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

В этой статье я расскажу о том, как загруженность шины данных влияет на масштабируемость (scalability) приложений. Под масштабируемостью мы будем понимать не только способность многопоточного приложения сокращать свое время выполнения по мере увеличения числа потоков. Мы также добавим сюда и способность однопоточного приложения, запущенного одновременно в несколько копий (instances), выполняться за тот же самый промежуток времени, что и одна копия. Хотя последний пример было бы правильнее охарактеризовать таким свойством как пропускная способность (throughput), так как он относится к «серверному» режиму запуска приложений. Т.е. это такой режим, при котором на сервере запускается однопоточное приложение, каждый раз когда к нему подключается новый клиент. Главная задача при разработке таких приложений — это снижение их зависимости от общих ресурсов, одним из которых может являться шина данных.

Сегодня наличие многоядерных, многопроцессорных и многоузловых систем является уже нормой при обработке большого объёма данных.
Как же можно задействовать все эти вычислительные мощности? Ответ очевиден — распараллелив задачу.
Но тут же встаёт другой вопрос: а как синхронизировать сами подзадачи?

NUMA (Non-Uniform Memory Access — «Неравномерный доступ к памяти» или Non-Uniform Memory Architecture — «Архитектура с неравномерной памятью») — технология совсем не новая. Я бы даже сказала, что совсем старая. То есть, в терминах музыкальных инструментов, это уже даже не баян, а, скорее, варган.
Но, несмотря на это, толковых статей, объясняющих, что это, а главное, как с этим эффективно работать, нет. Данный пост, исправляющий эту ситуацию, предназначен прежде всего для тех, кто ничего не знает про NUMA, но также содержит кое-что интересное и для знатоков-NUMизматов, а главное, он облегчает жизнь мне, инженеру Intel, так как отныне всех интересующихся NUMA русскоязычных разработчиков буду отсылать к нему.

Я поделюсь 30 практиками для достижения максимальной производительности приложений, которые этого требуют. Затем, я расскажу, как применил их для коммерческого продукта и добился небывалых результатов!
Приложение было написано на C# для платформы Windows, работающее с Microsoft SQL Server. Никаких профайлеров – содержание основывается на понимании работы различных технологий, поэтому многие топики пригодятся для других платформ и языков программирования.

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

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

Давайте начнем. Сначала о процессах.

Совсем недавно мы рассматривали написание многопоточных приложений для магазина Windows с помощью Intel Threading Building Blocks(Intel TBB). Там утверждается, что использование кроссплатформенной библиотеки TBB позволяет легко переносить вычислительную часть на другие платформы. Android как раз сгодится для хорошего примера одной из «других платформ», подробности под катом.

VTune Amplifier XE давно известен пользователям своими возможностями глубокого анализа производительности ПО, как на уровне приложения, так и на микроархитектурном уровне.

Инструмент не стоит на месте и активно развивается, улучшаясь и обрастая новым функционалом. В этом посте приведён краткий обзор новых «фич», появившихся как в вышедшем в сентябре VTune Amplifier XE 2013, так и совсем недавно, в последующих обновлениях:

• Анализ циклов
• Текстовый поиск
• Анализ энергоэффективности
• EBS анализ со стеками
• Профилировка Java приложений
• API для пользовательских задач
• Улучшения командного интерфейса

Если ты ИТшник, то нельзя просто так взять и выйти на работу 2-го января: пересмотреть 3-ий сезон битвы экстрасенсов или запись программы «Гордон» на НТВ (дело умственных способностей вкуса).
Нельзя потому, что у других сотрудников обязательно будут для тебя подарки: у секретарши закончился кофе, у МП — закончились дедлайны, а у администратора баз данных — амнезия память.
Оказалось, что инженеры из команды Hadoop тоже любят побаловать друг друга новогодними сюрпризами.

2008

2 января. Упуская подробное описание эмоционально-психологического состояния лиц, участвующих в описанных ниже событиях, сразу перейду к факту: поставлен таск MAPREDUCE-279 «Map-Reduce 2.0». Оставив шутки про число, обращу внимание, что до 1-ой стабильной версии Hadoop остается чуть менее 4 лет.

За это время проект Hadoop пройдет эволюцию из маленького инновационного снежка, запущенного в 2005, в большой снежный com ком, надвигающийся на ИТ, в 2012.
Ниже мы предпримем попытку разобраться, какое же значение январский таск MAPREDUCE-279 играл (и, уверен, еще сыграет в 2013) в эволюции платформы Hadoop.

Как известно, в программном интерфейсе приложений для магазина Windows (Windows Store apps) отсутствуют многие функции работы с потоками, начиная с CreateThread() и заканчивая работой с TLS ключами. И это отличный повод перейти от параллелизма, основанного на системно-зависимых потоках к параллелизму, основанному на задачах. Данный пост излагает пошаговую инструкцию о том, как написать простейший многопоточный пример, который проходит аттестацию для магазина Windows (Windows App Certification Kit validation) и, гипотетически, может быть масштабирован до игрушек космического масштаба. А поскольку используется кроссплатформенная библиотека Intel Threading Building Blocks (Intel TBB, TBB, threadingbuildingblocks.org), то вычислительная часть может быть легко перенесена на другие платформы, и задача будет заключаться только в том, чтобы нарисовать новый красивый графический интерфейс.

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

С помощью вычислительного графа можно установить зависимости между задачами и в какой-то мере программно реализовать «dataflow архитектуру».

В этом посте я опишу, как реализовать такую модель на С++, используя библиотеку Intel Threading Building Blocks (Intel TBB), а именно класс tbb::flow::graph.

«Из пункта А в пункт Б вышел пешеход со скоростью … » Помните такие задачки из школьной программы? Они учили нас умению логически мыслить и, в какой-то степени, составлять алгоритмы, то бишь азам программирования. Но вот все мы подросли, и пришло время решать более взрослые задачи. Из пункта А в направлении пункта Б каждый день вылетает десятки самолетов с различными ценами на билет, маршрутами, бонусными программами… это множество вариантов необходимо просчитать таким образом, чтобы найти оптимальный исходя из предложенных критериев, причем просчитать быстрее других.
Вот вы и познакомились кратенько с условиями конкурса для студентов, аспирантов и школьников «Accelerate Your Code», проводимого компанией Intel в ноябре. Для всех заинтересовавшихся и желающих получить призовой ультрабук от Intel – кнопка внизу.

Данная статья иллюстрирует, как получить доступ к переменным из блока Thread Local Storage в Delphi. Однако принципы нахождения «чужого» блока TLS одинаковы для всех компиляторов Windows и применимы для любых языков программирования, поддерживающих TLS в том виде, как это определяет Windows.

В Delphi, в отличии от глобальных переменных, переменные, объявленные в блоке threadvar, создаются для каждого потока (thread) с возможностью хранить независимые значения. Каждый поток читает и записывает свою копию значений.
Но иногда необходимо прочесть или даже изменить переменные, соответствующие другому треду.
Конечно, лучше изменить алгоритм, чтобы избежать такой необходимости, но решение этой задачи есть.
Все блоки данных (Thread local storage, TLS) находятся в памяти одновременно, но по разным адресам, каждый тред хранит указатель на свою область памяти, поэтому есть возможность найти блок переменных и конкретное значение, принадлежащее любому треду, созданному в пределах текущего процесса.

Использование возможностей параллелизма в настоящее время стало уже обычной практикой в программировании. Однако все языки можно разделить на два типа: те, в которых параллельность применяется вовсю и активно (например, С), и те, которые не вкусили еще в полной мере радостей многопоточности. К последним, в частности, относится JavaScript. Чтобы восполнить этот досадный пробел и пополнить копилку прогрессивного опыта, предлагаем вашему вниманию перевод сообщения из блога Ника Матсакиса, программиста Mozilla Foundation, в котором он делится первыми личными впечатлениями от использования Rivertrail — инструмента параллелизации в JavaScript, созданным Intel.

Джефф Прешинг (Jeff Preshing) опубликовал отличную демонстрацию, как нормальный код C++ возвращает непредсказуемый результат на многоядерных процессорах со слабо упорядоченной обработкой очереди запросов (Weakly-Ordered CPU), то есть на ARM-процессорах. Например, на iPhone или каком-нибудь современном Android-устройстве.

Простая программа C++ с двумя потоками 20.000.000 раз прибавляет единичку к значению, защищённому мьютексом, — и каждый раз на выходе получается разный результат, который меньше 20.000.000!



Как говорится, наш враг — CPU.

За последнюю неделю Хабр пополнился сразу несколькими статьями об игре «Жизнь». Что ж, тогда и я поделюсь своими наработками по этой теме.

Предисловие

Минувшим летом мне довелось побывать на летней школе по параллельному программированию, проводимой НГУ. В рамках школы каждый студент должен был подготовить какой-либо проект по одной из тематик, озвученных на лекциях. Меня заинтересовали клеточные автоматы. У меня первая ассоциация при фразе «клеточный автомат» это именно «Жизнь».
Я понимал, что никому не будет интересно наблюдать за черными клеточками, живущими на экране. Да и слишком просто это для такого проекта. Нужно было придумать что-то принципиально новое. Я решил расширить диапазон своих мыслей и выйти за пределы двухмерного пространства. В прямом смысле. Я подумал, а почему бы не сделать эту игру трехмерной? Ведь это гораздо интереснее!

Компания Adapteva (про которую вы скорее всего слышите в первый раз) планирует сделать суперкомпьютер который будет доступен каждому. С 2008 года они занимаются разработками энергоэффективных RISC-процессоров по заказам производителей смартфонов и других мобильных устройств.

«Мы идем вниз по пищевой цепочке», говорит CEO и основатель Andreas Olofsson. Но Adapteva хочет дать свои технологии напрямую людям через проект на Кикстартере, если они соберут как минимум $750K с конечной целью в $3M.

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

Новый инструмент Intel Advisor XE поможет вам распараллелить приложение, потратив на это минимум сил и времени.

Advisor XE вышел в свет в сентябре этого года в составе пакета для разработчиков Intel Parallel Studio XE 2013. Дословный перевод названия – «советчик» — довольно ёмко описывает его предназначение. Инструмент помогает программисту проанализировать возможности распараллеливания кода: найти наиболее подходящие для этого участки и оценить предполагаемый полезный эффект – а стоит ли вообще за это браться? Кроме того, Advisor XE подскажет, где могут возникнуть ошибки, такие как гонки данных. И всё этого без реальной модификации программы! Но обо всём по порядку.

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

Поскольку ошибки, связанные с синхронизацией потоков крайне сложно отлаживать, то самым эффективным способом тут является предупреждение этих самых ошибок. Для этого используются различные парадигмы программирования на разных уровнях абстракции. Нижним уровнем абстракции будем считать работу с объектами синхронизации (критические секции, мьютексы, семафоры). Верхним — такие парадигмы программирования, как Futures and promises, STM (software transactional memory), обмен асинхронными сообщениями и т.п. Верхний уровень абстракции зачастую всегда основан на нижнем.

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

Здравствуйте, сегодня я хочу рассказать про метод геометрического параллелелизма для решения двумерного уравнения теплопроводности. Для наглядности, некоторые фрагменты будут реализованы при помощи MPI на языке C. Я постараюсь не повторяться с этой и этой статьями, и рассказать что-нибудь новенькое.

В этой серии постов мы попробуем решить одну простую задачу с помощью более-менее актуальных технологий параллельного программирования (Нативные потоки, OpenMP, TBB, MPI, CUDA, OpenCL, OpenACC, Chapel может быть еще что-нить экзотическое. Как бы сравнительно и в hands-on ключе.