В этой статье рассматривается несколько альтернативных моделей памяти для языка Rust. Надеюсь, эта дискуссия будет ценна всему сообществу Rust – но, в конце концов, это их язык, поэтому и выбор модели памяти тоже за ними.

Эта дискуссия ведется с позиций принятой в Rust безбоязненной конкурентности. Затравкой для нее послужили различные обсуждения, которые я наблюдал и в которых сам участвовал, работая над этой серией статей. Разумеется, мнения у разных членов сообщества тоже разнятся, люди могут обоснованно отстаивать разные варианты решений. Те, кто меня знают, понимают, что эти точки зрения серьезно расходятся с моей. Однако, моя точка зрения продиктована тем, что я давно работаю в условиях максимально возможной производительности, масштабируемости, молниеносного отклика, энергоэффективности, устойчивости и многого другого. В таких условиях определенная перестраховка – выбор не только мудрый, но и жизненно необходимый. В авиации есть примета, что есть пилоты отважные, а есть старые, но отважные пилоты до старости не доживают.

Тем не менее, я рассчитываю, что мой более чем тридцатилетний опыт работы с конкурентностью и моя работа над моделью памяти в C/C++ (безотносительно memory_order_consume), а также моя роль ведущего специалиста по поддержке модели памяти ядра (LKMM) послужат хорошей отправной точкой, чтобы высказаться о более прозаических задачах, решение которых, я уверен, стремятся поддержать в сообществе Rust.

Перед каждым сервисом, генерирующим хотя бы 1 Мбит/сек трафика в интернете возникает вопрос: «Как? по TCP или по UDP?» В прикладных областях, в том числе и платформах доставки уже сложились предпочтения и традиции принятия подобных решений.

По идее, если бы, к примеру, однажды один ленивый разработчик не попробовал развернуть свой ML на Python (потому что только его и знал), мир скорее всего никогда не проникся бы такой любовью к презренному «супер-джава-кодерами» языку. А сегодня слабости этого языка в прошлом контексте применения безоговорочно обеспечивают ему первенство в развертывании и запуске многочисленных майнерских А/Б.

Сравнивать можно многое: ARM с Intel, iOS и Android, а Mortal Kombat с Injustice. И нарваться на космический холивар, поэтому вернемся к теме доставки огромных объемов разноформатного контента.

Десять лет назад все были абсолютно уверены, UDP — это что-то про негарантированную доставку. Если нужен надежный протокол — это TCP. И вопреки традициям в этой статье мы будем сравнивать такие, кажущиеся несравнимыми вещи, как TCP и UDP.


Осторожно, под катом 99 иллюстраций и схем и все важные.

Всем привет, меня зовут Саша, я руковожу тестированием бэкенда. У нас, как и у многих, реализована сервис-ориентированная архитектура. С одной стороны, это упрощает работу, т.к. каждый сервис проще тестировать по отдельности, но с другой — появляется необходимость тестировать взаимодействие сервисов между собой, которое часто происходит по сети.

В этой статье я расскажу о двух утилитах, с помощью которых можно проверить базовые сценарии, описывающие работу приложения при наличии проблем с сетью.

Вторая часть: Принципы работы видеокодека

---

Любое растровое изображение можно представить в виде двумерной матрицы. Когда речь заходит о цветах, идею можно развить, рассматривая изображение в виде трехмерной матрицы, в которой дополнительные измерения используются для хранения данных по каждому из цветов.

Если рассматривать итоговый цвет как комбинацию т.н. основных цветов (красного, зеленого и синего), в нашей трёхмерной матрице определяем три плоскости: первая для красного цвета, вторая для зеленого и последняя для синего.

Будем называть каждую точку в этой матрице пикселем (элементом изображения). Каждый пиксель содержит информацию об интенсивности (обычно в виде числового значение) каждого цвета. Например, красный пиксель означает, что в нём 0 зеленого цвета, 0 синего и максимум красного. Пиксель розового цвета может быть сформирован с помощью комбинации трех цветов. Используя числовой диапазон от 0 до 255, розовый пиксель определяется как Красный = 255, Зелёный = 192 и Синий = 203.

Часть 1: обработка вершин

В этой статье мы подробнее рассмотрим то, что происходит с 3D-миром после завершения обработки всех его вершин. Нам снова придётся стряхнуть пыль с учебников по математике, освоиться в геометрии пирамид усечения и решить загадку перспектив. Также мы ненадолго погрузимся в физику трассировки лучей, освещения и материалов.

Главная тема этой статьи — важный этап рендеринга, на котором трёхмерный мир точек, отрезков и треугольников становится двухмерной сеткой разноцветных блоков. Очень часто этот процесс кажется незаметным, потому что преобразование из 3D в 2D оказывается невидимым, в отличие от процесса, описанного в предыдущей статье, где мы сразу же могли увидеть влияние вершинных шейдеров и тесселяции. Если вы пока не готовы к этому, то можете начать с нашей статьи 3D Game Rendering 101.

Подготовка к двум измерениям

Подавляющее большинство читателей читают этот веб-сайт на совершенно плоском мониторе или экране смартфона; но даже если у вас есть современная техника — изогнутый монитор, то отображаемая им картинка тоже состоит из плоской сетки разноцветных пикселей. Тем не менее, когда вы играете в новую Call of Mario: Deathduty Battleyard, изображения кажутся трёхмерными. Объекты движутся по сцене, становятся больше или меньше, приближаясь и отдаляясь от камеры.

В этой статье я попытаюсь описать терминологию, используемую для описания систем, способных исполнять несколько программ параллельно, то есть многоядерных, многопроцессорных, многопоточных. Разные виды параллелизма в ЦПУ IA-32 появлялись в разное время и в несколько непоследовательном порядке. Во всём этом довольно легко запутаться, особенно учитывая, что операционные системы заботливо прячут детали от не слишком искушённых прикладных программ.



Используемая далее терминология используется в документации процессорам Intel. Другие архитектуры могут иметь другие названия для похожих понятий. Там, где они мне известны, я буду их упоминать.

Цель статьи — показать, что при всём многообразии возможных конфигураций многопроцессорных, многоядерных и многопоточных систем для программ, исполняющихся на них, создаются возможности как для абстракции (игнорирования различий), так и для учёта специфики (возможность программно узнать конфигурацию).

Однажды в Slack я наткнулся на новый акроним для моего глоссария акронимов C++: “VTT.” Godbolt:

test.o: In function `MyClass':
test.cc:3: undefined reference to `VTT for MyClass'

“VTT” в данном контексте означает «таблица виртуальных таблиц» (virtual table table). Это вспомогательная структура данных, используемая (в Itanium C++ ABI) при создании некоторых базовых классов, которые сами унаследованы от виртуальных базовых классов. VTT следуют тем же правилам размещения, что и виртуальные таблицы (vtable) и информация о типе (typeinfo), так что если вы получили ошибку, приведённую выше, вы можете просто мысленно подставить «vtable» вместо «VTT», и начать отладку. (Скорее всего, вы оставили неопределённой ключевую функцию класса). Для того, чтобы увидеть, почему VTT, или аналогичная структура, необходима, начнём с основ.

Руководящая философия

1. Языки программирования для людей

Языки программирования это то, как люди говорят с компьютерами. Компьютер будет рад поговорить на любом языке, который не будет двусмысленным. Причина почему у нас есть высокоуровневые языки — потому что люди не могут справиться с машинным языком. Суть языков программирования в том, чтобы предотвратить наш бедный хрупкий человеческий мозг от перегрузки массой деталей.

Оптимизирующие компиляторы — основа современного ПО: они позволяют программистам писать код на понятном для них языке, затем преобразуя его в код, который сможет эффективно исполняться оборудованием. Задача оптимизирующих компиляторов заключается в том, чтобы понять, что делает написанная вами входная программа, и создать выходную программу, которая делает всё то же самое, только быстрее.

В этой статье мы рассмотрим некоторые из основных методик приведения (inference techniques) в оптимизирующих компиляторах: как спроектировать программу, с которой компилятору будет легко работать; какие приведения можно сделать в вашей программе и как использовать их для её уменьшения и ускорения.

Оптимизирующий AOT-компилятор обычно структурирован так:

1. фронтенд, преобразующий исходный код в промежуточное представление
2. конвейер машинно-независимой оптимизации (IR): последовательность проходов, которые переписывают IR для устранения неэффективных участков и структур, которые не могут быть непосредственно преобразованы в машинный код. Иногда эту часть называют middle-end.
3. Машинно-зависимый бэкенд для генерации ассемблерного кода или машинного кода.

В некоторых компиляторах формат IR остаётся неизменным на протяжении всего процесса оптимизации, в других его формат или семантика меняется. В LLVM формат и семантика фиксированы, и, следовательно, возможно запускать проходы в любой последовательности без риска неверной компиляции или аварийного завершения работы компилятора.

«Думаю, я смело могу сказать, что квантовую механику никто не понимает», — Ричард Фейнман

Тема квантовых вычислений всегда привлекала технических писателей и журналистов. Ее потенциал в области вычислений и сложность придали ей некий мистический ореол. Слишком уж часто тематические статьи и инфографика подробно описывают всевозможные перспективы этой отрасли, при этом едва затрагивая вопросы ее практического применения: это может ввести в заблуждение не слишком внимательного читателя.

Мы в поте лица готовим очередную мажорную версию Tokio, асинхронной среды выполнения для Rust. 13 октября для слияния в ветку оформлен пул-реквест с полностью переписанным планировщиком задач. Результатом станет огромное улучшение производительности и уменьшение задержки. В некоторых тестах зафиксировано десятикратное ускорение! Как обычно, синтетические тесты не отражают фактическую выгоду в реальности. Поэтому мы также проверили, как изменения в планировщике повлияли на настоящие задачи, такие как Hyper и Tonic (спойлер: результат замечательный).

Готовясь к работе над новым планировщиком, я потратил время на поиск тематических ресурсов. Кроме фактических реализаций, особо ничего не нашлось. Я также обнаружил, что в исходниках существующих реализаций трудно ориентироваться. Чтобы исправить это, мы постарались написать шедулер Tokio как можно более чисто. Надеюсь, эта подробная статья о реализации планировщика поможет тем, кто находится в том же положении и безуспешно ищет информацию на эту тему.

Статья начинается с высокоуровневого обзора дизайна, в том числе политик захвата работы. Затем погрузимся в детали конкретных оптимизаций в новом планировщике Tokio.

IT-департаменту ВТБ несколько раз приходилось сталкиваться с нештатными ситуациями в работе систем, когда нагрузка на них многократно возрастала. Поэтому появилась необходимость разработать и опробовать модель, которая предсказывала бы пиковую нагрузку на критичные системы. Для этого IT-специалисты банка настроили мониторинг, проанализировали данные и научились автоматизировать прогнозы. Какие инструменты помогли спрогнозировать нагрузку и получилось ли с их помощью оптимизировать работу, мы расскажем в небольшой статье.

Ubuntu интегрирована в Windows 10 Redstone, Visual Studio 2017 обзавелась поддержкой разработки под Linux – даже Microsoft сдает позиции в пользу растущего числа сторонников Торвальдса, а ты всё еще не знаешь тайны виртуального терминала в современных дистрибутивах?

Хочешь исправить этот пробел и открываешь исходный код? TTY, MASTER, SLAVE, N_TTY, VT, PTS, PTMX… Нагромождение понятий, виртуальных устройств и беспорядочная магия? Всё это складывается в довольно логичную картину, если вспомнить, с чего всё началось…

На написание данной статьи меня вдохновила статья об анализе Сишного printf. Однако, там был пропущен момент о том, какой путь проходят данные после того, как они попадают в терминальное устройство. В данной статье я хочу исправить этот недочет и проанализировать путь данных в терминале. Также мы разберемся, чем отличается Terminal от Shell, что такое Pseudoterminal, как работают эмуляторы терминалов и многое другое.

В недавнем обсуждении в очередной раз всплыла тема щедрости Илона Маска в виде безвозмездной (т.е. даром) раздачи патентов. Так же в очередной раз всплыли и сомнения в этой щедрости. Ради корректировки и поддержания объективной картины мира нужно не только читать многомегабайтные цепочки комментариев на Хабре, но и изредка заглядывать в первоисточники.

Первоисточник этот US 2014/0152260 RESPONSE TO DETECTION OF AN OVERDISCHARGE EVENT IN A SERIES CONNECTED BATTERY ELEMENT — A system and method for identifying and responding to exceptional charge events of series-connected energy storage elements ( www.patentsencyclopedia.com/app/20140152260 ).

«Реакция на событие переразряда последовательно соединённого элемента батареи — Система и метод определения и реакции на исключительные события при заряде последовательно соединённых элементов»

После того, как вы прочитали базовые шаги по написанию Hello World ядра из цикла имеющихся на Хабре статей, самое время приступить к серьезной разработке самых базовых инструментов: аллокатора кучи и планировщика.

Важно:
1. Эта серия уроков для новичков. Цель — сформировать целостную картину мира. Очень долго у меня в голове была теория Таненбаума и я не мог ее связать с практикой. Тем у кого то же самое — посвящаю эту статью.
2. Код самый простой и тупой, но максимально понятный. Моя цель дать вам понимание чтобы вы смогли написать свое ядро, гораздо более крутое чем это.
3. Репо опубликую как только посчитаю его готовым для широкого круга. Я пишу небольшую часть, отлаживаю, и снимаю видеоурок. У меня нет готового продукта.

Честно говоря я долго думал стоит ли начинать писать статьи и делать видеоуроки на столь изьезженную тему. Но страсть к системному программированию и отсутствие структурированной информации на русском языке все же подтолкнули меня на этот эксперимент. Посему, если труд мой окажется востребованным, статьи планирую выпускать не реже чем раз в месяц и не чаще чем раз в неделю.

Последнее, что хочется увидеть во время дебага кода — это хаос. Но что если этот хаос управляемый и запущен руками самого разработчика? Зачем умышленно устраивать турбулентность в слаженной работе своего приложения, как добиться душевного спокойствия при релизе важных фич и где точно вам пригодится практика хаос-инженерии, читайте в разговоре ведущих подкаста AppsCast с Павлом Осиповым PavelOsipov.

В этой статье рассмотрены основные вопросы, касающиеся принципа действия АЦП различных типов. При этом некоторые важные теоретические выкладки, касающиеся математического описания аналого-цифрового преобразования остались за рамками статьи, но приведены ссылки, по которым заинтересованный читатель сможет найти более глубокое рассмотрение теоретических аспектов работы АЦП. Таким образом, статья касается в большей степени понимания общих принципов функционирования АЦП, чем теоретического анализа их работы.

"

Введение

В качестве отправной точки дадим определение аналого-цифровому преобразованию. Аналого-цифровое преобразование – это процесс преобразования входной физической величины в ее числовое представление. Аналого-цифровой преобразователь – устройство, выполняющее такое преобразование. Формально, входной величиной АЦП может быть любая физическая величина – напряжение, ток, сопротивление, емкость, частота следования импульсов, угол поворота вала и т.п. Однако, для определенности, в дальнейшем под АЦП мы будем понимать исключительно преобразователи напряжение-код.

Прим. перев.: Рады поделиться переводом замечательного материала от старшего технологического евангелиста из AWS — Adrian Hornsby. В простых словах он объясняет важность экспериментов, призванных смягчить последствия сбоев в ИТ-системах. Вы, наверное, уже слышали про Chaos Monkey (или даже применяли подобные решения)? На сегодняшний день подходы к созданию подобных инструментов и их реализация в более широком контексте осуществляются в рамках деятельности, которую называют chaos engineering. Подробнее о ней читайте в этой статье.

«Но за всей этой красотой скрывается хаос и безумие». — Tanner Walling

Пожарные. Эти высококвалифицированные специалисты каждый день рискуют жизнью, борясь с огнем. Знаете ли вы, что перед тем, как стать пожарным, необходимо провести в тренировках минимум 600 часов? И это только начало. Согласно отчетам, пожарные тренируются до 80% своего рабочего времени.

Почему?