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

Несмотря на то, что сам я ушел из большого ООП¹ более десяти лет назад, причем, надеюсь, навсегда, я всегда крайне вяло и неохотно участвую в баталиях тупоконечников и остроконечников: я абсолютно убежден, что для разных типов задач лучше подходят разные инструменты, и выхолощенное ФП заставит всех вокруг создавать тонны никому не нужного бойлерплейта для тривиального круда, а кристальное ООП — воткнет все возможные палки в колёса при реализации бизнес-процессов. Любой из современных языков программирования позволяет смешивать эти подходы, а микросервисная архитектура — даже гостеприимно приютит несколько языков и сред под одной крышей.

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

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

Всем привет! Сегодня хочу поделиться с вами нашим опытом ускорения асинхронного микросервиса на Python примерно на 25%. Я расскажу, какие действия мы предпринимали с командой, что помогло, а что оказалось не особенно полезно с точки зрения ускорения сервиса.

Небольшое предисловие: мы в Иви постоянно работаем над тем, чтобы наши сервисы отвечали быстро и их максимальная предельная нагрузка повышалась. В процессе очередного анализа сервисов, мы выяснили, что один из них, о котором пойдет речь в статье, отвечает довольно медленно, учитывая его особенности. И мы решили его ускорять.

Поток — это последовательность элементов данных, предоставляемых за некоторое время. Концепция потока (stream) позволяет обрабатывать или передавать данные поэлементно, а не как одно целое. Потоки особенно полезны в сценариях, когда приходится работать с большими множествами данных, непрерывными данными или данными реального времени.

Потоки² — это просто состояния сохранения³ эмулятора⁴, связанные с условием, при котором продолжается их выполнение.

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

В языке Go одним из важнейших преимуществ является мощная поддержка многопоточности и параллелизма за счёт горутин и каналов. В этой статье подробно разберём три продвинутых шаблона работы с горутинами:

Каждому C++-разработчику приходится решать задачи асинхронности — от сетевых запросов до фоновых вычислений. В этой статье вы увидите, как P2300-модель Senders/Receivers в C++26 расширяет возможности std::async/std::future и позволяет строить ясные, декларативные конвейеры (then, when_all, upon_error и др.).

В этой статье я подготовил для вас прототип CRUD-приложения, которое использует файберы и неблокирующие(асинхронные) возможности драйвера PostreSQL. Вместе они дают любопытные результаты по производительности и потреблению памяти.

Наверное, я очень опоздал с изучением CUDA. До недавнего времени даже не знал, что CUDA — это просто C++ с небольшими добавками. Если бы я знал, что изучение её пойдёт как по маслу, я бы столько не медлил. Но, если у вас есть багаж привычек C++, то код на CUDA у вас будет получаться низкокачественным. Поэтому расскажу вам о некоторых уроках, изученных на практике — возможно, мой опыт поможет вам ускорить код.

Идиома RAII — давно зарекомендовал себя как удобный способ автоматического управления ресурсами в C++. Обычно мы применяем его для управления памятью, файловыми дескрипторами или мьютексами. Однако что, если расширить понятие RAII до управления не только физическими ресурсами, но и логическими контрактами и состояниями системы?

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

В своей предыдущей статье[1] я уже рассказывал, как начал свое знакомство с искусственным интеллектом (ИИ). Тогда это был ChatGPT, а теперь — китайский DeepSeek[2].

Общение с DeepSeek происходит без посредников, что делает его более удобным и доступным. Раньше за использование ChatGPT приходилось платить или, например,  задавать не более трёх вопросов в сутки. А с DeepSeek можно спрашивать сколько угодно и о чём угодно, не тратя ни копейки. Правда, есть опасения, что бесплатная подписка может закончиться, и тогда доступ к сервису будет закрыт. Также ходят слухи о возможных проблемах с «нежелательными» запросами.

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

Тем не менее, я кинулся, так сказать, «во все тяжкие». Мне предложили заняться «умными домами» и я согласился. Новая область, новые интересы, новое приложение своих сил. Короче, – «движуха»! Мы, ведь, все мечтаем о чем-то подобном – не так ли? А еще обещали мотивировать, что немаловажно в наше меркантильное время. Вспомним хотя бы размер виртуальной средней зарплаты по России и средний размер пенсий...

Сейчас я только рад случившемуся. Раньше было скучновато. Иногда взбадривало общение на Хабре, а теперь «поддает жару» искусственный интеллект. И хотя я предполагал что-то подобное, но не ожидал, что это произойдет столь быстро, так бурно и с таким эффектом. Китайский ИИ стал коллегой, советчиком, а, порой, и собеседником, помогая освоить новую область программирования. При этом я по-прежнему не согласен с глашатаями, предрекающими замену программистов, но уверен, что квалификацию многих из них он повысит точно. Я убедился в этом на своём опыте.

Был проведён эксперимент для проверки, можно ли существенно уменьшить объём вычислений в алгоритме обратного распространения ошибок с параллельными вычислениями за счёт использования на каждом шаге обучения только части обучающих образцов, выбранных случайным образом, а также определение того, какой выигрыш по времени даст использование языка Ассемблера в самых внутренних циклах (в программе, написанной на языке C++).

За основу был взят классический персептрон и алгоритм обратного распространения ошибок, основанный на методе градиента, который объяснялся на курсе Mashine Learning Стэнфордского университета. Он был доработан, чтобы можно было использовать параллельные вычисления. Была написана программа на языке C++ для Linux, её функции (создание, обучение нейронной сети, распознавание данных, закачка больших файлов на сервер и т. п.) вызываются из программ, написанных на любых языках программирования, по протоколу Socket.

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

Привет, Хабр! Это Дмитрий Бахтенков. Добро пожаловать в третью часть цикла статей «Многопоточность. Снизу вверх»! Мы уже разобрали процессор и операционную систему, а сегодня поговорим про использование потоков в .NET с помощью языка программирования C#.

Эта статья — обзор основных возможностей взаимодействия с потоками в .NET.

В статье Пример HTTP-сервера на PHP с использованием файберов / Хабр краеугольным камнем организации обработки HTTP-соединений является функция socket_select(), которая имеет значительное ограничение - максимальное значение дескриптора, которое можно добавить в любой из трёх аргументов данной функции составляет 1024. Данный лимит определяется константой FD_SETSIZE, для увеличения которой придётся сконфигурировать системные лимиты и как минимум пересобрать интерпретатор PHP, что нецелесообразно и может создать эксплуатационные проблемы. К тому же, производительность функции select(), обёрткой над которой является функция socket_select(), значительно проседает при ощутимом увеличении значения константы FD_SETSIZE. В данной статье я постараюсь продемонстрировать альтернативу, позволяющую избавить пример из предыдущей статьи от данного ограничения.

Представьте себе: 2004 год, инженеры Intel готовятся к анонсу нового флагманского процессора Tejas. Семь гигагерц тактовой частоты — цифра, о которой разработчики могли только мечтать. И вдруг — неожиданное решение: проект отменен. Что произошло? Инженеры столкнулись с фундаментальным физическим барьером: тепловыделение и токи утечки делали дальнейшее наращивание частоты невозможным. Этот момент стал поворотным в истории вычислений.

«Мы достигли стены, — объявил тогда Патрик Гелсингер, технический директор Intel. — Будущее за параллелизмом».

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

Совсем недавно моя машина была в таком запущенном состоянии, что я едва мог подключиться к ней через ssh. 3200% нагрузки на CPU — полностью использовались все 32 ядра хоста! Сравните это с моим последним багом, когда использовалось всего одно ядро, то есть 100%

К счастью, я использовал среду выполнения Java 17, у которой были дампы потоков с указанием времени CPU!

В Go есть три способа управления параллельностью тестов:

Короткий гайд о -p, -parallel и t.Parallel а также бонус для любителей параллельного программирования

Утечка горутин в Go происходит, когда горутина продолжает существовать и потреблять ресурсы, даже если она больше не выполняет полезной работы или не может завершиться. Это может произойти по разным причинам.
Мы рассмотрим 3 примера из которых: 2 будут на каналах, 1 с использованием mutex.