Правда это тесла а не Geforce 580. На джифорсах я бы считать динамику не стал — когда вычисления занимают сутки, большая вероятность сбоя, видюхи на другие режимы и другое число ошибок рассчитаны.
Не знаю, как в Москве — но в моем Иркутске если кричать «на помощь!» то помогают, по моему опыту, всегда, даже посреди ночи выбегают (девчонка кричала).
А если не кричать и не привлекать внимание — не помогают.
Доклад PITAC (The President’s Information Technology Advisory Committee) Вычислительные науки: обеспечение превосходства (конкурентоспособности) Америки
«Страна, которая хочет достичь превосходства в конкурентной борьбе, должна превосходить конкурентов в области вычислений»
Не буду сочинять, не знаю. По идее должны запускать сразу на всем оборудовании. Возможно, именно с этим связана низкая эффективность главного китайского суперкомпа.
По стандартной методике, теоретическая производительность, linpack, разница — эффективность.
Т.к. суперкомпов с граф. ускорителями пруд пруди, технология отработана.
Ну почему же не будет? У pentium4 и core вполне разная оптимизация, разве что этим занимаются компилеры и мы это не видим. Так будет и для видеокарт, тем более что у OpenCL jit-компилятор.
48 кб + 64 кб константной памяти.
А насчет огромных трудозатрат — это да, но кто первый это сделает, тот и будет на коне. Сейчас задача облегчается тем, что раньше для программирования Cray нужно было покупать Cray, а теперь достаточно домашней видеокарты.
Насколько мне не изменяет мой склероз, там 48 кб… да, мало, сам знаю, регистров еще меньше, но у процессоров так же. Но будет еще меньше, я не написал в статье еще одну проблему — количество памяти на ядро все время уменьшается.
Вспоминаем экономию памяти, как в 60е годы.
Ну, т.к. я довольно долго бился с OpenCL, я не питаю больших иллюзий, интеловская система с легкими, но не SIMD ядрами будет очень интересным решением. Однако же, чем «легче» ядра, тем больше их можно засунуть на кристалл, потому граф. ускорители при одной и той же технологии всегда будут на шаг впереди и всегда будут востребованы на своем классе задач.
Насчет 16ти потоков — скорее всего идет речь о 16 группах SIMD потоков, т.е. вы пытаетесь запустить не параллельный по данным код и он делится только на количество микропроцессоров, а не на все их ядра (там же двухуровневая организация).
На Tesla 448 ядер и соответствующим кодом их вполне можно задействовать.
Насчет OpenCL — уже сейчас Intel выпустила его реализацию для процессоров. OpenCL силен тем, что можно напрямую указывать, в каком кэше будут лежать какие данные (сейчас этим оптимизатор занимается автоматом), что позволит получать предсказуемые по производительности результаты на разных платформах. Опять же, я писал в статье, что через OpenCL уже можно управлять целым кластером, так что технология явно универсальна и жизнеспособна.
В моей задаче пришлось долго подбирать, какую часть засунуть на ускоритель. В результате все-таки получилось найти участок программы, внутри которого ходили большие объемы памяти а снаружи было терпимо (несколько гигабайт за 15 минут). Скорость обмена все ж таки несколько Гб/с, что совсем не мало.
Есть идея попробовать сделать архивацию перед пересылкой, на разреженных данных возможно получить выигрыш.
www.nvidia.ru/page/gromacs_on_tesla.html
(Перейдите уж по ссылке, там много чего есть)
Если интересна не только молекулярная динамика, то
www.nvidia.com/object/tesla_bio_workbench.html
Правда это тесла а не Geforce 580. На джифорсах я бы считать динамику не стал — когда вычисления занимают сутки, большая вероятность сбоя, видюхи на другие режимы и другое число ошибок рассчитаны.
www.nvidia.ru/page/amber_on_tesla.html
А если не кричать и не привлекать внимание — не помогают.
school.hpc-russia.ru/
Летняя школа по суперкомпьютерным технологиям.
Увы, я уже не молод и не попадаю.
Там даже мой Иркутск есть!
parallel.ru/conferences/russian_conferences.html
Даже для ruby есть.
«Страна, которая хочет достичь превосходства в конкурентной борьбе, должна превосходить конкурентов в области вычислений»
Т.к. суперкомпов с граф. ускорителями пруд пруди, технология отработана.
А насчет огромных трудозатрат — это да, но кто первый это сделает, тот и будет на коне. Сейчас задача облегчается тем, что раньше для программирования Cray нужно было покупать Cray, а теперь достаточно домашней видеокарты.
Вспоминаем экономию памяти, как в 60е годы.
Насчет 16ти потоков — скорее всего идет речь о 16 группах SIMD потоков, т.е. вы пытаетесь запустить не параллельный по данным код и он делится только на количество микропроцессоров, а не на все их ядра (там же двухуровневая организация).
На Tesla 448 ядер и соответствующим кодом их вполне можно задействовать.
Насчет OpenCL — уже сейчас Intel выпустила его реализацию для процессоров. OpenCL силен тем, что можно напрямую указывать, в каком кэше будут лежать какие данные (сейчас этим оптимизатор занимается автоматом), что позволит получать предсказуемые по производительности результаты на разных платформах. Опять же, я писал в статье, что через OpenCL уже можно управлять целым кластером, так что технология явно универсальна и жизнеспособна.
2) ну, и с gcc так вполне бывает.
Есть идея попробовать сделать архивацию перед пересылкой, на разреженных данных возможно получить выигрыш.