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

В мире JVM про корутины знают в большей степени благодаря языку Kotlin и Project Loom. Хорошего описания принципа работы котлиновских корутин я не видел, а код библиотеки kotlin-coroutines совершенно не понятен неподготовленному человеку. По моему опыту, большинство людей знает о корутинах только то, что это "облегченные потоки", и что в котлине они работают через умную генерацию байткода. Таким был и я до недавнего времени. И мне пришла в голову идея, что раз корутины могут быть реализованы в байткоде, то почему бы не реализовать их в java. Из этой идеи, впоследствии, появилась небольшая и достаточно простая библиотека, в устройстве которой, я надеюсь, может разобраться практически любой разработчик. Подробности под катом.

Перевод главы 13 Параллелизм
из книги ‘Expert Python Programming’,
Second Edition
Michał Jaworski & Tarek Ziadé, 2016

Асинхронное программирование

В последние годы асинхронное программирование приобрело большую популярность. Python 3.5 наконец-то получил некоторые синтаксические функции, закрепляющие концепции асинхронных решений. Но это не значит, что асинхронное программирование стало возможным только начиная с Python 3.5. Многие библиотеки и фреймворки были предоставлены намного раньше, и большинство из них имеют происхождение в старых версиях Python 2. Существует даже целая альтернативная реализация Python, называемая Stackless (см. Главу 1 «Текущее состояние Python»), которая сосредоточена на этом едином подходе программирования. Для некоторых решений, таких как Twisted, Tornado или Eventlet, до сих пор существуют активные сообщества, и их действительно стоит знать. В любом случае, начиная с Python 3.5, асинхронное программирование стало проще, чем когда-либо прежде. Таким образом, ожидается, что его встроенные асинхронные функции заменят большую часть старых инструментов, или внешние проекты постепенно превратятся в своего рода высокоуровневые фреймворки, основанные на встроенных в Python.

Машина Тьюринга, как модель автоматных программ

1. Введение

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

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

За основу обсуждения проблем автоматного программирования возьмем недавнюю лекцию Шалыто А.А. [1] и его «программные» статьи к определению парадигмы автоматного программирования [2, 3].

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

go myfunc();                                // Golang

pthread_create(&thread_id, NULL, &myfunc);  /* C with POSIX threads */

spawn(modulename, myfuncname, [])           % Erlang

threading.Thread(target=myfunc).start()     # Python with threads

asyncio.create_task(myfunc())               # Python with asyncio

Есть много вариантов нотации и терминологии, но одна семантика — запустить myfunc параллельно основной программе и продолжить родительский поток выполнения (англ. "Control Flow")

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


— Меня зовут Сева Миньков. Я работаю в отделе облачной инфраструктуры поискового департамента. Занимаюсь в основном бэкендом. Пишу на разных языках, но чаще всего это Java и языки, запускаемые на Java Virtual Machine (JVM).

Сегодня коротко расскажу о том, как я реализовывал семафор на основании объекта синхронизации «Событие».

Сначала пройдусь по определениям.

1. Что такое синхронизация и зачем она нужна?

Очевидно, что набор действий мы можем выполнять несколькими способами. Самые простые — последовательно и параллельно. Параллельности выполнения определенных действий можно достигнуть за счет запуска различных потоков (threads). Идея простая: назначаем каждому потоку какое-то элементарное (или не очень) действие и запускаем их в определенном порядке. Вообще говоря, запустить мы их можем и все одновременно — выигрыш по времени мы, конечно, получим. Это понятно: одно дело вывести 10 000 слов одно за другим, а другое дело одновременно выводить, например, 100 слов. 100-кратный выигрыш по времени (плюс-минус, без учета задержек и проч.). Но исходная задача может предполагать строгую последовательность действий.

Например:

• Открыть файл
• Записать текст в файл
• Закрыть файл

Пример специально взят тепличный (понятно, что никакой параллелизм тут не нужен, все можно просто выполнить последовательно), но в качестве учебной задачи он вполне сойдет, а главное, на его примере отлично видна потребность в последовательном выполнении. Или вот другой пример, немного отличающийся:

• Сгенерировать три последовательности случайных чисел
• Последовательно вывести их на экран

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

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

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

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

Совсем скоро, 29-30 ноября в Санкт-Петербурге и 06-07 декабря — в Москве мы запустим шестой семинар по .NET. На этот раз — по теме многопоточки и конкурентности. Мы уже писали об этом пару раз на Хабре, но сегодня есть отдельный повод для этого: на семинаре настоящий эксклюзив. Будет описана работа гибридного примитива синхронизации: Monitor. Да, всем привычная вещица достойна отдельного доклада. Ведь он в своей работе учитывает и частоту процессора и количество ядер, учитывает lock convoy/starvation и вообще, очень сложен.

А в конце статьи развлечения ради предложу пройти парочку QUIZов по многопоточке.

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).

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

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

Совсем скоро, 29-30 ноября в Санкт-Петербурге и 06-07 декабря — в Москве мы запустим шестой семинар по .NET. На этот раз — по теме многопоточки и конкурентности. Мы уже писали об этом пару раз на Хабре, но сегодня — День Программиста и есть отличный повод дать вам всем комплимент: скидку на его посещение.

У меня для вас есть новость: мы с Андреем Гончаровым, моим хорошим другом и соратником решили сделать для вас доклады по lock-free, выступая вместе. Мне показалось, это должно сильно оживить атмосферу выступления. Андрей сейчас закапывается в эту тему так, что иногда его приходится даже останавливать: доклады будут очень интересными и полезными.

Юрий Власов, мой второй коллега нашёл библиотеку Microsoft.VisualStudio.Threading, которую с удовольствием использует в проектах. Он решил поведать вам о её богатых возможностях и применимости в различных задачах. Этот доклад отлично завершит тему lock-free, закрыв вопросы теории, оценки сложностей, анализа существующих алгоритмов и построения собственных вопросом хорошей реализации в виде промышленной библиотеки.

В честь Дня Программиста мы ввели промокод: CLRiumDevDay. Он действует всего-лишь два дня, когда можно забронировать билеты. Далее — вы имеете 5 дней на оплату билетов.
Первый день — скидка = 25%, второй = 15%

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

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

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

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

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

Наконец-то в России вышел учебник по SystemVerilog уровнем выше чем для начинающих. Учебник описывает технологии и приемы, которые спрашивают на интервью в NVidia, Intel, AMD, Apple и другие электронные компании: использование concurrent assertions и functional coverage, что сейчас требуют не только от инженеров по верификации, но и от дизайнеров микросхем; алгоритм работы симулятора с дельта-циклами; вменяемое объяснение static timing analysis; схемы коммуникации аппаратных блоков через аппаратные очереди; реализацию этих коммуникаций с помощью конечных автоматов с трактами данных и т.д.

В главе про последнее российского читателя может озадачить упоминание «политкорректной системы». Что бы это значило? Это вероятно намек на казус, который произошел в округе Лос-Анжелес в 2003 году. Чиновники Лос-Анджелеса попросили производителей, поставщиков и подрядчиков прекратить использование терминов «master/slave» («хозяин» и «раб») в отношении компьютерного оборудования, так как одному из работников округа эти термины напомнили про рабовладельческое прошлое.

Сейчас авторы технической литературы избегают терминов master/slave. В современной Америке работают и афро-американские инженеры (например София Мвокани из Камеруна — на фото слева), и использование старых терминов выглядит архаично, как выглядели бы например термины «пан/холоп» в украинской технической литературе вместо принятых «провідний/ведений» (рус. «ведущий/ведомый»).

Это не первый раз, когда в российском электронном образовании появляется тема борьбы афро-американцев за гражданские права. Например Татьяна Волкова, известный специалист по образованию в электронике, носит маечку с эмблемой «Черных Пантер», калифорнийского движения, которое в свое время сочло мирный протест недостаточным, и занялось вооруженным протестом.



Полное изображение эмблемы под кожанкой Татьяны Александровны — под катом, но в основном я буду рассказывать про дельта-циклы и конечные автоматы:

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

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

Введение

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

В прошлой статье я с помощью скрэпинга-парсинга собрал с сайтов IMDB и Кинопоиск оценки фильмов и сравнил их. Репозиторий на Github.

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

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

[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) работает, и, поэтому, могут сделать осознанный выбор.

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