Альтернативный HPC или новый PU

Уже несколько лет в сфере высокопроизводительных вычислений (HPC, High Perfomance Computing) не смолкают разговоры о реконфигурируемых вычислителях (RPU,reconfigurable processing unit) и об общецелевых вычислениях на граф.процессорах (GPGPU). И если о GPGPU говорят достаточно часто и много, то про RPU, вроде бы как известно поменьше. В журнале IT Business Edge появилась обзорная заметка о реконфигурируемых вычислениях (всего 7 абзацев). Вкратце идея RPU заключается в следующем: использование ПЛИС(FPGA) в качестве сопроцессоров. Т.е. к обычному CPU цепляются несколько ПЛИС и все это вместе называется реконфигурируемыми вычислениями. Почему "реконфигурируемыми" - дело в том, что ПЛИС позволяют изменять(говорят ещё перепрограммировать,перепрошивать, конфигурировать) свою структуру в процессе работы. Таким образом, мы можем во время работы нашего приложения специализировать ПЛИС-сопроцессоры для решения наших конкретных задач в данный момент времени. Всё это позволяет достигать значительного прироста производительности. (На некоторых узкоспециализированных задачах(поиск шаблонов в ДНК или задачи распознавания (кстати, тоже по сути дела поиск шаблонов)) RPU дают прирост производительности в 1000 раз по сравнению с вычислениями на обычных CPU). Необходимо конечно отметить, что программирование ПЛИС дело не простое и не каждую программу можно легко и просто заточить для исполнения на ПЛИС. В этой области активно используются такие языки параллельного программирования как VHDL и Verilog. В роли интерфейсов CPU <-> RPU(FPGA) могут выступать, в том числе Ethernet и PCI. Кроме того, сами ПЛИС за счет все той же перепрограммируемости позволяют разработчикам быстро создавать дешевые прототипы своих разработок и экспериментировать с ними (конечно, это требует определенных навыков и знаний, а под час и, если хотите, мастерства. собственно также как и везде).
В области GPGPU разработок (коими я сам практически не занимаюсь) мое внимание привлекла заметка в блоге John West-а (www.IncideHPC.com) о том, что NVidia создала плугин для MATLAB на базе своей CUDA SDK (фреймворк для программирования Nvidia-GPU на языке C). Этот плугин позволяет здорово ускорить процессы вычислений в среде MATLAB. Приводятся цифры - несколько дней моделирования однородных двумерных турбулентных потоков при разрешении 1024х1024 без CUDA и 4-е часа при её использовании. И это ещё не придел, заявляют представители NVidia.

Ужасный Google или Непростое поглощение PeakStream

Не так давно мы уже писали о том, что Google приобрел PeakStream, несколько заметок по этому поводу появилось и в российской web-периодике - здесь и здесь. Теперь же хочется представить вашему вниманию альтернативный взгляд на это событие от западного аналитика Эшли Ванса.

---

Кому нужны нефть и газ, когда есть google-ads?

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

Мы уверены, что такие поглощения будут продолжаться и дальше, если индустрия будет столь недальновидна. Стратап PeakStream, существующий на рынке около 2 лет, занимался разработкой инструментов, облегчающих распараллеливание однопоточных приложений на многоядерных x86 процессорах Intel и AMD, а в будущем и на GPGPU() карточках от Nvidia и AMD\ATI.

Защитники PeakStream’a и его технологий, а также технологий, которые разрабатываются сейчас пока ещё независимой компанией RapidMind, говорят об этих компаниях как об ангелах воплоти, которые уберегали программистов от жесткого ручного хардкодинга многопоточных моделей. Критики же такого подхода говорят о том, что такие технологии по сути дела являются морфием для программистов, что они реально не решают стоящих перед ИТ-сообществом проблем и что такая халява все равно долго не продержится.

Согласно нашим данным, на протяжении двух последних месяцев PeakStream вела активные переговоры о поглощении с несколькими крупными игроками ИТ-рынка. Мы не можем назвать полный перечень этих компаний, но разумно предположить, что в этот список вошли Intel, AMD, Nvidia, Sun Microsystems, IBM, HP и Microsoft. Неправда ли, именно производители ПО и микропроцессоров выглядят наиболее подходящими кандидатами на заключении такой сделки, поскольку они могли обеспечить значительную поддержку инструментам PeakStream’a и как следствие оказать благотворное влияние на индустрию в целом.

Вместо этого инженеры PeakStream’a отправились оказывать благотворное влияние на Google.

Недавно из достоверных источников нам стало изветсно, что Google не собирается заниматься распространением и продажей инструментов, разработанных PeakStream. Причина, думаю, вам понятна – основной бизнес Google сосредоточен в области рекламы и поисковых сервисов.

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

Нам удалось проследить судьбу некоторых из бывших пикстримщиков, которые теперь работают в Google. Один из них также как и раньше работает над JIT’ом для многоядерных процессоров. Другой работает над компилятором для x86 платформы, а ещё один переключился на алгоритмы генерации случайных чисел с использованием GPU и CPU с упором на HPC(high performance computing) область.
Приобретение Googl’ом этих талантливых инженеров – это ещё один пример хитрого шага этой умной компании, которая все больше и больше обгоняет Yahoo! и Microsoft. Нет, ну вы можете всерьез представить, что Yahoo! или Microsoft будут приобретать компанию, наподобие PeakStream, для того чтобы улучшить свои поисковые сервисы или лежащие в их основе файловые системы. Вряд ли мы когда-либо станем свидетелями столь удивительных событий.

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

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

И вот теперь Google запросто покупает недешевую PeakStream как будто бы просто потому, что пикстримщики могут ей пригодиться. Такая покупка про запас. Если бы у Google было столько денег лет пять назад, то вполне возможно, что VMware стала бы просто одной из примочек к Goobuntu, к счастью этого не случилось и сейчас VMware по сути дела дефакто одна из самых применяемых на практике систем виртуализации. И кто знает, может быть в следующем году Google захочется купить Sun, чтобы заполучить нескольких талантливых Java программистов или заграбастать Red Hat, для того чтобы Linux в Google работал получше, да постабильнее.

Вообщем если нас послушать, то покупка PeakStream’a совсем не рядовое поглощение, однако с другой стороны теперь на рынке осталась всего лишь одна компания подобного профиля(single-threaded-to-multi-threaded code) - RapidMind.

Думается, что производителям серверов больше бы понравилось, если бы в этом сегменте рынка была хоть какая-нибудь конкуренция. Она, как известно, всегда способствует прогрессу, а именно этого сейчас так не хватает в нише инструментов для «упрощенного» параллельного программирования. Если бы PeakStream остался в живых, то года через два мы вполне бы могли наблюдать кучу HPC приложений, заточенных под GPGPU или многоядерные процессоры. Это позволило бы находить больше нефти и газа, создавать более безопасные автомобили, в конце концов, это сказалось бы и на наших с вами бюджетах тоже.

Вместо этого производители серверов вынуждены молиться на RapidMind, которой предстоит в одиночку решить все эти сложные проблемы, если конечно её не купит ещё какой-нибудь Google. И тогда уж точно в пору будет создавать супер-пупер машину, которая будет денно и нощно обучать программистов практике параллельного программирования.

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

Что ж можете и дальше наслаждаться быстрым поиском от Google, не думаю, правда, что это вам поможет.

Источник - The Register

Параллельное программирование. Что делать?

Автор - Joseph Landman(с) | scalability.org
Перевод - Петров Александр(с)

Ранее мы уже обсуждали некоторые аспекты будущего параллельного программирования и современных тенденций в области. Грубо говоря, на сегодняшний день мы можем выделить два типа параллельных систем и инструментов их создания – системы с разделяемой (общей) памятью и системы с распределенной памятью. Наиболее известными инструментами создания таких систем являются OpenMP и MPI, соответственно. Впрочем есть и другие типы систем, и соответственно другие инструменты, но наиболее широко распространены именно эти.

Проблемы?

Используя OpenMP, вы по сути дела снабжаете свой код некоторыми пометками, которые позволяют компилятору «развернуть» эти пометки в недостающий код. Т.е., другими словами, OpenMP является макрорасширением языка (языком в языке) – компилятор выполняет автоматическое распараллеливания вашего алгоритма, руководствуясь вашими пометками (иногда это вызывает интересные проблемы - пример). Однако OpenMP предполагает, что вы программируете систему с разделяемой памятью – OpenMP не способна генерировать код, предназначенный для распределенного исполнения.

Используя MPI, вы полновластно владеете своим кодом. Вы – а не компилятор выполняете основную работу, используя библиотечные функции MPI. Компилятор не способен оптимизировать (в плане параллелизма) ваш mpi-код, поскольку это всего лишь вызовы функций. Ещё хуже, что вы по сути дела находитесь в свободном плавании и вольны выбирать тот способ решения задачи, какой вам заблагорассудиться, понятно, что этот способ вовсе не обязательно будет лучшим или вообще правильным.

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

Я вовсе не хочу сказать, что OpenMP – это плохо. Мне нравиться OpenMP, но мы не сможем использовать OpenMP в распределенных системах (а именно за ними будущее высокопроизводительных вычислений). Я не хочу сказать, что MPI – это плохо, просто MPI – это довольно-таки низкоуровневый инструмент, используя, MPI вам приходиться явно прописывать все то, что обычно генерирует за нас сам компилятор.

MPI – это что-то вроде ассемблера в параллельном программировании. Поэтому используя его, нужно быть готовым к тому, что совсем не просто написать рабочий код, неп росто его отлаживать, не просто его оптимизировать. Большинство программ MPI-программистов дают лишь 10-15% прирост производительности при увеличении числа ядер. Очень редко эта цифра достигает 50+%. Проблема не в программистах (а вы как думали?!) – проблема в том, что при распараллелировании крайне тяжело выделить действительно продолжительные по времени исполнения куски кода.

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

Понятно, что такие упрощения не учитывают некоторых важных вещей. Окружающий нас мир не обладает локальностью. Наши алгоритмы, которые в определенной степени, являются отражением действительности с помощью некоторых математических конструкций, должны учитывать отсутствие локальности. Так мы можем воспринимать неравнозначность узлов сети как отсутствие локальности и учитывать это в наших алгоритмах. Однако, это опять же приводит нас к излишней низкоуровневости (к копошению) – не должен ли сам компилятор заботиться об отсутствии локальности? Если бы мы смогли научить наши компьютеры учитывать характер распреденности в системе, то это, возможно, помогло бы нам сделать параллельные программы более предсказуемыми и надежными, хотя конечно, это сказалось бы на времени компиляции и на сложности компиляторов.

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

Программирование масштабных многопроцессорных систем будет только усложняться с ростом их масштаба. К тому же очевидно в скором времени появиться не-SMP системы (aSMP - асимметричные многопроцессорные системы), а также системы, использующие дополнительные сопроцессоры (называемые также акселераторами или APU (accelerator processing units)). Любая из этих нелокальных систем потребует четкого представления принципов распределенного (как в пространстве, так и во времени) доступа к данным. Надеюсь мы сможем преодолеть господствующие сегодня стереотипы и найти простые способы решения этих непростых проблем.

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

Это Фортран.

Joseph Landman(с).

---

Данная заметка показалась мне интересной, поскольку она более-менее отражает сегодняшние стремления параллельных программистов (нет не стремление программировать на Фортране, а необходимость создания более выразительных инструментов) в интересном свете распределенных систем.

Реальными примерами систем, о которых говорит автор, являются Googl-овская MapReduce и системы на основе идей GPGPU (General-Purpose computation on graphics processing units (GPUs)).
MapReduce - сильно распределенная система – это кластер из 1800 узлов (в каждом по 2 Intel Xeon 2GHz), между которыми распределяются данные и задания. При таком количестве узлов одной их основных проблем кластера является его отказоустойчивость – в том, смысле, что при выходе одного узла система должна перенаправить его данные и его задания другому узлу и т.д. Система называется MapReduce – поскольку модель этой системы основана на использовании двух широко распространенных в функциональном программировании функций: Map (отображение одного множества в другое путем применения функции преобразования к элементам исходного множества) и Reduce (получение агрегированной характеристики элементов множества (нпр. их суммы)).


GPGPU cистемы принадлежат к другому классу систем, которые автор, называет APU-системы. В таких системах (аппаратно-программных комплексах, по сути) центральному процессору аккомпанирует целый ряд внешних, обычно специализированных вычислителей. Это могут быть как ПЛИСы, так и микроконтроллеры или специализированные микропроцессоры (нпр. сигнальные(DSP) процессоры). Очевидно, что такие системы прямо-таки насыщены параллелизмом (вычислителей-то много) и они не являются однородными (в отличие, скажем, от сегодняшних многоядреных процессоров). Они не являются однородными поскольку в них могут использоваться различные каналы связи между элементами системы, что влечет отсутствие локальности, о которой говорит автор. В GPGPU системах, в качестве специализированного вычислителя выступает процессор видео карточки.