Параллельное программирование *

Как Rust обманывает процессор. Часть 2: niche сквозь крейты, dropck, Pin и провенанс указателей

В первой части мы обсуждали niche-оптимизацию, drop flags, MIR, Stacked Borrows и async-стейт-машины. В комментариях справедливо заметили (спасибо, Mingun): про niche рассказано в простой форме - Option<&T> и NonZeroU8.

А что происходит, когда enum живёт в одном крейте, оборачивается в newtype в другом, и оба варианта внешнего enum хранят один и тот же внутренний? У такого внешнего типа всего четыре состояния, байта должно хватить. Хватит ли? Зависит от того, как rustc считает layout. Об этом и поговорим.

Во второй части идём глубже: niche сквозь границы крейтов, variance, Pin и самоссылающиеся футуры, dropck с #[may_dangle], Tree Borrows вместо Stacked Borrows и strict provenance. Без этого половина unsafe-кода в экосистеме держится на честном слове.

Возможно, на мой предвзятый взгляд, нынче автоматным программированием (АП) называют любое программирование, в которое вводят состояния (а параллельным – где используют потоки). Но не все, что с колесами – машина, а с крыльями – самолет. И далеко не всегда то, что «выглядит» как автомат, «плавает» как автомат и «крякает» как автомат им является. Это ясно, если руководствоваться математическим определением конечного автомата (КА). Только соответствие этому позволяет  считать программирование автоматным. Подробнее же об АП рассказано в [1].

Среди существующих программных подходов некоторые на взгляд программистов относятся к категории АП. Это, например, варианты диаграмм Харела (Statecharts) и языков на них основанных. Например, UML (Unified Modeling Language). Именно этой теме посвящена статья на Хабре, которая описывает проектирование на базе КА  в среде Engee[2].  В последней есть библиотека «Конечные автоматы» – «лучший инструмент для визуального проектирования сложной управляющей логики» [3].

Разберем данную статью, создав аналог рассмотренного в ней решения, но только на языке С++ и в среде ВКПа – классическом варианте технологии автоматного программирования. Это позволит объективно сравнить подходы, а вам, «хабравчане», останется только составить уже свое мнение о разных вариантах АП.

Операционная «Ghetto MLOps»: пересадка 31B‑мозга Gemma в MoE‑экзоскелет DeepSeek. Без наркоза и дообучения.

Дисклеймер: Эта статья не о том, как сделать убийцу ChatGPT бесплатно. Она о том, как глубоко можно залезть под капот PyTorch и Transformers, и как заставить работать вместе вещи, которые физически не должны работать. Слабонервным математикам читать с осторожностью.

У нас было две бесплатные видеокарты T4 в Kaggle, 30 ГБ оперативной памяти и безумная идея: что будет, если взять веса классической модели (Gemma-4-31B) и хирургическим путем, без всякого дообучения, вшить их в MoE-архитектуру (DeepSeek-V4)?

В академической среде вам скажут, что это невозможно: разные размерности, несовместимые слои нормализации, разные принципы роутинга токенов. Но в парадигме Ghetto MLOps нет слова «невозможно». Есть только вопрос: сколько костылей потребуется, чтобы это скомпилировалось?

Апдейт: идеи, изложенные в этой статье, позволили сформулировать оптимальные стратегии warp-специализации, описанные в научной публикации, которую можно посмотреть здесь.

Недавно я глубоко задумался о специализации варпов в контексте высокопроизводительных ядер для современных графических процессоров (GPU) на тензорных ядрах. Примеры таких процессоров — H100 и B200 от NVIDIA. Я стал полнее понимать, чего можно добиться при помощи специализации варпов, а также задался интересным вопросом: а нужна ли нам вообще специализация варпов (и вся та сложность, которую она с собой влечёт)? В итоге я пришёл к выводу, что, да, нуждаемся, но она не столь обязательна, как может показаться. В этом посте обсудим, в каких случаях без специализации варпов действительно не обойтись, а также я опишу, на каком пространстве компромиссов она зиждется, и какие границы этого пространства я вижу. Притом, что я обрисую некоторый контекст, касающийся графических процессоров, необходимый для обсуждения тем, которые мы взялись здесь рассмотреть, эту статью нельзя считать туториалом. Предполагается, что читатель имеет некоторый опыт работы с GPU и имеет опыт параллельного программирования.

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

Анимация: генерирует последовательность из 255 высокоточных кадров в формате BMP (frame_000.bmp ... frame_254.bmp) и автоматически компилирует их в видеоролик (файл Mandelbrot.mp4) с частотой 30 кадров в секунду, используя встроенный FFmpeg.

Скачать последнюю версию (Windows и Linux)
В windows это Mandelbrot_windows.exe и ffmpeg.exe
https://github.com/Divetoxx/Mandelbrot-Video/releases
Выше README содержит English и Русский!

FFmpeg - "швейцарский армейский нож" для обработки видео. В 2026 году он остается отраслевым стандартом, поддерживаемым сообществом разработчиков открытого программного обеспечения. От YouTube и Netflix до профессиональных киностудий - все на него полагаются. И да, он совершенно бесплатный.

GIL — самая известная «фича» Python, о которой большинство разработчиков знают ровно одну фразу: «мешает многопоточности». Этого хватает для джуна, но не для сеньора.

Статья построена так, чтобы после её прочтения вы могли не только ответить на вопросы по GIL на senior-интервью, но и объяснить коллеге-стажеру, что происходит внутри интерпретатора, когда два потока пытаются одновременно изменить один список.

Если вы хоть раз встраивали Lua в свой проект — будь то игровой движок, высоконагруженный веб-сервер на OpenResty или конфигуратор сложного сетевого оборудования — вы знаете, за что мы его любим:)
А любим мы его — за компактность, быстроту, встраиваемость и предсказуемость. Не любим — за аскетичный синтаксис, отсутствие привычных конструкций и постоянное «изобретение велосипеда».
Эта статья — обзор диалекта Lattelua: зачем он нужен, чем отличается от других диалектов, и почему его особенно удобно использовать в уже существующих проектах, где Lua — встраиваемый язык.

Множество Мандельброта. 80-бит FPU x87. OpenMP - параллельным программированием на уровне многопоточности. Синий, зеленый и красный - синусоидальными и косинусоидальными волнами: 127 + 127 cos(2 PI a / 255) и 127 + 127 sin(2 PI a / 255). DwmFlush - синхронизация с монитором 60 fps. Суперсэмплинг 2x2 (4 прохода). Делал я. Посмотрите - движется! Я сделал на g++. Свободно распространяемого компилятора языка C++. Скачайте и посмотрите! Это экзешник, в ГитХаб.

github: Download Latest Version Windows And Source code

Самое полезное - это увеличиваем / уменьшаем и центрируем. Вы на экран любое из множество Мандельброта. Какое вам нравится? Какое интересное? Вы можете все! И потом запишется в файл Mandelbrot.txt - три строки из файла. Вещественная часть центра и мнимая часть центра и ширина видимой области. Потом другая программа читает Mandelbrot.txt и создает Mandelbrot.bmp и уже не суперсэмплинг 2x2 (4 прохода) а 8x8 (64 прохода)!

Вот так. Впервые в мире. Суперсэмплинг (SSAA) — ресурсоемкий метод сглаживания, увеличивающий число выборок на пиксель для повышения качества изображения. При значении 8x (N=8) сцена рендерится в разрешении, в 8 раз превышающем целевое, по обеим осям, создавая 64 (или 8 х 8) выборки на пиксель. Изображение просчитывается в более высоком разрешении, а затем принудительно уменьшается до разрешения дисплея, устраняя лесенки и улучшая чёткость. Это очень высокая нагрузка! Это не 1920 на 1080 пикселя а в 8x8 больше - 15360 на 8640 пикселя! Такое никто, кроме меня, делает в мире. Для множество Мандельброта.

Это маленькая утилита из командной строке. Которая либо читает Mandelbrot.txt три строки из файла - клавиша 7. И создает Mandelbrot.bmp
Либо клавиша 1-6 - это одно из шести разных мест множество Мандельброта и создает Mandelbrot.bmp
Скачайте и посмотрите. Это экзешник, в ГитХаб
Скачать последнюю версию (Windows и Linux)

Этот пост написан по мотивам выступления, с которым мы с Шисянь Ван ездили на конференцию Rust UnConf, организованную нью-йоркским сообществом Rust. Конференция UnConf собрала поистине потрясающий коллектив энтузиастов a Rust, в компании которых мы более двух часов посвятили глубоким техническим дискуссиям (а также поеданию мороженого). Далее при необходимости я буду ссылаться на опыт нашей компании Antithesis.

Всем привет! Меня зовут Сергей и последнее время я занимаюсь backend-разработкой на Scala. Вообще, мой опыт асинхронного программирования на Scala и C# составляет более десяти лет, и за это время сложилось вполне достаточное понимание этой темы. Во всяком случае, тогда мне так казалось…

Но недавно в беседе с коллегами обнаружились большие проблемы в моём «понимании», что мотивировало детально разобраться в этом вопросе.

Множество Мандельброта. 32-бит TrueColor. 60 FPS. 80-бит long double. OpenMP. Суперсэмплинг 2x2 (4 прохода). И цвета. Я хочу сказать. Это самая нужная вещь во Вселенной. Самая глубокое. И я сейчас за всю жизнь наконец стал писать код и сделал. Довольно сложное. И самое прекрасное. Скачайте и посмотрите! Это экзешник, в ГитХаб.

github: Download Latest Version Windows And Source code

Чем отличаются китайские дроны Tello от российских «Геоскан» и как они применяются в образовании школьников: практический опыт в Центре гуманитарных и цифровых профилей «Точка роста».

Множество Мандельброта. 60 fps. Вращение - анимация. Делал я. Она движется! И это - программа! Я сделал на g++. Свободно распространяемого компилятора языка C++. Почитайте! Очень интересно. Используя OpenMP, вы занимаетесь параллельным программированием на уровне многопоточности. И суперсэмплингом (антиалиасингом), выполняют сглаживание 8x8 (всего 64 прохода на один пиксель). Это позволяет получить плавные градиенты, которые 24-битного цвета TrueColor! И как делать видео с 255 файлов bmp - TrueColor анимация.

Допустим, вы написали код для решения задачи, которая хорошо распараллеливается. Каждый поток занимается своим участком работы и не зависит от других, поэтому потоки почти не должны координироваться друг с другом, за исключением самого последнего этапа, когда требуется объединить результаты. Естественно, в данном случае логично предположить, что чем больше ядер задействуется для такого кода, тем быстрее он выполнится. Вы ставите бенчмарки и сначала прогоняете этот код на ноутбуке. Действительно, оказывается, что он практически идеально масштабируется на всех четырёх доступных ядрах. Затем вы прогоняете его на большой и пафосной многопроцессорной машине, рассчитывая, что производительность будет ещё выше — но убеждаетесь, что на практике этот код работает даже медленнее, чем на ноутбуке, сколько бы ядер под него не выделить. Да, именно с таким случаем мне однажды довелось столкнуться.

Просматривая на Хабре поток «Параллельное программирование», не верится, что на дворе «образованный век». Все против этого. Особенно статьи типа «Три способа менять один объект из нескольких потоков. Больше нет».

Ныне любой, кому  поступило «поручение» провести ту или иную идею в массы, может городить любую чушь. А «народ» будет верить. Жечь свечи,  восклицать аллилуйя, бить поклоны, рукоплескать и, размазывая слезы, биться в экстазе от восторга, восхищения и прозрения.

Ну, а здесь на Хабре, ставить «плюсы». Каждый, конечно, имеет право на свою позицию. Но в чем-то хочется разобраться,  понять и, возможно, простить. Накопилось, наверное…

Упомянутая статья - «гром среди ясного неба»! Ни кто до этого не знал, что делать с одним объектом, а тут вдруг - прозрение! Буквально на раз или, что точнее, на три. Есть ровно три варианта, после чего «объекту» уже не скрыться от «потоков», у которых до него дотянуться руки. Ровно три! Меньше – да, «больше нет»!

Люди, вы пытаетесь вникнуть в смысл прочитанного?!   Спросите, где он? А вот это уже другой вопрос. На, который, к счастью, есть ответ… В научном познании мира.

Однако, процитирую отрывок из краеугольной, судя по реакции «народа»,  статьи...

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

Таким образом, если вас интересуют общие проблемы параллельных процессов, то в этой и в последующих статьях на примере логических процессов мы их и рассмотрим. Терминологически мы будем придерживаться словаря по вычислительной технике под редакцией В.Иллингоута[1].  Но это может быть учебная литература, подобная [2], научная литература, как монография  [3], или научно-популярные книги типа [4, 5].

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

У меня сформировался свой вариант модели конечного автомата  (КА), который далее будет основным. Данная модель, во-первых, очень близка к классической форме. А это важно, т.к. позволяет использовать теорию почти без исключений. А, во-вторых,  она удобна для практики программирования, допуская эффективную ее реализацию.  Более детально все эти вопросы освещены в статье [6].

В настоящее время многоядерные процессоры с гетерогенными архитектурами, в которых сочетаются ядра с различной производительностью, становятся всё более и более распространенными. Если ещё пару лет назад такие архитектуры были в основном распространены в мобильном сегменте (см. ARM BIG.little), то с анонсом в 2022 году компанией Intel процессоров 12-го поколения линейки Intel Core, такие процессоры стали распространяться в сегменте десктопов и рабочих станций. Однако, до сих пор остается открытым вопрос — необходимо ли каким‑то специальным образом учитывать особенности данных архитектур для достижения максимальной многопоточной производительности?

Команда Spring АйО подготовила перевод статьи в которой автор разбирает, где параллельные стримы действительно масштабируются, а где создают накладные расходы, конкуренцию за ресурсы и иллюзию производительности. Коротко: сначала аналитика и измерения, потом — параллелизм.