Добавляем щепотку векторного программирования в задачки проекта Эйлер. Заодно разбираемся, как эффективно реализовать деление на константу.

Параллельное программирование *
Распараллеливаем вычисления
Новости
async2: эксперимент с поддержкой асинхронности в рантайме
Перед тем как перейти к рассмотрению предложенных изменений в работе асинхронности в C#, давайте разберемся — зачем все это нужно, как устроено сейчас и какие имеются проблемы, раз разработчики начали искать способы улучшения существующей логики.
Для начала давайте поймем, а зачем вообще нам нужна асинхронность и какие проблемы она решает?
Представим какой‑то абстрактный web‑api, который ходит за данными в БД. При однопоточном синхронном выполнении следующий запрос может быть обработан только тогда, когда полностью был выполнен предыдущий, что неэффективно, т.к. вся нагрузка ложится только на 1 ядро процессора, а остальные простаивают.
Что не так с ООП в 2025

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

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

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

В своём предыдущем посте о потоках я привёл импровизированное сравнение1:
Потоки2 — это просто состояния сохранения3 эмулятора4, связанные с условием, при котором продолжается их выполнение.
В тот момент я подумал, что это неплохая аналогия, но не мог перестать размышлять о ней. Я какое-то время крутил её в голове. Мне кажется, что у этой аналогии есть серьёзный потенциал в качестве инструмента обучения.
Поэтому я добавил многопоточность в Super Mario Bros. для NES.
Корутины в C++20: архитектура и практическое применение

Корутины в C++20 открывают новые возможности для асинхронного программирования, но они также могут привести к ошибкам, связанным с управлением памятью и синхронизацией. Здесь о том, какие проблемы могут возникнуть и чего ожидать от будущих обновлений корутин в C++.
Advanced Goroutines Patterns в Go: Fan-out, Fan-in и Pipelines

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

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

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

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

Идиома RAII — давно зарекомендовал себя как удобный способ автоматического управления ресурсами в C++. Обычно мы применяем его для управления памятью, файловыми дескрипторами или мьютексами. Однако что, если расширить понятие RAII до управления не только физическими ресурсами, но и логическими контрактами и состояниями системы?
В этой статье я хочу поговорить о том, как RAII можно использовать для контроля жизненного цикла асинхронных операций, транзакций или подписок, гарантируя их корректное завершение или откат до прежнего состояния.
Как я «ломал» DeepSeek

В своей предыдущей статье[1] я уже рассказывал, как начал свое знакомство с искусственным интеллектом (ИИ). Тогда это был ChatGPT, а теперь — китайский DeepSeek[2].
Общение с DeepSeek происходит без посредников, что делает его более удобным и доступным. Раньше за использование ChatGPT приходилось платить или, например, задавать не более трёх вопросов в сутки. А с DeepSeek можно спрашивать сколько угодно и о чём угодно, не тратя ни копейки. Правда, есть опасения, что бесплатная подписка может закончиться, и тогда доступ к сервису будет закрыт. Также ходят слухи о возможных проблемах с «нежелательными» запросами.
Так уж жизнь повернулась, что для меня в автоматном программировании (АП) возникла пауза. Но мне бросить АП все равно что перестать дышать. А потому просто произошла задержка дыхания или просто передышка. Меня это не сильно огорчило, т.к. я по-прежнему пользуюсь АП, вдыхая полной грудью его возможности. Даже в текущей ситуации.
Тем не менее, я кинулся, так сказать, «во все тяжкие». Мне предложили заняться «умными домами» и я согласился. Новая область, новые интересы, новое приложение своих сил. Короче, – «движуха»! Мы, ведь, все мечтаем о чем-то подобном – не так ли? А еще обещали мотивировать, что немаловажно в наше меркантильное время. Вспомним хотя бы размер виртуальной средней зарплаты по России и средний размер пенсий...
Сейчас я только рад случившемуся. Раньше было скучновато. Иногда взбадривало общение на Хабре, а теперь «поддает жару» искусственный интеллект. И хотя я предполагал что-то подобное, но не ожидал, что это произойдет столь быстро, так бурно и с таким эффектом. Китайский ИИ стал коллегой, советчиком, а, порой, и собеседником, помогая освоить новую область программирования. При этом я по-прежнему не согласен с глашатаями, предрекающими замену программистов, но уверен, что квалификацию многих из них он повысит точно. Я убедился в этом на своём опыте.
Ближайшие события
Метод Монте-Карло в алгоритме обратного распространения ошибок с параллельными вычислениями

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

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

На практике, создаваемое нами ПО выполняется на множестве процессоров. К сожалению, многие наши допущения, справедливые для одного процессора, в случае нескольких процессоров становятся ложными. Например, каким будет состояние памяти, если два процессора изменяют один блок памяти? В общем случае на этот вопрос ответить сложно. Может случиться так, что внесённое одним процессом изменение перепишет внесённое другим. Справедливо может быть и обратное: может «победить» изменение другого процессора. Или оба процесса могут попытаться внести изменение одновременно, в результате чего возникнет неопределённое состояние, не соответствующее ни одному ожидаемому. Мы называем такие операции доступа «гонками данных» — ситуацией, в которой два или более процессоров в программе одновременно получают доступ к одной области памяти, и хотя бы одна из этих операций доступа выполняет запись без должной синхронизации.
Всё становится сложнее, если вам нужно, чтобы несколько процессоров изменяли одну и ту же память намеренно. Например, предположим, что у нас есть переменная, отслеживающая количество проданных товаров. В программе инкремент этой одной переменной могут выполнять несколько процессоров.
Пример HTTP-сервера на PHP с использованием файберов. Улучшенная версия

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

Представьте себе: 2004 год, инженеры Intel готовятся к анонсу нового флагманского процессора Tejas. Семь гигагерц тактовой частоты — цифра, о которой разработчики могли только мечтать. И вдруг — неожиданное решение: проект отменен. Что произошло? Инженеры столкнулись с фундаментальным физическим барьером: тепловыделение и токи утечки делали дальнейшее наращивание частоты невозможным. Этот момент стал поворотным в истории вычислений.
«Мы достигли стены, — объявил тогда Патрик Гелсингер, технический директор Intel. — Будущее за параллелизмом».
Эта история наглядно иллюстрирует, почему мы живем в эпоху параллельных вычислений. Больше нельзя было рассчитывать, что программы автоматически будут работать быстрее на новом оборудовании — наступила эра, когда разработчикам приходится явно программировать с учетом множества одновременно работающих вычислительных элементов.
3200% нагрузки на процессор

Совсем недавно моя машина была в таком запущенном состоянии, что я едва мог подключиться к ней через ssh. 3200% нагрузки на CPU — полностью использовались все 32 ядра хоста! Сравните это с моим последним багом, когда использовалось всего одно ядро, то есть 100%
К счастью, я использовал среду выполнения Java 17, у которой были дампы потоков с указанием времени CPU!
Параллелизм в Go тестах: все, что нужно знать о -p, -parallel и t.Parallel()

В Go есть три способа управления параллельностью тестов:
Короткий гайд о -p
, -parallel
и t.Parallel
а также бонус для любителей параллельного программирования
Вклад авторов
ThisIsZolden 598.0YuriPanchul 314.0sidristij 269.4AlexeyR 269.0khizmax 265.0ivorobts 206.0krogozh 206.0Stefanio 179.0AndrewSu 177.0AlexeyAB 167.0