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

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

Все обсуждаемые здесь измерения проведены на единственной системе с более или менее случайными характеристиками. Хотя она довольно типична, то есть, не слишком хороша и не слишком плоха, выполненное в таком объеме исследование заведомо не претендует на полноту. Заинтересованный читатель может повторить его в любой подходящей среде, загрузив исходный код с GitHub (ссылка на репозиторий приведена в конце). 

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

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

Друзья, рад представить вам свой новый курс "Циклы и функционалы в R". Курс и все сопутствующие материалы к нему распространяются бесплатно, и являются общедоступными. Во время кризиса лучшей инвестицией времени является обучение.

В данной публикации вы найдёте ссылку на курс, подробное описание и программу курса.

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

Я отвечаю за поддержку одной из наших библиотек с C-интерфейсом, написанной на C и C++. Мой коллега из другого отдела сообщил, что его нагрузочный тест нашей библиотеки на C# в Linux выдаёт ошибку в хитром сценарии: нужно иметь два процесса по пять потоков, делающих некоторые идентичные вызовы. Если процесс один, а потоков много, то проблема не проявляется. Если процессов два, но в каждом по одному потоку, то проблема не проявляется. Путём просмотра исходников нагрузочного теста и логов работы библиотеки удалось перенести проблему в маленький юнит-тест на C++ с использованием нашего API.

Попалась мне задачка оптимизации, а так как я большой фанат Экселя, то и выбор инструмента был скорым. Единственная пакость: Эксель дико медленный. Так, на одну итерацию уходило как минимум 35 минут, а таких итераций планировалось сделать 1275 (как минимум)!

Цель этого небольшого проектика – ускорить исполнение VBA скриптов задействуя все доступные мне железяки: GPU и CPU. Ну и до кучи, так как библиотека моя, была реализована многозадачность.

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

В предыдущей публикации мы рассмотрели некоторые базовые вопросы относительно потоков и пулов потоков и готовы двигаться дальше. Давайте проведём эксперимент и найдём правильный объём работы для пула потоков. Чтобы его издержки не давлели над объёмом полезной работы

⚠️ Материал средней сложности

С другой стороны, показанные примеры доказывают, что на производительность сильно влияет гранулярность элементов работы. Имеется ввиду, конечно же, длительность работы делегатов. Чтобы достичь хороших показателей, гранулярность работы не может быть абы какой: она должна быть правильной. И помимо планирования задач на ThreadPool, планировать их можно также как через TPL так и через какой-либо свой собственный пул потоков. Например, если взять обычный ThreadPool, то можно примерно измерить издержки алгоритмов ThreadPool в тактах Time Stamp Counter счётчика времени (можно, конечно и в чём-то более привычном типа микросекунд, но там на многих сценариях вполне могут быть нули)

Эта текст покрывает ответы на некоторые совсем базовые вопросы и вместе с тем сразу погружает в проблематику получения ответа на вопрос: "как работать лучше? однопоточно, многопоточно или многопоточно, но на ThreadPool?". Ответ на этот вопрос может изначально показаться очень простым и понятным, однако реальность совершенно иная: всё как и везде сильно зависит от ситуации: от типа задачи, от её размера, от прочих условий, которые так просто в голову сами собой не придут.

А потому мы пройдёмся в первую очередь по IO-/CPU-bound операциям, стоимости создания потока, базовым основам работы пула потоков (но только основы), а далее -- углубимся в анализ чёрного ящика: от чего зависит производительность пула потоков? Каков объём работы приемлим для того чтобы в него планировать?

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

Также отмечу, что материал постепенно переходит от начального уровня сложности 🥤 через ⚠️ средний уровень к ☠️ высокому, о чём вы сможете узнать по пиктограммам.

Threading Building Blocks (TBB) — популярная библиотека для параллельного программирования на C++ с открытым исходным кодом, опубликована на GitHub. Пару лет назад команда разработки решилась на глобальный рефакторинг библиотеки (проект TBB revamp), в который удалось вписать долгожданную смену системы сборки с GNU Makefiles на CMake. Свежая версия вышла в релиз в рамках инициативы oneAPI, обновив имя на oneTBB. В этой статье я расскажу про то, как подключить oneTBB в CMake-проект и как собрать, протестировать и установить oneTBB.

Microsoft продолжает развивать свои учебные программы и курсы. Так, в конце прошлого года мы анонсировали возможность сдачи базовых (и некоторых продвинутых) экзаменов на русском языке. Мы также писали о том, что российские ВУЗы начали открывать у себя центры сертификации, чтобы студентам было проще сдавать экзамены по нашим продуктам и платформам, начав свою карьеру с хороших позиций.

Одним из ключевых базовых экзаменов Microsoft в настоящее время является AZ-900, который открывает дверь в мир Azure. Сам экзамен доступен на русском языке, однако долгое время основные материалы были доступны только на английском. Поэтому мы рады анонсировать выход перевода нашего официального руководства по сдачи экзамена AZ-900 на русском языке. И как маленький бонус мы также немного расскажем о книге «Параллельное программирование на C# и .NET Core».

Над переводами данных книг работали наши партнеры из молодой компании Devs Universe, а редактором выступил уже известный нашим читателям Вячеслав Черников, в прошлом эксперт по Xamarin, а в настоящее время архитектор решений Azure.

Здравствуйте, уважаемые читатели.

Хочу написать здесь об одном из своих проектов -- языке Planning C (v2.0). Он является расширением C++, дополняющим базовый язык рядом новых конструкций. В настоящее время проект доступен в репозитории (исходный код прототипного транслятора-препроцессора, множество примеров, конвертер простых программ MPI->Planning C). От других языков Planning C отличается тем, что многие его новые конструкции построены на базе так называемых процедур с планированием повторного входа, которые в первую очередь удобны для программирования некоторых алгоритмов, использующих стек, дек или очередь (но могут использоваться и для программирования произвольных алгоритмов). Язык содержит различные средства алгоритмизации и распараллеливания, более-менее унифицированные и для обычных в наше время компьютеров с многоядерными процессорами, и для видеокарт, и для кластерных систем. Во второй версии языка были введены стандартные средства расширения языка новыми конструкциями, «интеллектуальная» мемоизация и еще некоторые возможности. Надеюсь, кому-нибудь данный язык покажется интересным, может быть даже перспективным для применения и/или развития. Сам я иногда им пользуюсь для быстрого написания некоторых расчетных параллельных программ.

В этой статье напишу лишь о самых базовых возможностях языка, преимущественно на примерах. Если тема вызовет интерес, то, возможно, впоследствии напишу еще одну-две статьи о «продвинутых»/необычных возможностях.

Проект aztotmd основан на классической молекулярной динамике и содержит основной функционал для классических расчётов, но также и ряд экспериментальных особенностей: непостоянное поле сил и излучательный термостат. Программа распараллелена с помощью технологии CUDA. Здесь представлена инструкция по работе с программой.

 Возможности и ограничения

Требуется видеокарта NVidia с computational capability > 2.2. Программа основана на численном интегрировании уравнений движения скоростным алгоритмом Верле. Опции:

+ периодические граничные условия и только в форме прямоугольного параллелепипеда;

+ парные потенциалы: 6 обычных и 1 температуро-зависимый;

+ 3 способа учета электростатики: наивный, суммирование по Эвальду и метод Феннеля и Гецельтера;

+ 2 термостата: Нозе-Гувера и излучательный;

+ валентные связи;

+ валентны углы;

+ внешнее электрическое поле с постоянным градиентом;

+ возможность динамического образования/удаления валентных связей (включая водородные) и валентных углов;

Рецепт параллельных вычислений Fork/Join или Map/Reduce:
- разбить задачу на куски;
- посчитать куски по-отдельности;
- склеить вместе.

Неотрицательная сумма (a, b) -> max(0, a + b) неассоциативна и результат зависит от порядка склейки. Она сломает Fork/Join и результат будет некорректен. Магией моноида починить на Java, SQL и Haskell за 5 минут, но

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

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

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

Что общего между популярным у хоббистов компьютером Синклер ZX Spectrum и космической станцией Juno, которая сейчас вращается вокруг Юпитера? И на одном, и на другом стоит процессор с архитектурой Zilog. На Синклере просто Z80, а на Juno - радиационно стойкий Y180-S. Y180-S спроектировал Монте Далримпл (Monte J. Dalrymple), выпускник Беркли, который проработал 16 лет в Zilog, после чего сделал собственный бизнес, компанию под названием Systemide.

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

В.А.Крюков

[email protected]

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

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

Если опустить первое и самое главное предубеждение относительно питонячьей многопоточности у большинства программистов — что её не существует из-за GIL, — то остается другое, и, наверное, вполне достоверное: что многопоточность — это сложно, и нам этого, пожалуйста, не надо. И знаете что? Так оно и есть. Многопоточность — это сложно, особенно когда выбираешься за пределы стандартных руководств и попадаешь со своей многопоточной поделкой в реальный мир. И, возможно, вам не нужно. Ни здесь, ни далее я не буду обсуждать целесообразность написания многопоточного кода на Python и сразу перейду к тому, как это делать.

Когда я предложил перевести на русский мою последнюю статью Easy Concurrency with Python Shared Objects на английском, поступило предложение "написать в несколько раз короче и понятнее". Просьба более чем обоснована. Поскольку я уже порядка десяти лет пишу многопоточку и БД, то описываемые мной логические связи выглядели самоочевидно, и я ошибочно расчитывал на аудиторию из трех с половиной человек, которые сидят сейчас где-то в яндексе или гугле. Судя по всему, они там и сидят, но тема им не интересна, поскольку в питоне нет настоящих потоков, а значит для этих людей такого языка программирования не существует. Потому я немножко снижаю планку и делаю общий обзор проблематики параллельных вычислений для людей, которые в них разбираются, но не являются экспертами в области.

Из-за чего весь сыр-бор?