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

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

На рис. 1 приведена блок-схема алгоритма нахождения наибольшего общего делителя двух натуральных чисел из книги Н. Вирта[1]. С таких алгоритмов, да и с подобных книг,  начинается или должно начинаться знакомство с программированием. И, кстати, книга Н.Вирта была одной из первых, с которой в свое время познакомился и я. Так что здесь присутствует и некий личный мотив.

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

Итак, в данной статье мы поговорим о многопоточности в Java. Тема очень обширная, и я не ставлю целью описать все ее аспекты. Статья рассчитана на людей, только начинающих свое знакомство с многопоточностью. В данной статье мы рассмотрим основу многопоточности Java, такие базовые механизмы синхронизации как ключевые слова volatile и synchronized и очень важную проблематику “Состояние гонки” и “Смертельная блокировка”. 

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

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

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

В статье я расскажу как разработчиков вводят в заблуждение рассказывая что необходимо учесть в первую очередь при разработке серверов (и не только для игр), но умалчивая о реальных "узких местах" (проблемах).

В конце статьи будет приложена видео версия.

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

Будет затронута тема очередей, асинхронного логирования, параллельного программирования на CPU и использования каналов (сhannel) для взаимодействия между процессами (thread - ветками) на языке программирования PHP (аналогичный функционал есть в языке GO).

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

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

Давайте посмотрим, на что она способна.

Из нашей повседневной практики доподлинно известно, что массивно(массово?)-параллельные вычисления это круто. Но что именно означает этот термин, и как "массивность" и "параллельность" реализованы в конкретной системе? В данной статье мы ответим на оба вопроса, проанализировав внутреннюю архитектуру популярного MPP-движка для больших данных Trino.

В первой части статьи мы рассмотрели написание на современном Фортране простой программы, реализующей клеточный автомат "Жизнь", в виде классического последовательного кода (SISD), матричных операций (SIMD) и параллельных конструкций SMP (SIMD с частью функций MIMD). Сейчас мы будем рассматривать использование конструкций Фортрана для программирования массивно-параллельных архитектур (MPP), к которым, в частности, относятся современные суперкомпьютеры. Такие архитектуры реализуют классическую схему MIMD.

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

Вы замечали, как простые вопросы иногда приводят к сложным вопросам? Сегодня мы попытаемся подступиться к одному из таких вопросов. Категория — наша любимая: сетевые аспекты Linux.

Все знают про язык программирования C, поменьше — про язык программирования F, кое‑кто про B, предшественник C, а вот знаете ли вы про язык «e»? Их кстати два — один с большой буквы «E», а другой с маленькой «e».

Вы наверное подумали, что это еще один безызвестный язык от какого‑нибудь аспиранта провинциального европейского университета. Однако интерпретатор маленького «e» под названием Specman продали в 2005 году большой компании Cadence Design Systems за $315 милионов долларов. Причем президента продающей компании Verisity звали Гаврилов. Также можно нагуглить, что этот язык использовали внутри компании Intel. Что же в нем такого, что вызвало интерес у толстых богатых корпораций?

Параллельное программирование — одна из самых интересных фич, которые может предложить вам Golang. Идея, лежащая в основе параллелизма, заключается в одновременной работе над несколькими разными процессами, что помогает избежать застревания в задачах, выполнение которых занимает много времени.

Поводом для написания статьи послужило не очень приятное для меня событие: модератор Хабра убрал теги – «С++» и «Параллельное программирование» из моей крайней статьи [1]. Этому предшествовало сообщение пользователя, который по его словам не заметил в статье ни С++, ни параллелизма и поспешил об этом известить весь свет. На самом деле он, скорее всего, просмотрел статью по диагонали и попросту "не врубился". Другим объяснить сей казус сложно. Я объяснил причины его заблуждения, но это не было принято во внимание. В ответ – тишина и, более того, пошли у него на поводу.

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

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

Генерация случайных чисел окружает нас везде. Любой шаг, дыхание, дуновение ветра, шум кулера, частота мяуканья кошки и т.п. уже может рассматриваться как некая генерация случайности. Так например, насколько вы контролируете вашу ходьбу? Можете ли вы с точностью до нанометра определить точку опоры? Если не можете, то сама погрешность в неопределённости расстояния начинает становиться для вас генератором случайности.

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

У разных электронных компаний вопросы на интервью немного отличаются. В одной интервьюер на скрининге (первом интервью) спросит кандидата на RTL позицию про конечный автомат, в другой про арбитр, кэш или конвейер, в третьей про упорядочение неупорядоченных транзакций. Но на большом интервью вопрос про очередь FIFO появится практически всегда - не первым/вторым, но третьим.

Это может быть элементарный вопрос "напишите на доске (физической, ха-ха, без доступа к интернету и ChatGPT) код для FIFO на D-триггерах". Или это может быть обсуждение микроархитектуры какого-нибудь извращенного FIFO, например FIFO с отменой вталкиваний, или с возможностью втолкнуть и вытолкнуть переменное количество кусков данных за такт, или с конвейером и кредитным счетчиком, или работающее на памяти с высокой латентностью, или асинхронное FIFO из статьи Клиффа Каммингса про пересечение тактового домена.

Эта заметка является сиквелом заметки "FIFO для самых маленьких", а также приквелом занятия в Школе синтеза цифровых схем в ближайшую субботу. Главное нововведение - все примеры и упражнения теперь делаются не только в симуляторе, но и на плате ПЛИС.

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

Блоки на внутреннем ЯП в SimInTech создаются на базе блока PL  - блок библиотеки Динамические. Напомним реализацию модели аттрактора Лоренца на стандартных библиотечных блоках. Она приведена на рис. 1. Далее мы ее будем называть исходной схемой. Часть ее вместе с соответствующим кодом на языке программирования SimInTech (LangBlock22) представлена на рис. 2.

Приветствую

Появилась задача моделирования процесса теплопроводности. Для решения необходимо было использовать метод продольно-поперечной прогонки, а для распараллеливания - MPI

Разберем не только теорию, но и подробности решения

Я уже не знаю кому и чему верить. Собрался было подводить итоги по обсуждению аттрактора Лоренца, но что-то меня заставило "поиграть" еще с одним - мотором Рикитаке [1]. И, честное слово, какого-либо подвоха я, ну, никак  не ожидал. Просто потому, что по виду графиков он был, пожалуй, наиболее стабильным и характерным по внешнему виду во всех программных пакетах - MATLAB, SimInTech и ВКПа (cм. также предыдущую статью [2]).

            На структурном уровне рассматриваемые аттракторы можно представить в виде трех блоков ("черных ящиков"), отличающихся лишь видом связей. Структурная модель аттрактора Рикитаке представлена на рис. 1а, а на рис. 1б для сравнения приведена схема аттрактора Лоренца.

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

И, вроде бы все так, да не всегда. Критично ли наличие ошибок в программах? Странный вопрос - конечно, критично. Но, тем не менее, найдутся и те, кто скажет – не беда. И даст этому свое объяснение. Здесь, правда,  можно вспомнить, как фирма Intel объясняла несущественность ошибки деления с плавающей точкой в процессоре Pentium (подробнее см. [1]). Но общественность и пользователи объяснили Intel, что она не права. И, понеся большие репутационные и финансовые потери,  ей пришлось с этим согласиться и исправить положение.

Далее, обсуждая конкретные программы, мы столкнемся с тем, что нужно считать ошибками. Отличие от ситуации с Intel только в том, что необходимо будет конкретизировать, кто ошибается и ошибается ли и где источник ошибок. Но то, что идет явно не по плану, подтверждают результаты нашего тестирования. Просто ситуация несколько сложнее проблемы одной операции деления FDIV. 

Итак. Выберем для экспериментов три среды: две известные – это MATLAB, SimInTech и одну, известную больше по статьям вашего покорного слуги, - среду параллельного автоматного программирования ВКПа. Для первых двух можно скачать ограниченные версии.  Их возможностей вполне будет достаточно для наших примеров. Ну, а в отношении третьей - придется довериться автору.