Как стать автором
Обновить

Комментарии 43

Про обучение: в лаборатории Intel-СПРИНТ (СПбГУ) прошедшим летом проходила школа по High-Performance Computing. В этом году также будет летняя школа, скорее всего, по сходной тематике. Для студентов участие бесплатно, для остальных — не знаю.
Также на сайте лаборатории можно найти литературу по соответствующей тематике.
Полагаю там обучают только в «правильном», выгодном для Intel направлении? :-) Или там и кластеры на процессорах + видеокартах AMD тоже изучают? :-)
Интел уже выпустила альфу своей реализации OpenCL. Не думаю, что они идут совсем уж своим путем, ведь дело не в каких-то фишечках оптимизации, а в проблемах программирования для гетерогенной параллельной архитектуры.
Нашел на parallel.ru целый список конференций по суперкомпьютингу и около.
Там даже мой Иркутск есть!
parallel.ru/conferences/russian_conferences.html
И еще одна ссылка для обучения:
school.hpc-russia.ru/
Летняя школа по суперкомпьютерным технологиям.
Увы, я уже не молод и не попадаю.
Автор, зачем ты пишешь о том, в чём не разбираешься? Проблема в программировании под GPGPU не столько в «сложности написания кода», сколько в крайне узком спектре задач и алгоритмов, которые принципиально выигрывают от выполнения на них.
Возможно, я где-то выразился неточно, впрочем где я пишу про «сложность написания кода»? Не нашел даже поиском.
Да, дело не в кодировании а в алгоритмах, и проблема переписывания кода в том, что алгоритмы решения множества задач не параллелятся (по данным или вообще).
Нужно придумывать новые, параллельные, именно в этом одна из главных задач текущей гонки.
>программирование для графических ускорителей, как я уже писал, не самое простое занятие
Вот здесь.
Дело не в параллельности, а в ветвлениях.
Если перейти по ссылке, там достаточно подробно про SIMD — моя статья про OpenCL и как раз прямым текстом про замедление при ветвлениях. Ы?
Тогда прошу прощения. Я неправильно понял вашу формулировку.
Принято.
Проблема, например, аэродинамики в том, что изначально параллельный процесс описали последовательной моделью, для которой придумали алгоритм. А затем, почему-то стали этот алгоритм параллелить, без оглядки на изначальную параллельность среды.

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

А если к этому добавить всякие ограничения со стороны nvidea, в виде, например 63 байт под алгоритм и данные на одну группу процессоров в GPU — вот тогда начинается полный ппц.
48 кб + 64 кб константной памяти.
А насчет огромных трудозатрат — это да, но кто первый это сделает, тот и будет на коне. Сейчас задача облегчается тем, что раньше для программирования Cray нужно было покупать Cray, а теперь достаточно домашней видеокарты.
Основная проблема на GPGPU — это крайне малый объем памяти с доступом за 1-2 такта. Вся остальная память за 100 и больше тактов доступна. Поэтому для вычислительной аэродинамики приходится изгаляться над кодом так, что мама не горюй.
Знакомый аспирант уже задолбался умещать алгоритмы в 63 байта (и это на одной из топывых Тесл).
Насколько мне не изменяет мой склероз, там 48 кб… да, мало, сам знаю, регистров еще меньше, но у процессоров так же. Но будет еще меньше, я не написал в статье еще одну проблему — количество памяти на ядро все время уменьшается.
Вспоминаем экономию памяти, как в 60е годы.
Один 486 процессор мог обсчитывать всю космическую программу СССР уровня 80-х годов в реальном времени.
Но для противоракетной обороны пришлось городить гигафлопный суперкомпьютер…
«Чем больше узлов, тем меньше надежность, экзафлопные компьютеры будут ломаться непрерывно и при их эксплуатации это должно непрерывно учитываться»

Вспоминаются вакуумные лампы в первых компах, где в среднем 1 лампа сгорала каждые 3-5 минут.
Развитие идет по спирали.
Впрочем, мозги достаточно надежно думают на принципиально ненадежных элементах, так что, думаю, начиная с некоторой сложности все равно придется учиться программировать ненадежные системы.
Хорошая статья, но мне немного не нравится терминология и контекст.
Ракетная и ядерная гонка были порождением холодной войны. Сейчас совсем другое время и принципиально другие вызовы. Если и есть гонка, то ее субъектами в гораздо меньшей степени чем раньше являются государства. Это скорее корпорации и отрасли.
Американцы вполне сейчас пользуются своим монополизмом в суперкомпьютерном софте и, понятно, зажимают наших ядерщиков и авиастроителей. Да, слава Богу это не война, но это вызов — и именно на уровне государств.
Я не принадлежу к ура-патриотам, но вполне понимаю, что технологии, затрагивающие национальную безопасность никогда не будут полностью корпоративными.
Наука пользуется достижениями суперкомпьютерных вычислений. А она в значительной степени интернациональна. прошли времена, когда военные технологии были драйвером развития гражданских как минимум с 60-х все наоборот. Опять же холодная война закончилась. рассуждать в терминах «американцы пользуются» теперь бессмысленно.
Доклад PITAC (The President’s Information Technology Advisory Committee) Вычислительные науки: обеспечение превосходства (конкурентоспособности) Америки

«Страна, которая хочет достичь превосходства в конкурентной борьбе, должна превосходить конкурентов в области вычислений»
Пару лет назад пробовал программировать с использованием видеокарты.
Бутылочным горлышком был обмен данными между памятью карты и оперативкой.
Тесла в этом плане мне нравится куда больше.
Хотя конечно зависит от задач, не всегда требуется обработка больших массивов данных.
PS: не верю в экзофлоп через 8 лет, технологический рывок в производстве процессоров ожидается только лет через 10, кроме того необходимо будет полносью переписывать весь софт.
По моему опыту, профайлер не всегда правильно показывает причину замедления, я тоже долго грешил на память, оказалось — ветвление.
Память, память и еще раз она, разработка алгоритма упирается в нее.
В моей задаче пришлось долго подбирать, какую часть засунуть на ускоритель. В результате все-таки получилось найти участок программы, внутри которого ходили большие объемы памяти а снаружи было терпимо (несколько гигабайт за 15 минут). Скорость обмена все ж таки несколько Гб/с, что совсем не мало.
Есть идея попробовать сделать архивацию перед пересылкой, на разреженных данных возможно получить выигрыш.
Есть интересная тенденция: 2 xeon не выдерживает полностью рассчеты на всю мощность 3-х тесл. Очень забавно наблюдать, когда предельное ускорение не достигается не из-за памяти в GPU, а из-за процессоров, которые не успевают ставить задачи.

Кстати компилятор у nvidea кривой и содержит много багов. Например, программа собранная с ключом -О3 может давать результаты совершенно не такие, как с -О2.
1) Можно попробовать асинхронный режим, главное, чтоб памяти хватило.
2) ну, и с gcc так вполне бывает.
Я когда-то написал небольшую заметку насчет использования GPU.

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

Область моей деятельности связана с вычислительной гидро- и аэро-динамикой, поэтому я имею некоторое представление о научных вычислениях. Если вы думаете, что видео-чипы выйдут победителями сражения с Intel? Я думаю, что вы ошибаетесь.

Первое, я не знаю, что должно произойти, чтобы ученые взяли свои библиотеки написанные на фортране лет 10-20 назад и переписали под новые условия. Эти библиотеки написаны не на С++, и не на Java, и даже не на обычном С — они написаны на fortran-е, причем так, что напрямую на видеочипы не переносятся.

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

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

Четвертое, сейчас большинство используют MPI и OpenMP. При выходе даже 48миядерного процессора от Intel — эти средства будут быстро оптимизированы под новые условия — старые программы продолжат свою работу.

Пятое, количество реальных потоков в современных видеокартах, то есть на которых можно запустить счет, составляет 10-ки. Например, у меня в институте на новом супере (гибридном, то есть видеокарты и обычные процессоры на узлах) в видеокарту помещается не больше 32 таких потоков (а по-моему все-таки 16, но точно не помню). И сравнить с аналогичным по производительности 48миядерником, где мы, в отличии от видео-чипов, можем управлять каждым ядром, то видео-чипы смотрятся как-то бледно.

Итого: на данный момент, из-за остановки роста производительности процессоров по частоте и смещения акцента в сторону многоядерности, видео-чипы выглядят привлекательнее для научных разработок. Но я думаю пройдет пару лет, Intel выпустит свои многоядерники на рынок, доступный научным организациям и видео-чипы будут вытеснены. Но я не исключаю, что AMD/nVidia выпустят видеокарты с более дружественными технологиями, чем CUDA и openCL.
Ну, т.к. я довольно долго бился с OpenCL, я не питаю больших иллюзий, интеловская система с легкими, но не SIMD ядрами будет очень интересным решением. Однако же, чем «легче» ядра, тем больше их можно засунуть на кристалл, потому граф. ускорители при одной и той же технологии всегда будут на шаг впереди и всегда будут востребованы на своем классе задач.
Насчет 16ти потоков — скорее всего идет речь о 16 группах SIMD потоков, т.е. вы пытаетесь запустить не параллельный по данным код и он делится только на количество микропроцессоров, а не на все их ядра (там же двухуровневая организация).
На Tesla 448 ядер и соответствующим кодом их вполне можно задействовать.
Насчет OpenCL — уже сейчас Intel выпустила его реализацию для процессоров. OpenCL силен тем, что можно напрямую указывать, в каком кэше будут лежать какие данные (сейчас этим оптимизатор занимается автоматом), что позволит получать предсказуемые по производительности результаты на разных платформах. Опять же, я писал в статье, что через OpenCL уже можно управлять целым кластером, так что технология явно универсальна и жизнеспособна.
К сожалению, пока нельзя избавиться от проблем, связанных с адаптацией кода под железо. Если у вас есть несколько разных моделей видеокарт — уже на них нужно подгонять под железо.
С универсальными процессорами таких проблем особо не будет.
Ну почему же не будет? У pentium4 и core вполне разная оптимизация, разве что этим занимаются компилеры и мы это не видим. Так будет и для видеокарт, тем более что у OpenCL jit-компилятор.
Работаю над фреймворком для генерации случайных чисел.
Начали появляться генераторы адаптированные для графических процессоров.
Учёные тоже не стоят на месте ;)
На конференции слышал, что часть мат. библиотек уже переписали. Т.е. просто используешь, а она, при необходимости, использует ускоритель.
> В этом году намечается масштабная модернизация «Ломоносова» с помощью графических ускорителей, после чего он должен войти в десятку лучших.

Как они будут считать общую производительность, чтобы сравнивать с другими машинами?
По стандартной методике, теоретическая производительность, linpack, разница — эффективность.
Т.к. суперкомпов с граф. ускорителями пруд пруди, технология отработана.
Так вот это и не понятно. Получили мы линпак на CPU, потом на GPU — это два совершенно разных линпак-результата и их нельзя просто так складывать. Даже с гетерогенным кластером, на каждом сегменте (с разными CPU) которого запускается отдельный линпак, вопрос о корректности суммирования весьма тонкий, а тут вообще CPU и GPU. Получается у нас 2 независимые характеристики. Тогда и сравнение должно вестись по двум параметрам?
Не буду сочинять, не знаю. По идее должны запускать сразу на всем оборудовании. Возможно, именно с этим связана низкая эффективность главного китайского суперкомпа.
Интересно, есть ли Java-порты к GPU?
Я не явавод, но гугл говорит, что очень много
Даже для ruby есть.
К списку ответов на вопрос «Зачем все это нужно?» могу добавить также использование суперкомпьютеров для выполнения больших имитационны агентных моделей в масштабе города, страны или целого мира. С миллионами и миллиардами агентов. Как, например, тут.
Хотя, честно говоря, такое количество агентов не всегда необходимо решения конкретной задачи.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории