24 апреля компания Intel проводит вебинар "Обзор Intel Parallel Studio XE 2011". Будет рассмотрен комплекс средств Intel Parallel Studio XE для оптимизации производительности приложений.

В рамках вебинара Игорь Воробцов, инженер по разработке программного обеспечения в компании Intel, расскажет о передовых компиляторах Intel C/C++ и Fortran, средствах проверки ошибок и повышения надежности кода, профилировке. Несмотря на то, что вебинар будет проводиться только в сети, вещаться он будет "в прямом эфире", поэтому докладчик будет рад ответить на ваши вопросы по ходу вебинара и после его окончания.

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

Вы сможете задать свои вопросы об Intel Parallel Studio XE и работе в Intel в нашем чате во время вебинара. Для участия в вебинаре вам необходимо пройти регистрацию. По окончанию регистрации вам будет выслано подтверждение на электронную почту.

Вебинар состоится в ближайший вторник, 24 апреля в 16.00 по московскому времени.

Когда я искал ответ на свой предыдущий вопрос, я наткнулся на статью "Применение закона Амдаля к энергоэффективным вычислениям в эпоху многоядерных компьютеров" (en) (журнал Computer, декабрь 2008 г., стр. 24-31), авторами которой являются Dong Hyuk Woo и Hsien-Hsin S. Lee (Georgia Institute of Technology). Прочитав название, я решил, что статья может быть посвящена поиску метрики или верхней границы теоретической энергоэффективности приложения. Все оказалось не так просто, но я нашел несколько очень интересных идей.

Авторы попытались выяснить, какая из трех возможных процессорных архитектур будет максимально эффективна для параллельных вычислений с точки зрения минимизации потребления энергии. Многоядерные процессоры делятся на три основных типа: 1) Multicore (несколько больших процессорных ядер на одном кристалле), 2) Manycore (значительно большее количество более простых и энергоэффективных ядер) и 3) сочетание одного большого ядра и множества более простых ядер. К первому типу относятся современные 2-, 4- и 6-ядерные процессоры, ко второму — графические процессоры (GPU), а третий тип представляет собой гибрид, когда одно большое ядро, встроено в графический процессор.

В формулах, используемых для описания модели, максимальная потребляемая мощность одного большого ядра приведена к единице, а энергопотребление бездействующего процессора выражено дополнительной переменной k. Для первой архитектуры в традиционную формулу закона Амдаля добавляется новая переменная, используемая в качестве множителя для процента времени последовательной работы, умноженного на число бездействующих ядер (n-1). В результате ряда простых алгебраических преобразований авторы получают формулу для оценки средней потребляемой мощности в ваттах для приложения с параллельной обработкой, использующего n ядер, с указанным процентным соотношением параллельной и последовательной работы. Аналогичная формула выведена для модели Manycore, в которой потребляемая мощность простого ядра приведена к четверти от потребляемой мощности большого ядра. Для гибридной модели при выводе соответствующей формулы делается предположение о том, что одно большое ядро используется для последовательной обработки, а более простые ядра выполняют параллельную работу.

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

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

А в качестве итогового вывода, наиболее масштабируемой с точки зрения энергопотребления была названа гибридная модель с одним большим ядром и множеством мелких ядер. Архитектура Manycore демонстрирует хорошие показатели при высокой степени параллелизма и низких ограничениях мощности (при меньшем общем количестве ядер), но с увеличением ограничений количество простых ядер увеличивается, а производительность эффективной последовательной обработки — нет. Гибридная модель с одним большим ядром, встроенным на месте нескольких более простых ядер, способно эффективнее обрабатывать последовательные фрагменты нагрузки (по сравнению с несколькими десятками простых ядер, из которых одно работает, а все остальные простаивают).

Читая статью, я сопоставлял описанные модели современных многоядерных процессоров с устройствами, широко представленными на сегодняшнем рынке. Модель Manycore, скорее всего, представлена графическими процессорами (GPU) или акселераторами MIC. Гибридная модель должна выглядеть как комбинация акселератора Manycore и двухъядерного процессора (пока на рынке не появились кристаллы с разными типами ядер). Мне было интересно, к какому типу можно отнести векторные процессоры. Если рассматривать только векторные регистры, можно сказать, что это разновидность модели Manycore. Однако такие регистры являются частью большого ядра, что наводит на мысль о гибридной модели. Возможно, они реализуют второй уровень параллельной обработки, который не учитывается в этих трех моделях.

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

Предположим, что у нас есть время выполнения, равное 10 единицам времени (назовем эти единицы moops). При выполнении последовательного кода на четырехъядерном процессоре одно ядро работало бы на полной скорости в течение 10 moops, а остальные три ядра в совокупности добавили бы еще 30 moops потребления в режиме бездействия. Если алгоритм распараллеливает 50% нагрузки, мы получим 5 moops потребления энергии на полной мощности для последовательной обработки, 5 moops потребления на полной мощности для параллельной обработки на каждом из четырех ядер, и 15 moops потребления в режиме бездействия. Даже если код распараллелен всего на 10%, мы получим уже 27 moops потребления в режиме бездействия. При любой степени (идеального) параллелизма будет гарантированно потребляться меньше энергии, чем при эквивалентной последовательной обработке на той же системе. Вам не кажется, что здесь пропущено что-то важное?

Я не зря добавил слово "идеального" в конце предыдущего абзаца. При параллельных вычислениях всегда существуют непроизводительные издержки, которые увеличивают время выполнения параллельных участков кода и, следовательно, время потребления энергии на полной мощности (например, для выполнения 50-процентной параллельной части нагрузки может потребоваться 5,4 moops потребления на полной мощности).

Во-вторых, закон Амдаля используется для оценки ускорения. Ускорение — это безразмерное число. То есть я делю время выполнения последовательного кода на время параллельной обработки и получаю просто число, поскольку единицы измерения moops из двух величин при расчете сокращаются. Если при последовательной обработке требуется 10 moops времени, а при параллельной обработке — 6,35 moops, ускорение составляет 1,57X. 1,57 чего? Ускорение представляет собой метрику относительной производительности, но это не то, что я вкладываю в понятие производительности.

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

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

Предположим, что ваш начальник обратился к вам и потребовал, чтобы программное обеспечение, которое вы разрабатываете, было энергоэффективным. Попробуйте объяснить, как именно вы будете этого добиваться?

Конечно, вы можете найти множество различных идей для решения этой задачи на нашем Cообществе повышения энергоэффективности (en). Но как вы докажете своему начальнику, что справились с задачей? Или, если вы уже оптимизировали в приложении все, что только возможно, по каким критериям вы определите, что теперь это приложение энергоэффективно?

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

Общее энергопотребление

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

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

Производительность на ватт энергии

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

С помощью таких метрик можно легко отслеживать разницу между состояниями до и после изменения в процессе оптимизации. Если сначала приложение работает на уровне 10 FAUXtoe-ops на ватт, а конце достигает уровня 20 FAUXtoe-ops на ватт, то это означает, что вы двигаетесь в верном направлении. [Здесь FAUXtoe-ops — отсылка к абстрактной операции, выполняемой приложением — прим. переводчика] Как и для предыдущего аспекта, было бы полезно определить теоретическое абсолютное значение в качестве цели для такой оптимизации. Это значение будет зависеть от единиц рабочей нагрузки, которые используются в приложении. Будет ли такой критерий энергоэффективности зависеть от конфигурации целевого оборудования (аккумулятора, блока питания, процессора, чипсета, графического процессора и т. д.)?

Поведение приложения в режиме ожидания

Многие разработчики акцентировали внимание на том, что процессор должен по возможности бездействовать. То есть он должен как можно дольше находиться в C-состоянии (C-state) с самым низким энергопотреблением. Применительно к приложению это золотое правило можно выразить аббревиатурой HUGI (Hurry Up and Get Idle — "торопись и отдыхай"). Выполняйте обработку как можно быстрее любыми средствами, чтобы затем приложение переходило в состояние ожидания (и тратило энергию как можно экономнее). Таким образом, данный аспект заключается в том, чтобы определить, насколько эффективно приложение тратит время в ожидании пользовательского ввода или других прерываний.

Оценить, насколько эффективно приложение выполняется во время ожидания, не сложно — достаточно измерить процент времени, когда процессор находился в C-состоянии с низким энергопотреблением (C3, C6). Эта метрика может быть абсолютным процентным значением от времени выполнения или измеренным значением относительно состояния бездействия системы при отсутствии других запущенных приложений, то есть когда операционная система находится в состоянии покоя. Эта методика хорошо подходит для высокоинтерактивных приложений, работающих быстрее, чем пользователь вводит данные или нажимает кнопки, но что делать с приложениями, интенсивно использующими вычислительные ресурсы? При запуске моей версии приложения Akari менее 3% времени было проведено в состоянии С3, и в ходе выполнения 80 потоков было достигнуто ускорение 22.56X. Если учесть все параллельные задачи, которые позволили задействовать все доступные потоки и ядра, может ли это приложение считаться энергоэффективным?

Что вы об этом думаете?

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

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

Перевод продолжения этого поста читайте здесь→

Как многие наверняка слышали, Intel регулярно проводит в своих офисах интересные семинары, приглашая на них всех желающих. Чаще всего такие семинары проходят в Нижнем Новгороде.

В ближайшую пятницу (30 марта) с 16:00 до 18:00 по Москве пройдет очередной семинар «Вычислительное моделирование для разработки современной технологии в микроэлектронике».

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

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

Итак, 30 марта (пятница), 4 часа вечера по Москве, онлайн-трансляция семинара «Вычислительное моделирование для разработки современной технологии в микроэлектронике» будет доступна прямо на этой странице. Задать вопросы докладчику во время семинара можно будет на странице канала Intel talks на Ustream.tv

Приглашаем всех!

Пока онлайн-трансляция не началась, в плеере ниже можно посмотреть кусочек записи трансляции предыдущего семинара «Игровая физика».

Video streaming by Ustream

В эти холодные дни, когда студенты спокойно отдыхают от сессии, а не-студенты два раза в день мерзнут по дороге на работу и с работы, мы опять решаем, как оформить новые блог(г)ерские футболки для участников Intel Software Network.

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

Итак, в этот раз всё серьезно и более свободно.

Наверняка, у вас есть идея для клёвой футболки блогера/участника ISN. Мы можем воплотить ее в жизнь!

Каждый, кому не безразлична ISN-мода этого сезона, может перейти в специальную тему на форуме и опубликовать там картинку или текстовое описание «футболки мечты».

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

Самую лучшую идею мы воплотим в жизнь (а это значит, что более 50 человек будут носить на себе ваше творение), а автору идеи, а также самому активному на наш взгляд участнику, отправим свежеиспеченные футболки, как только они приедут к нам из типографии.

Таймлайн: обсуждение лучшей футболки не закончится никогда, но выбирать лучший вариант мы будем 9 марта, сразу после праздников (чтобы веселее было )

До встречи в форуме!

P.S.: Тому, кто догадается, почему мы не предлагаем публиковать картинку в комментариях к этой записи, плюс в карму

P.P.S.: Не воспринимайте последний вопрос серьезно, ответ лежит на поверхности и не отличается уникальностью

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

В ноябре прошлого года сотрудники двух лабораторий (НИВЦ МГУ и ВМК ННГУ) разработали совместный курс по параллельному программированию и победили в международном конкурсе, организованном компанией Informatics Europe.

Конкурсная заявка коллектива МГУ–ННГУ Parallelism & Concurrency: Changing the Landscape of IT-Education получила признание представительного международного жюри конкурса, что подтверждает высокий уровень образования и исследований в Московском и Нижегородском университетах и свидетельствует о качестве образования в России в целом в области суперкомпьютерных технологий.

Informatics Europe – известная международная ассоциация факультетов и исследовательских лабораторий в области Computer Science в Европе и соседних регионах. Основное направление деятельности ассоциации – способствование повышению качества образования и исследований в области информатики и Computer Science.

Награда в конкурсе Informatics Europe Curriculum Best Practices Award присуждается за выдающиеся достижения, способствующие повышению качества образования и привлекательности дисциплины. Отмечается возможность использования образовательных материалов за пределами создавшей их организации. В 2011 году конкурс был направлен на тематику, связанную с параллельными вычислениями (Parallelism and Concurrency), и поддержан грантом компании Intel.

Вручение награды состоялось в рамках ежегодного международного форума European Computer Science Summit. В саммите принимали участие деканы, заведующие кафедрами и ключевые сотрудники ведущих европейских университетов, факультетов, исследовательских институтов в области информатики и Computer Science, а также представители индустрии. В 2011 году форум был проведен в Милане (Италия) с 7 по 9 ноября.

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

С презентацией курса, который получил эту почетную награду можно ознакомиться по ссылке Parallelism & Concurrency: Changing the Landscape of IT-Education (pdf).

Авторы курса:

ННГУ:

• В.П. Гергель, д.т.н., профессор, декан факультета ВМК ННГУ, соруководитель коллектива
• И.Б. Мееров, к.т.н., доцент
• К.А. Баркалов, к.ф.-м.н., старший преподаватель
• А.В. Сысоев, ассистент

МГУ:

• В.В. Воеводин, член-корреспондент РАН, д.ф.-м.н., профессор, заместитель директора НИВЦ ВМК, соруководитель коллектива
• Н.Н. Попова, к.ф.-м.н., доцент
• А.С. Антонов, к.ф.-м.н., старший научный сотрудник
• С.А. Жуматий, к.ф.-м.н., старший научный сотрудник
• О.В. Джосан, к.ф.-м.н., ассистент

Я сам уже почти 3 года участвую в жизни лаборатории ITLab ННГУ и очень рад за преподавателей и коллег.

Еще раз поздравляем!

Вопрос читателям: а как вас учили параллельному программированию в университете?

Хотели бы вы учиться, например, по такому курсу, как Параллельные численные методы?

Стив Лайонел (Steve Lionel) — разработчик компилятора языка Фортран, инженер Intel, евангелист, а также активный блоггер на американском ISN. За его увлечение и продвижение Фортрана его зовут "Доктор Фортран", в чем можно убедиться, набрав в гугле "Dr. Fortran". Я бы хотел перевести интервью, которое Доктор Фортран дал несколько дней назад сайту Intelligence In Software.

Стив Лайонел считает, что Фортран, несмотря на почтенный 54-летний возраст, остается достаточно важным языком, даже в наш век, когда большинство программистов пользуются языками типа PERL, Python или Java.

Вопрос: Фортран всё еще актуален? Кажется, что в последнее время этот язык обсуждается достаточно редко.

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

В: Какие возможности Фортран получил из других языков?

Стив: В 2003 году, например, в Фортран были добавлены классы и возможности полиморфизма, унаследованные из С++.

В: А какие еще сильные стороны есть у языка?

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

В: Пишутся ли на Фортране новые приложения?

Стив: Да, их много. Если посмотреть на приложения для предсказания ураганов, большинство моделей написаны на Фортране. Известный фреймворк для предсказания погоды WRF (The Weather Research and Forecasting Model) в основном написан на Фортране. На нем написан и известный симулятор автомобильных аварий (PAM-CRASH), а также много инженерного кода, кода для оптического моделирования, язык используется и в ядерной физике. Фортран де-факто остается важным языком в высокопроизводительных вычислениях (HPC).

В: Так почему же так мало людей пишут на Фортране?

Стив: Я не хочу создавать впечатление, что всё написано на Фортране. Он занимает меньшую часть рынка, чем 20 лет назад, но Фортран не умирает. Да, сейчас C и C++ лучше подходят для многих задач, чем Фортран.

В: Для каких задач Фортран всё еще лучше других языков?

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

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

---

От автора:

Я поговорил с одним из программистов Intel и почитал несколько статей в интернете, из чего складывается мнение, что с языком ситуация не такая уж и радостная.
С одной стороны, существует как минимум два коммерческих компилятора Фортрана — Intel® Composer XE и PGI Workstation, такие библиотеки как MPI, OpenMP (даже последняя версия 3.1), Intel® MKL поддерживают Фортран-интерфейсы, существует CUDA Fortran компилятор. Значит ли это, что язык не умирает? Очевидно, да.

С другой стороны, похоже, Фортран поддерживается только ради старого кода. Молодых программистов (даже в научных институтах) сложно заставить писать на старом добром Фортране, но менее прогрессивная часть ученых всё еще руководствуется принципом "не трогайте то, что работает, а новое пишите на том же языке (это объективно проще, чем писать обертки для старого кода)". Это относится и к промышленному программированию: например, CAD CATIA, которая используется компанией Boeing для разработки самолетов, имеет часть, написанную на Фортране, и они, как мне кажется, не соберутся переписывать ее на Си в ближайшее время.

По мотивам: Steve Lionel on Why Fortran Still Matters

На закуску: интересное видео, в котором Стив рассказывает о Intel® Fortran Compiler:

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

В этом году на конференции появится новая интересная секция — "визуализация науки" (в оригинале — Scientific Visualization Showcase). В секции будут представлены статичные изображения и анимации, созданные профессиональными художниками и призванные помочь ученым отобразить результаты вычислений в интуитивно-понятном графическом или трехмерном виде. Картинки и трехмерные модели, построенные на основе реальных данных будут представлены на панели из больших LCD-дисплеев в холле выставочного зала.

Фото с конференции SC10

Kelly Gaither, руководитель отдела визуализации в Техасском компьютерном центре и председатель секции научных визуализаций SC11:

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

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

Scott Lathrop, председатель SC11 и ответственный за образовательную программу в Blue Waters Project в Национальном центре высокопроизводительных вычислений:

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

Jim Costa, председатель Технической программы SС11 и главный менеджер Sandia National Laboratory:

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

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

Хотите поехать на конференцию? Регистрация тут.

По мотивам SC11 Visualization Showcase to Highlight the Beauty of Science (pdf)

От автора:

В прошлом году я был на конференции SC10 и участвовал в Student Cluster Competition. В этом году я вновь поеду на этот конкурс и, надеюсь, опять опубликую отчет о конкурсе, а также постараюсь рассказать подробнее про секцию научных визуализаций. Ждите фотографий!

В середине ноября в США проводилась международная IT-конференция по высокопроизводительным системам (HPC) Supercomputing 2010 (SC10). Я входил в команду студентов от Нижегородского Государственного Университета, которая ездила на эту конференцию для участия в Student Cluster Competition (студенческое соревнование по созданию и использованию кластера). В этом посте я расскажу про саму конференцию и соревнование, про подготовку вы можете прочитать в постах «Введение» и «Первая часть: Redmond, Microsoft и кластер».

Когда мы прилетели с западного на восточное побережье США в Новый Орлеан (штат Луизиана) за 2 дня до начала конференции, в выставочном зале уже вовсю шла работа по установке и сборке будок (booth) разных фирм. К счастью, наша будка уже была готова, оставалось только установить там наш кластер, подключить его к сети и к большому телевизору-монитору и навести порядок. Конференция занимала треть гигантского здания «Convention Center», длиной около километра! На первом этаже проходила выставка, стояли будки фирм и нашего соревнования, а на втором этаже в нескольких конференц-комнатах в это время читались доклады.

Итак, нам нужно было собрать кластер. Во-первых, мы спокойно выдохнули, когда узнали, что наш кластер успешно добрался из Редмонда в Орлеан и стоит в будке Майкрософта. Одной из команд «немного не повезло» — ребята из Флориды так и не получили кластер до начала соревнования, им пришлось просить всех вокруг поделиться нодами и оборудованием, в итоге они запускались на 2 нодах странной конфигурации. Тем не менее здорово, что их не бросили в беде. Вообще на конференции в целом и на соревновании в частности была хорошая добрая атмосфера не «конкурирования», а честной борьбы за приз. Команды друг другу помогали, «менялись» полезной информацией и кодами, организаторы помогали студентам настраивать сеть, найти недостающие кабели и всячески поддерживали морально.
Когда наш кластер был успешно установлен и подключен, мы позвали нашего помощника из IBM — он быстро проверил процессоры и состояние нод, после чего нам пришлось заменить несколько процессоров в нодах, добавить две новые ноды, реанимировать одну из старых нод и подключить несколько GPU — в итоге к началу соревнования мы получили кластер из 8 нод (вместо 6 изначально), запустили на последнуюю спокойную ночь утилиту Lizard, которая подбирает оптимальные параметры для бенчмарка HPCC и ушли спать.

Расскажу о наших спонсорах. Генеральный спонсор Microsoft оплачивал нам дорогу в Штаты, именно люди из Майкрософта собирали кластер из отдельных деталей, 4 человека помогали нам с аудитом наших сборок приложений и учили меня управлять кластером, делать простейший troubleshooting и показали, как пользоваться утилитой для отображения загруженности нод (Jeff, Wenming, Josh, Mark — спасибо вам!). Второй по важности спонсор — IBM, предоставлял ноды кластера. NVidia, естественно, дала Теслы (NVidia Tesla M2050). А Intel был «сердцем» кластера и единственной оптимизацией, которую мы успели сделать в условиях ограниченного времени — спасибо за процессора Xeon и Intel Compiler (теперь, боюсь, мы умеем им пользоваться даже лучше, чем простым и встроенным Visual Studio Compiler). От PGI у нас был лицензионный ключ для необходимого для сборки PGI Workstation.

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

И вот, наступил первый день Student Cluster Competition. По правилам соревнования, в этот день нужно было запустить набор бенчмарков HPCC и передать судьям лучший результат к 5 вечера. Так как никаких входных данных у HPCC нет, многие команды запустили его еще до соревнования (что не запрещалось), но у нас кластер появился слишком поздно, поэтому HPCC доработал только к 4 часам вечера, а мы весь день молились, чтобы ничего не упало и не пришлось перезапускать бенчмарки. К счастью, всё прошло удачно, тест LINPACK показал 780 гигафлоп (что немного ниже ожидаемого, но достаточно хорошо).

В 5 часов вечера первого дня нам выдали входные данные для остальных приложений. На получение результатов у нас было 48 часов, поэтому работа закипела вовсю. Главным сюрпризом для нас стало то, что слова организаторов «данных будет больше, чем возможно обсчитать за это время» были поняты нами неправильно. Мы ожидали, что будет очень много наборов входных данных, поэтому можно будет запускать по очереди каждый пакет на всем кластере по кругу (чтобы если что-то неправильно работает, то были бы хотя бы какие-то результаты). Оказалось, что почти для всех задач входной набор был один, но он должен был считаться очень долго. Приятным исключением был Password Cracker — выданные пароли, естественно, можно было разбить на множество запусков взломщика.

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

Итак, пакеты были запущены на 48 часов, поэтому нам нужно было (в идеальном случае) только иногда следить, не упало ли чего.

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

Первое приложение (WRF) отказывалось собираться с нужными ключами в параллельном режиме (оно собиралось, но не масштабировалось на кластер). Было принято волевое решение запускаться на двух нодах с другими ключами, чтобы посчитать хоть что-то.

Входной набор данных второго приложения (FLASH) не убирался в оперативную память (если производить вычисления с требуемой судьями точностью). Нужно было либо увеличивать число процессов (24 процесса на двух нодах было недостаточно), либо ухудшать точность. Решили быстро посчитать с плохой точностью (вдруг и за это баллы дадут), а потом запустить с правильной точностью на большом количестве нод, причем с 3 процессами на одно ядро, чтобы умещаться в память. Такой способ запуска, естественно, сильно тормозил вычисления, но у нас хотя бы был шанс досчитать до конца отведенных 48 часов. После нескольких часов счета, когда у нас освободился еще один узел кластера и мы решили перезапустить это приложение с «контрольной точки» (checkpoint), мы этого сделать не смогли. Времени разбираться уже не было, пришлось запускать вычисления с самого начала.

Взломщик MD5-хэшей на GPU почему-то начинал тормозить после нескольких часов работы, приходилось его останавливать, перегружать GPU и вручную запускать дальше. Появилась даже фраза «CUDA устала», но разобраться, почему это происходило, нам не хватало опыта.

Только последнее приложение (NAMD) отлично работало на CPU+GPU (причем, что удивительно, «CUDA не уставала») и закончило считать уже через 10-15 часов после начала соревнования.

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

Итогом неравной борьбы с трудностями и бессонной ночи стало то, что собранный с неправильными флагами WRF не получил баллов, FLASH не успел дойти до первой оцениваемой «контрольной точки», но был награжден несколькими баллами «за старания», NAMD по невыясненным до сих пор причинам получил не полный балл (хотя среди всех команд у нас были самые хорошие результаты, что не может не радовать), а Password Cracker смог всё-таки вскрыть часть паролей и получить законные баллы.

По правилам соревнования, объявлялся только победитель, а «остальные тоже молодцы», поэтому известно только то, что победили ребята с Тайваня, приехавшие уже четвертый раз и набравшие более 90% от максимально возможных баллов.

Всем командам были выданы таблицы с их баллами, но ни у кого нет сводной таблицы.

Итого, Майкрософт, Университет, да и мы сами вполне довольны результатом, мы получили бесценный опыт и если мы поедем в следующем году, то сможем учесть ошибки и может быть даже победить!

После объявления результатов соревнования у нас оставался еще целый вечер и утро следующего дня (до 13.00, когда нужно было ехать в аэропорт), чтобы погулять по городу и изучить окрестности, что мы и сделали, отправившись в так называемый «Французский квартал» Нового Орлеана. Как известно, город является столицей джаза, поэтому почти в каждом кафе играла живая музыка, а на улицах сидели музыканты, с некоторыми из которых нам даже удалось пообщаться. Город, в отличие от Редмонда, совсем не такой тихий и американский, а скорее даже очень европейский (по крайней мере центральная его часть). Узкие улочки, по бокам — невысокие красивые дома со свисающми балкончиками, очень много людей, местами шумно и грязно.

Но не смотря ни на что, город нам понравился, как и США в целом

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

Ссылки на дополнительные материалы про нашу поездку:

• Официальный сайт SC10
• Сайт Student Cluster Competition
• Список всех команд
• Страничка про нашу команду

Несколько ссылок на интервью с нами на youtube:

• SCC: Meet Team Russia
• SCC After Dark

Статьи на theregister:

• GPUs go crazy at SCC
• Student Cluster Competition: And they're off!
• SCC after dark: Clustering all night long
• SCC results: Taiwan wins overall crown

Фотоальбомы:

USA 2010

USA 2010 From Eugene Grines

Спасибо за внимание! Добро пожаловать в комментарии — вся наша команда постарается ответить на ваши вопросы.

Итак, 4 ноября в 2 часа ночи мы полетели в США. Перелет Нижний Новгород — Франкфурт (Германия) — Seattle (USA) для всех нас был ожиданно неприятным. 15 часов сидеть в узком кресле без возможности вытянуть ноги — неоспоримый повод проклинать того, кто придумал посреди нашей планеты сделать такой гигантский Атлантический океан

Несмотря на всю неприятность сидения в самолете, мы успешно прибыли в аэропорт Сиэттла, где нас встречал наш начальник и идейный предводитель, а также сотрудник Microsoft Джон.

После получасовой поездки из Сиэттла в Редмонд на лимузине (да-да, Майкрософт не мелочится ), нас поселили в двух апартментах (apartments) недалеко от одного из зданий Майкрософт, в котором нам и предстояло работать.

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

Здание Microsoft, в котором мы провели всю последующую неделю, тоже было удивительно гостеприимным и пустым, причем не только в выходные (что логично), но и в будние дни. Больше половины кабинетов были пусты. Наше здание (#25) было трехэтажным, с прозрачными стеклянными стенами, большой парковкой и высокой столовой, из которой открывался вид на небольшой парк с бегающими по деревьям белками

Нашей команде из 6 студентов и ментора выделили большую комнату, куда вскоре переехал наш кластер, всем дали компьютеры (лэптопы с разворачивающимся экраном и тач-скрином) и велели «работать дальше», чем мы и занялись. В течение недели каждый день мы приходили в нашу лабораторию, работали там вместе с несколькими инженерами Microsoft, которые нам очень помогали. На второй день кластер из состояния «стоит неизвестно где, доступен по Remote Desktop» переехал в нашу комнату, чтобы мы могли подключаться к нему напрямую, по ethernet. Главным «преимуществом» кластера рядом был непривычный рёв нескольких десятков кулеров, самые шумные из которых охлаждали маленький Infiniband-свитч.

Расскажу немного про то, что такое кластер с точки зрения пользователя (то есть нас). Сразу оговорюсь, что никогда не работал с кластерами под Linux, да и под Windows видел всего два кластера.

Наш кластер (итоговая конфигурация) состоял из 8 «нодов» (nodes). В каждом стояли по два процессора Intel Xeon L5640 (Westmere), по 6 ядер на каждом процессоре, на пяти нодах стояли по две карточки NVidia Tesla M2050. Ноды соединялись по медленному гигабитному Ethernet и по быстрому двадцатигигабитному Mellanox Infiniband. Ethernet-switch и Infiniband-switch на картинке:

Вот так страшно выглядел наш кластер в сборе уже на соревновании:

(между прочим, известный бенчмарк LINPACK показывал производительность около 700 гигафлоп!)

Две сети были сделаны специально, чтобы системные сообщения для администрирования кластера ходили по независимому медленному каналу, в то время, как приложения, занимающиеся вычислениями, «общались» по быстрому Infiniband’у.

На кластере стояла последняя версия Windows HPC Server 2008 R2 с установленным Microsoft HPC Pack, в состав которого входили инструменты для администирования, настройки и мониторинга кластера, автоматически ставился Microsoft MPI (основанный на MPICH2, но оптимизированный под Windows) и удобный HPC Job Manager, позволявший управлять задачами через простой GUI или Command-line интерфейс. Мне не с чем сравнить, но на наших задачах пользоваться им было очень приятно. Пишешь в командной строке

job submit /numnodes:2 /workdir:\\Share\Application\dir\ mpiexec -n 24 Application.exe

и задача ставится в очередь, и автоматически выполняется, когда появляются свободные ресурсы. Это избавляло нас от проблем типа «Кто опять запустился на седьмой ноде?? Моя задача тормозит!111», процесс выполнения задач автоматизировался на ура.

Расскажу немного о приложениях, которые в этом году нужно было запускать на соревновании. В нашей команде каждый из четырех человек отвечал за одно из четырех приложений и двое отвечали за пятое приложение, которое не имело ранее версии под Windows и вообще было самым «сложным» для нас.

Первое приложение — пакет бенчмарков HPCC, который запускался отдельно от остальных приложений и оценивал производительность кластера в общем. В HPCC входит известный бенчмарк LINPACK (решающий гигантскую систему линейных уравнений и показывающий, насколько хорошо кластер выполняет floating-point операции), а также бенчмарки для тестирования пропускной способности канала, связывающего ноды кластера (Infiniband), и скорости работы оперативной памяти. Для оптимального подбора начальных параметров для LINPACK была использована утилита Lizard (LInpack wiZARD), написанная специально для Windows.

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

• WRF — приложение, используемое для предсказания погоды
• FLASH — большой модульный фреймворк для моделирования разнообразной физики, мы использовали его для решения задачи неустойчивости Рэлея — Тейлора (http://ru.wikipedia.org/wiki/Неустойчивость Рэлея — Тейлора)
• NAMD — пакет для симуляции задач молекулярной физики. Одно из двух нашх приложений, которое использовало графический процессор для вычислений.

Особняком стояла задача «Password cracker» — нужно было «взломать» пароли, зашифрованные алгоритмами MD5 и Blowfish. Можно было использовать любой инструментарий (с открытым или закрытым кодом), мы использовали собственные реализации этих алгоритмов, причем они умели работать как на CPU, так и на GPU!

Итак, за неделю в «царстве Microsoft» Редмонде мы разбирались, как пользоваться кластером, инженеры Майкрософт написали мне несколько мануалов по решению проблем и тестированию работы кластера, мы успели также «допилить» наши приложения и полетели в Новый Орлеан (штат Луизиана) на конференцию. Кластер был отправлен туда за пару дней до нашего отлета.

О самой конференции Supercomputing 2010, о соревновании Student Cluster Competition и немножко о Новом Орлеане читайте в следующем посте: «Вторая часть: конференция в Новом Орлеане».