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

Это расшифровка-перевод доклада Саши Гольдштейна, признанного лучшим на конференции DotNext 2016 Piter. С годами этот доклад стал лишь актуальнее прежнего: появление Mac на ARM-процессорах — еще один пример, почему разработчикам сегодня нужно думать не только о x86-архитектуре.

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

То, что подходит процессорам Intel на архитектурах x86 и x86-64, может не подойти другой архитектуре. Как только вы перенесете свой код на другой процессор, например, на ARM для iPhone и Android, есть вероятность, что он перестанет работать как надо. Проблемы могут быть как очевидными (воспроизводиться с первого-второго раза), так и не очень (возникать только раз в миллион итераций). Вполне вероятно, что такие баги могут добраться до продакшна. Сегодня .NET и, конечно, C++ можно использовать не только на Windows и Intel, но и на других платформах, так что доклад будет полезен многим разработчикам.

Дисклеймер: статья предназначена для продвинутых читателей. Смотрите на свой страх и риск. За частое упоминание барьеров памяти и изменения порядка исполнения инструкций она получила возрастное ограничение 18+.

https://www.youtube.com/playlist?list=PLwr8DnSlIMg0KABru36pg4CvbfkhBofAi

Как-то на Хабре мне попалась довольно любопытная статья “Научно-технические мифы, часть 1. Почему летают самолёты?”. Статья довольно подробно описывает, какие проблемы возникают при попытке объяснить подъёмную силу крыльев через закон Бернулли или модель подъёмной силы Ньютона (Newtonian lift). И хотя статья предлагает другие объяснения, мне бы всё же хотелось остановиться на модели Ньютона подробнее. Да, модель Ньютона не полна и имеет допущения, но она даёт более точное и интуитивное описание явлений, чем закон Бернулли.

Основной недостаток этой модели — это отсутствие взаимодействия частиц газа друг с другом. Из-за этого при нормальных условиях она даёт некорректные результаты, хотя всё ещё может применяться для экстремальных условий, где взаимодействием можно пренебречь.

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

Перед тем как мы начнём, я бы хотел сразу обозначить, что это статься не о физике самой модели. Эта статья о GPGPU-программировании. Мы не будем рассматривать физические свойства самой модели, потому что она груба и не подходит для настоящих расчётов. И всё же, эта неточная модель даёт куда более интуитивное описание явления подъёмной силы, чем закон Бернулли.

Вашему вниманию простой C++ template аллокатора с потокобезопасным циклическим буфером.

Вся реализация в одном заголовочном .h файле: [fast_mem_pool.h]

Фишки, чем этот аллокатор лучше сотни подобных — под катом.

Вы хотите узнать, как получить работу по проектированию электроники космического корабля? Мне надавно пришло предложение поинтервьироваться на позицию FPGA designer для Blue Origin (см. выше). Лично мне такая позиция не нужна (у меня уже есть позиция ASIC designer-а в другой компании), но я отметил, что технические требования к претендентам в Blue Origin точно совпадают с содержанием семинара для школьников и младших студентов, который пройдет 15-17 сентября на выставке ChipEXPO в Сколково, с поддержкой от РОСНАНО. Хотя разумеется на семинаре мы коснемся технологий Verilog и FPGA только на самом начальном уровне: базовые концепции и простые, но уже интересные, примеры. Чтобы устроится после этого в Blue Origin, вам все-же потребуется несколько лет учебы и работы.

Из-за короновируса семинар будет удаленный, поэтому принять участие смогут не только школьники и студенты Москвы, но и всей России, Украины, Казахстана, Калифорнии и других стран и регионов. Физически проводить лекции и удаленно помогать участникам будут преподаватели и инженеры МИЭТ, ВШЭ МИЭМ, МФТИ, Черниговского Политеха, Самарского университета, IVA Technologies и fpga-systems.ru.

Для участия сначала, еще до семинара, нужно пройти три части теоретического курса от РОСНАНО, под общим названием «Как работают создатели умных наночипов»: «От транзистора до микросхемы», «Логическая сторона цифровой схемотехники», «Физическая сторона цифровой схемотехники». Этот курс необходим, чтобы вы понимали, что вы делаете, по время практического семинара. По получению сертификата окончания теоретического онлайн-курса, вы можете зайти в офис РОСНАНО в Москве и получить бесплатную плату для практического семинара (если они останутся, преимущество имеют школьники). С этой платой вы можете работать дома, до, во время и после семинара в Сколково.

Как получить плату, подготовится к семинару и что на нем будет:

И снова здравствуй. Какое-то время назад я писал о другом малоизвестном инструменте для любителей высокой производительности — System.IO.Pipelines. По своей сути, рассматриваемый System.Threading.Channels (в дальнейшем «каналы») построен по похожим принципам, что и Пайплайны, решает ту же задачу — Производитель-Потребитель. Однако имеет в разы более простое апи, которое изящно вольется в любого рода enterprise-код. При этом использует асинхронность без аллокаций и без stack-dive даже в асинхронном случае! (Не всегда, но часто).

Цель данной статьи – поднять вопросы распараллеливания кода программы для численного моделирования методом молекулярной динамики (МД) с помощью технологии CUDA. Зачем это вообще нужно, ведь уже существуют программные пакеты по МД, работающие в том числе и на CUDA? Дело в том, что я развиваю свою собственную концепцию «непостоянного поля сил» (non-constant force field), которая не реализована в существующих МД-программах.

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

Итак, что же такое молекулярная динамика? На Хабре уже есть несколько постов на эту тему, например здесь или вот здесь. Кратко, МД – это метод, позволяющий моделировать движение множества частиц (в том числе атомов, ионов, молекул) и рассчитывать коллективные свойства системы, зависящие от этого движения. Как это работает? Допустим для множества из N частиц заданы некоторые начальные координаты, скорости, массы и (главное!) законы взаимодействия между ними. Изменяем координаты согласно скоростям. На основе законов взаимодействия вычисляем силы, действующие между частицами. Раз знаем силу и массу – знаем ускорение. Поправляем скорость с учетом ускорения. И снова переходим к изменению координат. И так повторяем тысячи раз, пока не надоест не наберем достаточную статистику.

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

В книжке есть интервью команды из Питера, которую Intel привез в свою штаб-квартиру в Silicon Valley за их победу на конкурсе Innovate FPGA. Книжку «Цифровой синтез: практический курс» поддержала ведущая компания в автоматизации пректирования микросхем Cadence Design Systems (на фото выше сибирячка Наташа стоит с FPGA платой перед штаб-квартирой Cadence в Silicon Valley — в посте будет ее видео).

Лабник делался под эгидой Высшей Школы Экономики / МИЭМ (Александр Романов, Вероника Прохорова и Игорь Агамирзян), при этом разные главы в нем писали преподаватели Московского, Киевского и Самарского университетов, Питерского ИТМО, Черниговского политеха и Университета Калифорнии Санта-Круз (Чарльз Данчек, вечернее отделение в Silicon Valley). В создании учебника приняли участие инженеры российских компании IVA Technologies (Станислав Жельнио, аппаратный ускоритель ИИ + образовательный проект schoolMIPS) и ФГУП НПЦАП
(отделение Роскосмоса), американских компаний MIPS, Juniper Networks и AMD. Издало учебник ДМК-Пресс.

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

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

В этой статье я расскажу:

• Что за задача такая, о которой идет речь;
• Подробнее об интегральных изображениях;
• Как использовать интегральные изображения для приближенного решения гравитационной задачи N тел применительно к дискретному полю импульсов (масс-скоростей);
• Какой недостаток имеет это решение и как его исправить;
• И, наконец, как за константное время вычислить центр масс для произвольного региона.

В прошлом году в Санкт-Петербурге прошла первая конференция Hydra, посвящённая параллельным и распределённым системам. С докладами выступали лауреаты премии Дейкстры и премии Тьюринга (Лесли Лэмпорт, Морис Херлихи и Майкл Скотт), создатели компиляторов и языков программирования (C++, Go, Java, Kotlin), разработчики распределённых баз данных (Cassandra, CosmosDB, Yandex Database), а также создатели и исследователи алгоритмов и структур данных (CRDT, Paxos, wait-free data structures). В общем, на этом месте уже можно брать отпуск, сворачивать окно IDE, открывать плейлист на YouTube с лучшими докладами Hydra 2019 — и пусть task scheduler немного подождёт.

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

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

Прим. перев.: Содержимое этой статьи не совсем типично для нашего блога. Однако, как многим известно, etcd находится в самом сердце Kubernetes, из-за чего данное исследование, проведённое независимым консультантом в области надёжности, оказалось интересным и в среде инженеров, эксплуатирующих данную систему. Кроме того, оно интересно в разрезе того, как Open Source-проекты, уже зарекомендовавшие себя в production, совершенствуются даже на таком, весьма «низком», уровне.



Хранилище пар «ключ-значение» (KV) etcd представляет собой распределённую базу данных, основанную на алгоритме консенсуса Raft. В ходе анализа, проведенного в 2014 году, мы обнаружили, что etcd 0.4.1 по умолчанию была подвержена так называемым stale reads (операциям чтения, возвращающим старое, неактуальное значение из-за запаздывания синхронизации — прим. перев.). Мы решили вернуться к etcd (в этот раз — к версии 3.4.3), чтобы снова детально оценить ее потенциал в области надежности и безопасности.

"Цветорасширитель для ZX-Spectrum" — так называлась статья, опубликованная в эхе fido7.zx.spectrum 3 августа 1997 года. Статья описывала идею решения одной из главных проблем платформы ZX-Spectrum — конфликта атрибутов (attribute clash). Публикация вызвала в то время определенный интерес, про технические детали и историю вопроса я и хотел бы рассказать.

Не буду залезать глубоко в технические подробности и просто структурно опишу идею и решение.

Qt — чрезвычайно мощный и удобный фреймворк для C++. Но у этого удобства есть и обратная сторона: довольно много вещей в Qt происходят скрыто от пользователя. В большинстве случаев соответствующая функциональность в Qt «магически» работает и это приучает пользователя просто принимать эту магию как данность. Однако когда магия все же ломается то распознать и решить неожиданно возникшую на ровном казалось бы месте проблему оказывается чрезвычайно сложно.

Эта статья — попытка систематизации того как в Qt «под капотом» реализована работа с потоками и о некотором количестве неочевидных подводных камней связанных с ограничениями этой модели.

Основы
Thread affinity, инициализация и их ограничения
Главный поток, QCoreApplication и GUI
Rendering thread
Заключение

Доброго времени суток. В этот раз поговорим на тему, в которой начинал разбираться каждый уважающий себя адепт языка C# — асинхронное программирование с использованием Task или, в простонародье, async/await. Microsoft проделали хорошую работу — ведь для того, чтобы использовать асинхронность в большинстве случаев нужно лишь знание синтаксиса и никаких других подробностей. Но если лезть вглубь, тема довольно объемная и сложная. Ее излагали многие, каждый в своем стиле. Есть очень много классных статей по этой теме, но все равно существует масса заблуждений вокруг нее. Постараемся исправить положение и разжевать материал настолько, насколько это возможно, не жертвуя ни глубиной, ни пониманием.

Почему мы вообще хотим писать конкурентный код? Потому что процессоры перестали расти по герцовке и начали расти по ядрам. С каждым годом увеличивается количество ядер процессора, и мы хотим их эффективно утилизировать. Go — тот язык, который создан для этого. В документации так и написано.

Мы берём Go, начинаем писать конкурентный код. Конечно, ожидаем, что легко сможем обуздать мощь каждого ядра нашего процессора. Так ли это?

Меня зовут Артемий. Этот пост — вольная расшифровка моего доклада с GopherCon Russia. Он появился как попытка дать толчок людям, которые хотят разобраться, как писать хороший, конкурентный код.

Видео с конференции GopherCon Russia

Введение

Несколько лет назад, мы решили, что настало время поддержать SIMD код в .NET. Мы представили пространство имен System.Numerics с типами Vector2, Vector3,Vector4 и Vector<T>. Эти типы представляют API общего назначения для создания, доступа и оперирования векторными инструкциями, когда это возможно. Они, так же, обеспечивают программную совместимость для тех случаев, где аппаратное обеспечение не поддерживает подходящих инструкций. Это позволило, с минимальным рефакторингом, векторизовать ряд алгоритмов. Как бы там ни было, общность такого подхода делает его сложным в применении с целью получения полного преимущество от всех доступных, на современном аппаратном обеспечении, векторных инструкций. В дополнении, современное аппаратное обеспечение предоставляет ряд специализированных, не векторных, инструкций, которые могут значительно улучшать производительность. В этой статье я расскажу, как мы обошли эти ограничения в .NET Core 3.0.

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

День Программиста традиционно отмечается в 256-й день года. Число 256 выбрано потому, что это количество чисел, которые можно выразить с помощью одного байта (от 0 до 255).

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

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

Сколько процессорных ядер Intel в вашем компьютере? Если вы пользуетесь системой на базе Intel, то в абсолютном большинстве случаев к вашему ответу надо будет прибавить единицу. В состав почти всех процессоров Intel — от Atom и до Xeon E3, естественно, не пропуская Core, уже много лет входит интегрированное графическое ядро Intel Graphics, являющееся по сути полноценным процессором, и соответственно, способное не только показывать на экране картинки и ускорять видео, но и выполнять «обычные» вычисления общего назначения. Как это можно эффективно использовать? Смотрите под катом.

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

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

Конечно, как автор проповеди, я иду на риск. Вам может нравиться язык, который я высмеиваю! Безрассудный памфлет мог бы неосторожно привлечь в мой блог яростную толпу черни с вилами и факелами наперевес.

Чтобы защититься от праведного огня и не оскорбить ваши (вероятно деликатные) чувства, я буду рассказывать о языке...

Предисловие к переводу

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

Введение

Пространство имен System.Threading.Tasks и класс Task впервые были представлены в .NET Framework 4. С тех пор, этот тип, и его производный класс Task<TResult>, прочно вошли в практику программирования на .NET, стали ключевыми аспектами асинхронной модели, реализованной в C# 5, с его async/await. В этой статье я расскажу о новых типах ValueTask/ValueTask<TResult>, которые были введены с целью повышения производительность асинхронного кода, в тех случаях, когда ключевую роль играют накладные расходов при работе с памятью.

В своей практике я часто встречаю, в различном окружении, код вроде того, что приведен ниже:

[1] var x = FooWithResultAsync(/*...*/).Result;

//или
[2] FooAsync(/*...*/).Wait();

//или
[3] FooAsync(/*...*/).GetAwaiter().GetResult();

//или
[4] FooAsync(/*...*/)
    .ConfigureAwait(false)
    .GetAwaiter()
    .GetResult();

//или
[5] await FooAsync(/*...*/).ConfigureAwait(false)

//или просто
[6] await FooAsync(/*...*/)

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

• Первая группа, это те, кому ничего не известно о возможных проблемах с вызовом Result/Wait/GetResult. Примеры (1-3) и, иногда, (6), типичны для программистов из этой группы;
• Ко второй группе относятся программисты, которым известно о возможных проблемах, но они не знают причин их возникновения. Разработчики из этой группы, с одной стороны, стараются избегать строк вроде (1-3 и 6), но, с другой, злоупотребляют кодом вроде (4-5);
• Третья группа, по моему опыту самая малочисленная, это те программисты, которые знают о том, как код (1-6) работает, и, поэтому, могут сделать осознанный выбор.

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