Comments 43
Про обучение: в лаборатории Intel-СПРИНТ (СПбГУ) прошедшим летом проходила школа по High-Performance Computing. В этом году также будет летняя школа, скорее всего, по сходной тематике. Для студентов участие бесплатно, для остальных — не знаю.
Также на сайте лаборатории можно найти литературу по соответствующей тематике.
Также на сайте лаборатории можно найти литературу по соответствующей тематике.
+2
Полагаю там обучают только в «правильном», выгодном для Intel направлении? :-) Или там и кластеры на процессорах + видеокартах AMD тоже изучают? :-)
0
Нашел на parallel.ru целый список конференций по суперкомпьютингу и около.
Там даже мой Иркутск есть!
parallel.ru/conferences/russian_conferences.html
Там даже мой Иркутск есть!
parallel.ru/conferences/russian_conferences.html
0
И еще одна ссылка для обучения:
school.hpc-russia.ru/
Летняя школа по суперкомпьютерным технологиям.
Увы, я уже не молод и не попадаю.
school.hpc-russia.ru/
Летняя школа по суперкомпьютерным технологиям.
Увы, я уже не молод и не попадаю.
0
Автор, зачем ты пишешь о том, в чём не разбираешься? Проблема в программировании под GPGPU не столько в «сложности написания кода», сколько в крайне узком спектре задач и алгоритмов, которые принципиально выигрывают от выполнения на них.
-3
Возможно, я где-то выразился неточно, впрочем где я пишу про «сложность написания кода»? Не нашел даже поиском.
Да, дело не в кодировании а в алгоритмах, и проблема переписывания кода в том, что алгоритмы решения множества задач не параллелятся (по данным или вообще).
Нужно придумывать новые, параллельные, именно в этом одна из главных задач текущей гонки.
Да, дело не в кодировании а в алгоритмах, и проблема переписывания кода в том, что алгоритмы решения множества задач не параллелятся (по данным или вообще).
Нужно придумывать новые, параллельные, именно в этом одна из главных задач текущей гонки.
+2
>программирование для графических ускорителей, как я уже писал, не самое простое занятие
Вот здесь.
Дело не в параллельности, а в ветвлениях.
Вот здесь.
Дело не в параллельности, а в ветвлениях.
0
Проблема, например, аэродинамики в том, что изначально параллельный процесс описали последовательной моделью, для которой придумали алгоритм. А затем, почему-то стали этот алгоритм параллелить, без оглядки на изначальную параллельность среды.
Для всех современные суперов без GPU есть очень и очень много библиотек с готовыми решениями, зачастую написанными на фортране, выверенные годами. А для GPU нужно не только новые алгоритмы, но огромные трудозатраты на доказательство корректности и выверении алгоритмов.
А если к этому добавить всякие ограничения со стороны nvidea, в виде, например 63 байт под алгоритм и данные на одну группу процессоров в GPU — вот тогда начинается полный ппц.
Для всех современные суперов без GPU есть очень и очень много библиотек с готовыми решениями, зачастую написанными на фортране, выверенные годами. А для GPU нужно не только новые алгоритмы, но огромные трудозатраты на доказательство корректности и выверении алгоритмов.
А если к этому добавить всякие ограничения со стороны nvidea, в виде, например 63 байт под алгоритм и данные на одну группу процессоров в GPU — вот тогда начинается полный ппц.
-1
Основная проблема на GPGPU — это крайне малый объем памяти с доступом за 1-2 такта. Вся остальная память за 100 и больше тактов доступна. Поэтому для вычислительной аэродинамики приходится изгаляться над кодом так, что мама не горюй.
Знакомый аспирант уже задолбался умещать алгоритмы в 63 байта (и это на одной из топывых Тесл).
Знакомый аспирант уже задолбался умещать алгоритмы в 63 байта (и это на одной из топывых Тесл).
0
Насколько мне не изменяет мой склероз, там 48 кб… да, мало, сам знаю, регистров еще меньше, но у процессоров так же. Но будет еще меньше, я не написал в статье еще одну проблему — количество памяти на ядро все время уменьшается.
Вспоминаем экономию памяти, как в 60е годы.
Вспоминаем экономию памяти, как в 60е годы.
0
«Чем больше узлов, тем меньше надежность, экзафлопные компьютеры будут ломаться непрерывно и при их эксплуатации это должно непрерывно учитываться»
Вспоминаются вакуумные лампы в первых компах, где в среднем 1 лампа сгорала каждые 3-5 минут.
Вспоминаются вакуумные лампы в первых компах, где в среднем 1 лампа сгорала каждые 3-5 минут.
+1
Хорошая статья, но мне немного не нравится терминология и контекст.
Ракетная и ядерная гонка были порождением холодной войны. Сейчас совсем другое время и принципиально другие вызовы. Если и есть гонка, то ее субъектами в гораздо меньшей степени чем раньше являются государства. Это скорее корпорации и отрасли.
Ракетная и ядерная гонка были порождением холодной войны. Сейчас совсем другое время и принципиально другие вызовы. Если и есть гонка, то ее субъектами в гораздо меньшей степени чем раньше являются государства. Это скорее корпорации и отрасли.
-1
Американцы вполне сейчас пользуются своим монополизмом в суперкомпьютерном софте и, понятно, зажимают наших ядерщиков и авиастроителей. Да, слава Богу это не война, но это вызов — и именно на уровне государств.
Я не принадлежу к ура-патриотам, но вполне понимаю, что технологии, затрагивающие национальную безопасность никогда не будут полностью корпоративными.
Я не принадлежу к ура-патриотам, но вполне понимаю, что технологии, затрагивающие национальную безопасность никогда не будут полностью корпоративными.
+3
Наука пользуется достижениями суперкомпьютерных вычислений. А она в значительной степени интернациональна. прошли времена, когда военные технологии были драйвером развития гражданских как минимум с 60-х все наоборот. Опять же холодная война закончилась. рассуждать в терминах «американцы пользуются» теперь бессмысленно.
0
Пару лет назад пробовал программировать с использованием видеокарты.
Бутылочным горлышком был обмен данными между памятью карты и оперативкой.
Тесла в этом плане мне нравится куда больше.
Хотя конечно зависит от задач, не всегда требуется обработка больших массивов данных.
PS: не верю в экзофлоп через 8 лет, технологический рывок в производстве процессоров ожидается только лет через 10, кроме того необходимо будет полносью переписывать весь софт.
Бутылочным горлышком был обмен данными между памятью карты и оперативкой.
Тесла в этом плане мне нравится куда больше.
Хотя конечно зависит от задач, не всегда требуется обработка больших массивов данных.
PS: не верю в экзофлоп через 8 лет, технологический рывок в производстве процессоров ожидается только лет через 10, кроме того необходимо будет полносью переписывать весь софт.
0
По моему опыту, профайлер не всегда правильно показывает причину замедления, я тоже долго грешил на память, оказалось — ветвление.
0
Память, память и еще раз она, разработка алгоритма упирается в нее.
0
В моей задаче пришлось долго подбирать, какую часть засунуть на ускоритель. В результате все-таки получилось найти участок программы, внутри которого ходили большие объемы памяти а снаружи было терпимо (несколько гигабайт за 15 минут). Скорость обмена все ж таки несколько Гб/с, что совсем не мало.
Есть идея попробовать сделать архивацию перед пересылкой, на разреженных данных возможно получить выигрыш.
Есть идея попробовать сделать архивацию перед пересылкой, на разреженных данных возможно получить выигрыш.
0
Есть интересная тенденция: 2 xeon не выдерживает полностью рассчеты на всю мощность 3-х тесл. Очень забавно наблюдать, когда предельное ускорение не достигается не из-за памяти в GPU, а из-за процессоров, которые не успевают ставить задачи.
Кстати компилятор у nvidea кривой и содержит много багов. Например, программа собранная с ключом -О3 может давать результаты совершенно не такие, как с -О2.
Кстати компилятор у nvidea кривой и содержит много багов. Например, программа собранная с ключом -О3 может давать результаты совершенно не такие, как с -О2.
0
Я когда-то написал небольшую заметку насчет использования GPU.
Случайно обнаружил статью на хабре про 1000-ядерные процессоры. В ней сообщается, что в Intel работают на многоядерными процессорами ориентированные прежде всего на научные вычисления. В комментариях оказались противники Intel-а, считающие что видео-чипы победили в войне. По их уверениям, Intel пытается судорожно догнать и не потерять позиции.
Область моей деятельности связана с вычислительной гидро- и аэро-динамикой, поэтому я имею некоторое представление о научных вычислениях. Если вы думаете, что видео-чипы выйдут победителями сражения с Intel? Я думаю, что вы ошибаетесь.
Первое, я не знаю, что должно произойти, чтобы ученые взяли свои библиотеки написанные на фортране лет 10-20 назад и переписали под новые условия. Эти библиотеки написаны не на С++, и не на Java, и даже не на обычном С — они написаны на fortran-е, причем так, что напрямую на видеочипы не переносятся.
Второе, казалось бы, новые технологии должны заставить ученых шевелиться и переписывать, но там безумное количество формул, в которых каждый символ отлажен и выверен годами. При переносе появятся сразу ошибки, которые быстро не выявятся.
Третье, новые алгоритмы, оптимизированные под видео-чипы, требует математического доказательства. Учитывая методы выполнения расчетов на видеокартах, получается нетривиальная задача.
Четвертое, сейчас большинство используют MPI и OpenMP. При выходе даже 48миядерного процессора от Intel — эти средства будут быстро оптимизированы под новые условия — старые программы продолжат свою работу.
Пятое, количество реальных потоков в современных видеокартах, то есть на которых можно запустить счет, составляет 10-ки. Например, у меня в институте на новом супере (гибридном, то есть видеокарты и обычные процессоры на узлах) в видеокарту помещается не больше 32 таких потоков (а по-моему все-таки 16, но точно не помню). И сравнить с аналогичным по производительности 48миядерником, где мы, в отличии от видео-чипов, можем управлять каждым ядром, то видео-чипы смотрятся как-то бледно.
Итого: на данный момент, из-за остановки роста производительности процессоров по частоте и смещения акцента в сторону многоядерности, видео-чипы выглядят привлекательнее для научных разработок. Но я думаю пройдет пару лет, Intel выпустит свои многоядерники на рынок, доступный научным организациям и видео-чипы будут вытеснены. Но я не исключаю, что AMD/nVidia выпустят видеокарты с более дружественными технологиями, чем CUDA и openCL.
Случайно обнаружил статью на хабре про 1000-ядерные процессоры. В ней сообщается, что в Intel работают на многоядерными процессорами ориентированные прежде всего на научные вычисления. В комментариях оказались противники Intel-а, считающие что видео-чипы победили в войне. По их уверениям, Intel пытается судорожно догнать и не потерять позиции.
Область моей деятельности связана с вычислительной гидро- и аэро-динамикой, поэтому я имею некоторое представление о научных вычислениях. Если вы думаете, что видео-чипы выйдут победителями сражения с Intel? Я думаю, что вы ошибаетесь.
Первое, я не знаю, что должно произойти, чтобы ученые взяли свои библиотеки написанные на фортране лет 10-20 назад и переписали под новые условия. Эти библиотеки написаны не на С++, и не на Java, и даже не на обычном С — они написаны на fortran-е, причем так, что напрямую на видеочипы не переносятся.
Второе, казалось бы, новые технологии должны заставить ученых шевелиться и переписывать, но там безумное количество формул, в которых каждый символ отлажен и выверен годами. При переносе появятся сразу ошибки, которые быстро не выявятся.
Третье, новые алгоритмы, оптимизированные под видео-чипы, требует математического доказательства. Учитывая методы выполнения расчетов на видеокартах, получается нетривиальная задача.
Четвертое, сейчас большинство используют MPI и OpenMP. При выходе даже 48миядерного процессора от Intel — эти средства будут быстро оптимизированы под новые условия — старые программы продолжат свою работу.
Пятое, количество реальных потоков в современных видеокартах, то есть на которых можно запустить счет, составляет 10-ки. Например, у меня в институте на новом супере (гибридном, то есть видеокарты и обычные процессоры на узлах) в видеокарту помещается не больше 32 таких потоков (а по-моему все-таки 16, но точно не помню). И сравнить с аналогичным по производительности 48миядерником, где мы, в отличии от видео-чипов, можем управлять каждым ядром, то видео-чипы смотрятся как-то бледно.
Итого: на данный момент, из-за остановки роста производительности процессоров по частоте и смещения акцента в сторону многоядерности, видео-чипы выглядят привлекательнее для научных разработок. Но я думаю пройдет пару лет, Intel выпустит свои многоядерники на рынок, доступный научным организациям и видео-чипы будут вытеснены. Но я не исключаю, что AMD/nVidia выпустят видеокарты с более дружественными технологиями, чем CUDA и openCL.
+2
Ну, т.к. я довольно долго бился с OpenCL, я не питаю больших иллюзий, интеловская система с легкими, но не SIMD ядрами будет очень интересным решением. Однако же, чем «легче» ядра, тем больше их можно засунуть на кристалл, потому граф. ускорители при одной и той же технологии всегда будут на шаг впереди и всегда будут востребованы на своем классе задач.
Насчет 16ти потоков — скорее всего идет речь о 16 группах SIMD потоков, т.е. вы пытаетесь запустить не параллельный по данным код и он делится только на количество микропроцессоров, а не на все их ядра (там же двухуровневая организация).
На Tesla 448 ядер и соответствующим кодом их вполне можно задействовать.
Насчет OpenCL — уже сейчас Intel выпустила его реализацию для процессоров. OpenCL силен тем, что можно напрямую указывать, в каком кэше будут лежать какие данные (сейчас этим оптимизатор занимается автоматом), что позволит получать предсказуемые по производительности результаты на разных платформах. Опять же, я писал в статье, что через OpenCL уже можно управлять целым кластером, так что технология явно универсальна и жизнеспособна.
Насчет 16ти потоков — скорее всего идет речь о 16 группах SIMD потоков, т.е. вы пытаетесь запустить не параллельный по данным код и он делится только на количество микропроцессоров, а не на все их ядра (там же двухуровневая организация).
На Tesla 448 ядер и соответствующим кодом их вполне можно задействовать.
Насчет OpenCL — уже сейчас Intel выпустила его реализацию для процессоров. OpenCL силен тем, что можно напрямую указывать, в каком кэше будут лежать какие данные (сейчас этим оптимизатор занимается автоматом), что позволит получать предсказуемые по производительности результаты на разных платформах. Опять же, я писал в статье, что через OpenCL уже можно управлять целым кластером, так что технология явно универсальна и жизнеспособна.
0
К сожалению, пока нельзя избавиться от проблем, связанных с адаптацией кода под железо. Если у вас есть несколько разных моделей видеокарт — уже на них нужно подгонять под железо.
С универсальными процессорами таких проблем особо не будет.
С универсальными процессорами таких проблем особо не будет.
0
Сайт www.supercomputers.ru лег, однако хабраэффект?
+1
Работаю над фреймворком для генерации случайных чисел.
Начали появляться генераторы адаптированные для графических процессоров.
Учёные тоже не стоят на месте ;)
Начали появляться генераторы адаптированные для графических процессоров.
Учёные тоже не стоят на месте ;)
0
> В этом году намечается масштабная модернизация «Ломоносова» с помощью графических ускорителей, после чего он должен войти в десятку лучших.
Как они будут считать общую производительность, чтобы сравнивать с другими машинами?
Как они будут считать общую производительность, чтобы сравнивать с другими машинами?
0
По стандартной методике, теоретическая производительность, linpack, разница — эффективность.
Т.к. суперкомпов с граф. ускорителями пруд пруди, технология отработана.
Т.к. суперкомпов с граф. ускорителями пруд пруди, технология отработана.
0
Так вот это и не понятно. Получили мы линпак на CPU, потом на GPU — это два совершенно разных линпак-результата и их нельзя просто так складывать. Даже с гетерогенным кластером, на каждом сегменте (с разными CPU) которого запускается отдельный линпак, вопрос о корректности суммирования весьма тонкий, а тут вообще CPU и GPU. Получается у нас 2 независимые характеристики. Тогда и сравнение должно вестись по двум параметрам?
0
Не буду сочинять, не знаю. По идее должны запускать сразу на всем оборудовании. Возможно, именно с этим связана низкая эффективность главного китайского суперкомпа.
0
Интересно, есть ли Java-порты к GPU?
0
Я не явавод, но гугл говорит, что очень много
Даже для ruby есть.
Даже для ruby есть.
0
К списку ответов на вопрос «Зачем все это нужно?» могу добавить также использование суперкомпьютеров для выполнения больших имитационны агентных моделей в масштабе города, страны или целого мира. С миллионами и миллиардами агентов. Как, например, тут.
Хотя, честно говоря, такое количество агентов не всегда необходимо решения конкретной задачи.
Хотя, честно говоря, такое количество агентов не всегда необходимо решения конкретной задачи.
0
Only those users with full accounts are able to leave comments. Log in, please.
Суперкомпьютеры: третья мировая гонка