Комментарии 43
Про обучение: в лаборатории Intel-СПРИНТ (СПбГУ) прошедшим летом проходила школа по High-Performance Computing. В этом году также будет летняя школа, скорее всего, по сходной тематике. Для студентов участие бесплатно, для остальных — не знаю.
Также на сайте лаборатории можно найти литературу по соответствующей тематике.
Также на сайте лаборатории можно найти литературу по соответствующей тематике.
Полагаю там обучают только в «правильном», выгодном для Intel направлении? :-) Или там и кластеры на процессорах + видеокартах AMD тоже изучают? :-)
Нашел на parallel.ru целый список конференций по суперкомпьютингу и около.
Там даже мой Иркутск есть!
parallel.ru/conferences/russian_conferences.html
Там даже мой Иркутск есть!
parallel.ru/conferences/russian_conferences.html
И еще одна ссылка для обучения:
school.hpc-russia.ru/
Летняя школа по суперкомпьютерным технологиям.
Увы, я уже не молод и не попадаю.
school.hpc-russia.ru/
Летняя школа по суперкомпьютерным технологиям.
Увы, я уже не молод и не попадаю.
Автор, зачем ты пишешь о том, в чём не разбираешься? Проблема в программировании под GPGPU не столько в «сложности написания кода», сколько в крайне узком спектре задач и алгоритмов, которые принципиально выигрывают от выполнения на них.
Возможно, я где-то выразился неточно, впрочем где я пишу про «сложность написания кода»? Не нашел даже поиском.
Да, дело не в кодировании а в алгоритмах, и проблема переписывания кода в том, что алгоритмы решения множества задач не параллелятся (по данным или вообще).
Нужно придумывать новые, параллельные, именно в этом одна из главных задач текущей гонки.
Да, дело не в кодировании а в алгоритмах, и проблема переписывания кода в том, что алгоритмы решения множества задач не параллелятся (по данным или вообще).
Нужно придумывать новые, параллельные, именно в этом одна из главных задач текущей гонки.
>программирование для графических ускорителей, как я уже писал, не самое простое занятие
Вот здесь.
Дело не в параллельности, а в ветвлениях.
Вот здесь.
Дело не в параллельности, а в ветвлениях.
Проблема, например, аэродинамики в том, что изначально параллельный процесс описали последовательной моделью, для которой придумали алгоритм. А затем, почему-то стали этот алгоритм параллелить, без оглядки на изначальную параллельность среды.
Для всех современные суперов без GPU есть очень и очень много библиотек с готовыми решениями, зачастую написанными на фортране, выверенные годами. А для GPU нужно не только новые алгоритмы, но огромные трудозатраты на доказательство корректности и выверении алгоритмов.
А если к этому добавить всякие ограничения со стороны nvidea, в виде, например 63 байт под алгоритм и данные на одну группу процессоров в GPU — вот тогда начинается полный ппц.
Для всех современные суперов без GPU есть очень и очень много библиотек с готовыми решениями, зачастую написанными на фортране, выверенные годами. А для GPU нужно не только новые алгоритмы, но огромные трудозатраты на доказательство корректности и выверении алгоритмов.
А если к этому добавить всякие ограничения со стороны nvidea, в виде, например 63 байт под алгоритм и данные на одну группу процессоров в GPU — вот тогда начинается полный ппц.
Основная проблема на GPGPU — это крайне малый объем памяти с доступом за 1-2 такта. Вся остальная память за 100 и больше тактов доступна. Поэтому для вычислительной аэродинамики приходится изгаляться над кодом так, что мама не горюй.
Знакомый аспирант уже задолбался умещать алгоритмы в 63 байта (и это на одной из топывых Тесл).
Знакомый аспирант уже задолбался умещать алгоритмы в 63 байта (и это на одной из топывых Тесл).
«Чем больше узлов, тем меньше надежность, экзафлопные компьютеры будут ломаться непрерывно и при их эксплуатации это должно непрерывно учитываться»
Вспоминаются вакуумные лампы в первых компах, где в среднем 1 лампа сгорала каждые 3-5 минут.
Вспоминаются вакуумные лампы в первых компах, где в среднем 1 лампа сгорала каждые 3-5 минут.
Хорошая статья, но мне немного не нравится терминология и контекст.
Ракетная и ядерная гонка были порождением холодной войны. Сейчас совсем другое время и принципиально другие вызовы. Если и есть гонка, то ее субъектами в гораздо меньшей степени чем раньше являются государства. Это скорее корпорации и отрасли.
Ракетная и ядерная гонка были порождением холодной войны. Сейчас совсем другое время и принципиально другие вызовы. Если и есть гонка, то ее субъектами в гораздо меньшей степени чем раньше являются государства. Это скорее корпорации и отрасли.
Американцы вполне сейчас пользуются своим монополизмом в суперкомпьютерном софте и, понятно, зажимают наших ядерщиков и авиастроителей. Да, слава Богу это не война, но это вызов — и именно на уровне государств.
Я не принадлежу к ура-патриотам, но вполне понимаю, что технологии, затрагивающие национальную безопасность никогда не будут полностью корпоративными.
Я не принадлежу к ура-патриотам, но вполне понимаю, что технологии, затрагивающие национальную безопасность никогда не будут полностью корпоративными.
Наука пользуется достижениями суперкомпьютерных вычислений. А она в значительной степени интернациональна. прошли времена, когда военные технологии были драйвером развития гражданских как минимум с 60-х все наоборот. Опять же холодная война закончилась. рассуждать в терминах «американцы пользуются» теперь бессмысленно.
Пару лет назад пробовал программировать с использованием видеокарты.
Бутылочным горлышком был обмен данными между памятью карты и оперативкой.
Тесла в этом плане мне нравится куда больше.
Хотя конечно зависит от задач, не всегда требуется обработка больших массивов данных.
PS: не верю в экзофлоп через 8 лет, технологический рывок в производстве процессоров ожидается только лет через 10, кроме того необходимо будет полносью переписывать весь софт.
Бутылочным горлышком был обмен данными между памятью карты и оперативкой.
Тесла в этом плане мне нравится куда больше.
Хотя конечно зависит от задач, не всегда требуется обработка больших массивов данных.
PS: не верю в экзофлоп через 8 лет, технологический рывок в производстве процессоров ожидается только лет через 10, кроме того необходимо будет полносью переписывать весь софт.
По моему опыту, профайлер не всегда правильно показывает причину замедления, я тоже долго грешил на память, оказалось — ветвление.
Память, память и еще раз она, разработка алгоритма упирается в нее.
В моей задаче пришлось долго подбирать, какую часть засунуть на ускоритель. В результате все-таки получилось найти участок программы, внутри которого ходили большие объемы памяти а снаружи было терпимо (несколько гигабайт за 15 минут). Скорость обмена все ж таки несколько Гб/с, что совсем не мало.
Есть идея попробовать сделать архивацию перед пересылкой, на разреженных данных возможно получить выигрыш.
Есть идея попробовать сделать архивацию перед пересылкой, на разреженных данных возможно получить выигрыш.
Есть интересная тенденция: 2 xeon не выдерживает полностью рассчеты на всю мощность 3-х тесл. Очень забавно наблюдать, когда предельное ускорение не достигается не из-за памяти в GPU, а из-за процессоров, которые не успевают ставить задачи.
Кстати компилятор у nvidea кривой и содержит много багов. Например, программа собранная с ключом -О3 может давать результаты совершенно не такие, как с -О2.
Кстати компилятор у nvidea кривой и содержит много багов. Например, программа собранная с ключом -О3 может давать результаты совершенно не такие, как с -О2.
Я когда-то написал небольшую заметку насчет использования 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.
Ну, т.к. я довольно долго бился с OpenCL, я не питаю больших иллюзий, интеловская система с легкими, но не SIMD ядрами будет очень интересным решением. Однако же, чем «легче» ядра, тем больше их можно засунуть на кристалл, потому граф. ускорители при одной и той же технологии всегда будут на шаг впереди и всегда будут востребованы на своем классе задач.
Насчет 16ти потоков — скорее всего идет речь о 16 группах SIMD потоков, т.е. вы пытаетесь запустить не параллельный по данным код и он делится только на количество микропроцессоров, а не на все их ядра (там же двухуровневая организация).
На Tesla 448 ядер и соответствующим кодом их вполне можно задействовать.
Насчет OpenCL — уже сейчас Intel выпустила его реализацию для процессоров. OpenCL силен тем, что можно напрямую указывать, в каком кэше будут лежать какие данные (сейчас этим оптимизатор занимается автоматом), что позволит получать предсказуемые по производительности результаты на разных платформах. Опять же, я писал в статье, что через OpenCL уже можно управлять целым кластером, так что технология явно универсальна и жизнеспособна.
Насчет 16ти потоков — скорее всего идет речь о 16 группах SIMD потоков, т.е. вы пытаетесь запустить не параллельный по данным код и он делится только на количество микропроцессоров, а не на все их ядра (там же двухуровневая организация).
На Tesla 448 ядер и соответствующим кодом их вполне можно задействовать.
Насчет OpenCL — уже сейчас Intel выпустила его реализацию для процессоров. OpenCL силен тем, что можно напрямую указывать, в каком кэше будут лежать какие данные (сейчас этим оптимизатор занимается автоматом), что позволит получать предсказуемые по производительности результаты на разных платформах. Опять же, я писал в статье, что через OpenCL уже можно управлять целым кластером, так что технология явно универсальна и жизнеспособна.
Сайт www.supercomputers.ru лег, однако хабраэффект?
Работаю над фреймворком для генерации случайных чисел.
Начали появляться генераторы адаптированные для графических процессоров.
Учёные тоже не стоят на месте ;)
Начали появляться генераторы адаптированные для графических процессоров.
Учёные тоже не стоят на месте ;)
> В этом году намечается масштабная модернизация «Ломоносова» с помощью графических ускорителей, после чего он должен войти в десятку лучших.
Как они будут считать общую производительность, чтобы сравнивать с другими машинами?
Как они будут считать общую производительность, чтобы сравнивать с другими машинами?
По стандартной методике, теоретическая производительность, linpack, разница — эффективность.
Т.к. суперкомпов с граф. ускорителями пруд пруди, технология отработана.
Т.к. суперкомпов с граф. ускорителями пруд пруди, технология отработана.
Так вот это и не понятно. Получили мы линпак на CPU, потом на GPU — это два совершенно разных линпак-результата и их нельзя просто так складывать. Даже с гетерогенным кластером, на каждом сегменте (с разными CPU) которого запускается отдельный линпак, вопрос о корректности суммирования весьма тонкий, а тут вообще CPU и GPU. Получается у нас 2 независимые характеристики. Тогда и сравнение должно вестись по двум параметрам?
Не буду сочинять, не знаю. По идее должны запускать сразу на всем оборудовании. Возможно, именно с этим связана низкая эффективность главного китайского суперкомпа.
Интересно, есть ли Java-порты к GPU?
Я не явавод, но гугл говорит, что очень много
Даже для ruby есть.
Даже для ruby есть.
К списку ответов на вопрос «Зачем все это нужно?» могу добавить также использование суперкомпьютеров для выполнения больших имитационны агентных моделей в масштабе города, страны или целого мира. С миллионами и миллиардами агентов. Как, например, тут.
Хотя, честно говоря, такое количество агентов не всегда необходимо решения конкретной задачи.
Хотя, честно говоря, такое количество агентов не всегда необходимо решения конкретной задачи.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Суперкомпьютеры: третья мировая гонка