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

Почему мы вообще хотим писать конкурентный код? Потому что процессоры перестали расти по герцовке и начали расти по ядрам. С каждым годом увеличивается количество ядер процессора, и мы хотим их эффективно утилизировать. 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) работает, и, поэтому, могут сделать осознанный выбор.

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

Функционал Async/Await появился в C# 5, чтобы улучшить скорость отклика пользовательского интерфейса и веб-доступ к ресурсам. Другими словами, асинхронные методы помогают разработчикам выполнять асинхронные операции, которые не блокируют потоки и возвращают один скалярный результат. После многочисленных попыток Microsoft упростить асинхронные операции, шаблон async/await завоевал хорошую репутацию среди разработчиков благодаря простому подходу.

Существующие асинхронные методы значительно ограничены тем, что должны возвращать только одно значение. Давайте рассмотрим некий обычный для такого синтаксиса метод async Task<int> DoAnythingAsync(). Результатом его работы является некоторое одно значение. Из-за такого ограничения нельзя использовать эту функцию с ключевым словом yield и асинхронным интерфейсом IEnumerable<int> (чтобы вернуть результат асинхронного перечисления).

Я присоединился к сообществу Erlang около 10 лет назад, посреди первой фазы хайпа. Нам говорили, что Erlang — это будущее конкурентности и параллелизма. Реализовать их на этом языке проще и быстрее всего, и вы ещё получите бесплатную распределённость. В то время будущее казалось невероятным. Виртуальная машина недавно получила поддержку SMP, но чтобы действительно использовать все процессоры, приходилось запускать на одном компьютере несколько виртуальных машин.

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

ПривеТ! Решил поделиться с читателями своими небольшими экспериментами с системами частиц в трехмерном пространстве. За основу взял публикацию на Хабре об экспериментах с частицами в 2D пространстве.

Недавно были анонсированы сразу два мероприятия о разработке многопоточных и распределённых систем: конференция Hydra (11-12 июля) и школа SPTDC (8-12 июля). Люди, которым близка эта тема, понимают, что приезд в Россию Лесли Лэмпорта, Мориса Херлихи и Майкла Скотта — важнейшее событие. Но возникали другие вопросы:

• Чего ждать от конференции: «академичности» или «продакшна»?
• Как соотносятся школа и конференция? На кого рассчитано то и другое?
• Почему они пересекаются по датам?
• Будут ли они полезны тем, кто не посвятил всю жизнь распределённым системам?

Обо всём этом хорошо известно человеку, благодаря которому Hydra появилась: нашему директору Алексею Федорову (23derevo). Он и ответил на все вопросы.

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

Во всяком случае, так говорит руководитель мобильной разработки Prisma Андрей Володин. А еще о том, как идеи перетекают в мобильную разработку из GameDev, чем отличаются парадигмы, почему в Android нет нативного размытия — да много еще чего, продуктивный вышел выпуск AppsCast. Под катом поговорим про доклад Андрея на AppsConf без спойлеров.

Всем привет!

В данном руководстве хочу рассказать как подружить CUDA C/С++ и Rust. И в качестве примера напишем небольшую программу на Rust для вычисления скалярного произведения векторов, вычисление скалярного произведения будет производиться на GPU с использованием CUDA C.

Кому интересно под кат!

Это Лесли Лэмпорт — автор основополагающих работ в распределённых вычислениях, а ещё вы его можете знать по буквам La в слове LaTeX — «Lamport TeX». Это он впервые, ещё в 1979 году, ввёл понятие последовательной согласованности, а его статья «How to Make a Multiprocessor Computer That Correctly Executes Multiprocess Programs» получила премию Дейкстры (точней, в 2000 году премия называлась по-старому: «PODC Influential Paper Award»). Про него есть статья в Википедии, где можно добыть ещё несколько интересных ссылок. Если вы в восторге от решения задач на happens-before или проблемы византийских генералов (BFT), то должны понимать, что за всем этим стоит Лэмпорт.

А ещё он скоро приедет на нашу новую конференцию о распределённых вычислениях — Hydra, которая состоится 11-12 июля в Санкт-Петербурге. Давайте посмотрим, что это за зверь такой.

Не так давно я прочёл фантастический роман «Задача трёх тел» Лю Цысиня. В нём у одних инопланетян была проблема — они не умели, с достаточной для них точностью, вычислять траекторию своей родной планеты. В отличии от нас, они жили в системе из трёх звёзд, и от их взаимного расположения сильно зависела «погода» на планете — от испепеляющей жары до леденящего мороза. И я решил проверить, можем ли мы решать подобные задачи.

Введение от переводчика

В данной статье речь идёт об Erlang, но всё сказанное в равной степени применимо и к Elixir — функциональному языку, работающему поверх той же виртуальной машины BEAM. Он появился в 2012 году и сейчас активно развивается. Elixir получил более привычный большинству синтаксис плюс обширные возможности метапрограммирования, сохранив преимущества Erlang.

Это свободная расшифровка (или долгий парафраз?) моей презентации на организованной Genetec конференции ConnectDev'16.

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

Во время разработки meshoptimizer частенько возникает вопрос: «А может этому алгоритму использовать SIMD?»

Библиотека ориентирована на производительность, но SIMD не всегда обеспечивает значительные преимущества по скорости. К сожалению, SIMD может сделать код менее переносимым и менее ремонтопригодным. Поэтому в каждом конкретном случае приходится искать компромисс. Когда первостепенное значение имеет производительность, приходится разрабатывать и поддерживать отдельные реализации SIMD для наборов инструкций SSE и NEON. В других случаях нужно понять, каков эффект от применения SIMD. Сегодня мы попытаемся ускорить меш-рационализатор (sloppy mesh simplifier) — новый алгоритм, недавно добавленный в библиотеку — используя наборы инструкций SSEn/AVXn.

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

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

Но все уже осознали, ведь жить с этим как-то надо. А Java программисты даже неплохо живут. Потому что в Java есть модель памяти — Java Memory Model (JMM), которая предоставляет достаточно простые правила для написания корректного многопоточного кода.

И правил этих достаточно для большинства программ. Если вы их не знаете, но пишите или хотите писать многопоточные программы на Java, то лучше как можно скорее ознакомиться с ними. А если знаете, но вам не хватает контекста или интересно узнать откуда растут ноги у JMM, тогда статья может вам помочь.

Не так давно мимо нас пробегала неплохая статья об ужасном состоянии производительности современного ПО (оригинал на английском, перевод на Хабре). Эта статья напомнила мне об одном антипаттерне кода, который встречается весьма часто и в общем кое-как работает, но приводит к небольшим потерям производительности то тут, то там. Ну, знаете, мелочь, пофиксить которую руки никак не дойдут. Беда лишь в том, что десяток таких «мелочей», разбросанных в разных местах кода начинают приводить к проблемам типа «вроде у меня последний Intel Core i7, а прокрутка дёргается».

Я говорю о неверном использовании функции Sleep (регистр может отличаться в зависимости от языка программирования и платформы). Итак, что же такое Sleep? Документация отвечает на этот вопрос предельно просто: это пауза в выполнении текущего потока на указанное количество миллисекунд. Нельзя не отметить эстетическую красоту прототипа данной функции:

void Sleep(DWORD dwMilliseconds);

Всего один параметр (предельно понятный), никаких кодов ошибок или исключений — работает всегда. Таких приятных и понятных функций очень мало!


Что же могло пойти не так? То, что программисты используют эту замечательную функцию не для того, для чего она предназначена.

Фьютекс (futex — сокращение от «Fast userspace mutex») — это механизм, предложенный разработчиками Linux из IBM в 2002 году и вошедший в ядро в конце 2003 года. Основной идеей было предоставить более эффективный способ синхронизации пользовательских потоков с минимальным количеством обращений к ядру ОС.

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

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