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

Привет, habr! Предлагаю вашему вниманию статью о том, как я писал велосипед библиотеку для передачи сообщений между потоками с возможностью мультиплексирования.

Всем привет!

При изучении темы фаззинг‑тестирования всегда возникает вопрос, насколько сильно можно увеличить количество выполнений приложения в секунду. Иначе говоря — как ускорить фаззинг?

В последнее время одно из популярных направлений — искусственный интеллект, его создание и обучение. Лично я от этой темы далек, однако имею представление, что лучшего всего он (ИИ) обучается на видеокартах. Более того, обучение может происходить с использованием облака.

И так, с одной стороны мы имеем фаззинг, который надо ускорить, с другой — большое количество вычислительных ресурсов на основе видеокарт из‑за активного развития ИИ. Так почему бы не попробовать использовать эти ресурсы во благо ИБ?

Привет, Хабр!

Предисловие

Начнем с того,что я не специалист по Java и у меня нет коммерческого опыта на этом языке. Я просто обычный кодер, который по вечерам пилит проекты на Java, а основной мой стек состоит из PHP и смеси Python + Go. В данной статье хочу с вами поделиться опытом с использованием виртуальных потоках (Virtual Threads) в обработке файлов.

Я довольно давно пишу на Python и во многих проектах использовал multiprocessing — пакет стандартной библиотеки языка Python, который предоставляет интерфейс для работы с процессами, очередями, пулами процессов и многими другими удобными инструментами для параллельного программирования. В какой-то момент я понял, что мне не хватает более детального понимания работы этой библиотеки.

Мне захотелось залезть в исходники multiprocessing, разобраться и заодно написать статью. Данная статья в основном рассчитана на новичков в Python и тех, кто хочет подробнее разобраться в том, как именно создаются процессы и пулы в Python и погрузиться в детали реализации.

В прошлый раз мы разобрали пример, когда асинхронная операция использует дополнительный поток. Этот пример многим показался провокационным и даже вредным, что для меня выглядит достаточно странным. Насколько я понял основной претензией является то, что этот пример для многих как бы отрицает «экономное использование потоков», как это сформулировано например здесь-«metanit: Асинхронное программирование» .

Конечно, многие обиделись на меня за то, что я посмел возражать признанному авторитету, который вынес в заголовок своей очень известной работы фразу There is no thread (Там нет потока) ведь хорошо известно, что: «нет пророка в своем отечестве», и, видимо, быть не должно, но это все эмоции.

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

Python-разработчики, как правило, хорошо знают, что такое и для чего нужен GIL, вопросы по нему встречаются на большинстве собеседований, я и сам люблю их задавать. Но в CPython его скоро не будет. Да, core-разработчики CPython взяли курс на его удаление.

Разберём основные концепции того, как это будет произведено, с обзором соответствующего PEP 703.

Судя по обилию статей «Кто такой архитектор в ИТ?» — нет общего понимания, чем он занимается, должен ли он вырасти из программиста или его можно сделать из системного аналитика. На самом деле ключевым качеством, которое сразу выделяет его среди остальных в ИТ, является способность смотреть на задачу с разных точек зрения. В статье приводится простой практический архитектурный кейс для очень известной системы, и выводы будут однозначные.

Когда нам показывают на некотором примере, что асинхронная операция не создает потока, нам пытаются внушить, что асинхронная операция НИКОГДА не создает потока и в принципе не может его создать, но это не правда! Простой пример с работающим кодом доказывает обратное. Давайте разберем этот пример.

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

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

Про закулисье async/await написано предостаточно. Как правило, авторы декомпилируют IL-код, смотрят на IAsyncStateMachine и объясняют, вот дескать какое преобразование случилось с нашим исходным кодом. Из бесконечно-длинной прошлогодней статьи Стивена Тауба можно узнать мельчайшие детали реализации. Короче, всё давно рассказано. Зачем ещё одна статья?

Я приглашаю читателя пройти со мной обратным путём. Вместо изучения декомпилированного кода мы поставим себя на место дизайнеров языка C# и шаг за шагом превратим async/await в код, который почти идентичен тому, что синтезирует Roslyn.

Продолжаем серию статей про особенности, применение, плюсы и минусы языков, которые используются в «Криптоните». В этой статье наш инженер департамента инфраструктуры Алексей Косов расскажет про Golang.

Ранее наши разработчики делали обзоры Rust, Scala, JavaScript и Spark.

Наконец‑то мы добрались до конечной цели — графики, которая достаточно близко к реальности моделирует интересующие нас объекты. Речь пойдет об объектах систем управления (СУ). Это датчики, переключатели, индикаторы, моторы, конвейеры, объекты типа рассматриваемой нами гильотины и т. д. и т. п.

Данный цикл статей - не техническая документация, не подробное описание научных идей. Это краткое, обобщенное описание возможностей среды ВКПа на простом примере. Демонстрация процессов и принципов работы в ней. Идеи - проверенная временем часть. Они описаны в статьях, ссылки на основные из них приведены в  первой части [1]. Без понимания этого материала невозможно разобраться, зачем вообще нужна подобная среда. Ведь, существует и другое автоматное программирование. Но только идеи, положенные в их основу, другие.

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

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

В моих статьях часто используется аббревиатура ВКПа. Это сокращение названия программной среды проектирования по канонам технологии автоматного программирования - среды автоматного Визуально-Компонентного Программирования (подробно основы ее теории описаны в статьях [1, 2]). Объяснение, что это за среда, конечно, дается, но, признаю, что делается это часто по ходу, достаточно поверхностно и разбросанно по многим статьям.

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

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

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

В 1978 году вышел третий том монографии Дональда Кнута «Искусство программирования», где автор рассматривает алгоритмы сортировки и поиска. Помимо самих алгоритмов описаны аппаратные характеристики компьютера и их влияние на производительность при работе с алгоритмами.

В 2024 году мы с вами возьмём классические алгоритмы сортировки и посмотрим, как работает современный многоядерный процессор при сортировке нескольких массивов на одном и нескольких логических ядрах. Мы напишем приложение с графическим интерфейсом (GUI) на фреймворке Qt, обойдем глобальную блокировку интерпретатора (GIL), воспользуемся несколькими потоками, на один из которых переложим выполнение асинхронного цикла событий, и распараллелим этот поток для реализации параллельных вычислений.

Процессоры архитектуры  сверхдлинного машинного слова (VLIW - Very Long Instruction Word) относятся к специфическим классам архитектур, прямо нацеленным на использование внутреннего параллелизма в алгоритмах (программах), причём параллелизм этот анализируется и планируется к рациональному использованию при вычислениях на программном уровне; собственно аппаратная часть освобождается от процедур распараллеливания  (и поэтому должна стать проще и экономичнее использующих внутреннее распараллеливание).

VLIW-подход основан на идее загрузки во входной буфер процессора одновременно набора (bundle) допускающих параллельное выполнение  машинных команд и исполнения этого ряда команд аналогично единой команде в процессорах классической архитектуры. VLIW-процессоры реализуют параллелизм уровня ILP (Instruction-Level Parallelizm, параллелизм уровня машинных инструкций) и SMP (Symmetric MultiProcessing, системы с общей памятью)   идеологему работы с оперативной памятью. Несмотря на выпуклое преимущество (программным путём дешевле реализовать сложные процедуры параллелизации), работа VLIW-процессоров сопряжена с известными проблемами. Среди них называют статичность полученных планов параллельного выполнения и проблемы с излишней неравномерностью времени доступа к оперативной памяти разных вычислительных ядер   (временна́я антиплотность кода,   следствием является резкое снижение производительности из-за неизбежности  определять время выполнения всей связки команд сверхдлинного слова по продолжительности наиболее длинной из них).