Доклад 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 минут). Скорость обмена все ж таки несколько Гб/с, что совсем не мало.
Есть идея попробовать сделать архивацию перед пересылкой, на разреженных данных возможно получить выигрыш.
Американцы вполне сейчас пользуются своим монополизмом в суперкомпьютерном софте и, понятно, зажимают наших ядерщиков и авиастроителей. Да, слава Богу это не война, но это вызов — и именно на уровне государств.
Я не принадлежу к ура-патриотам, но вполне понимаю, что технологии, затрагивающие национальную безопасность никогда не будут полностью корпоративными.
Развитие идет по спирали.
Впрочем, мозги достаточно надежно думают на принципиально ненадежных элементах, так что, думаю, начиная с некоторой сложности все равно придется учиться программировать ненадежные системы.
Интел уже выпустила альфу своей реализации OpenCL. Не думаю, что они идут совсем уж своим путем, ведь дело не в каких-то фишечках оптимизации, а в проблемах программирования для гетерогенной параллельной архитектуры.
Там даже мой Иркутск есть!
parallel.ru/conferences/russian_conferences.html
Даже для ruby есть.
«Страна, которая хочет достичь превосходства в конкурентной борьбе, должна превосходить конкурентов в области вычислений»
Т.к. суперкомпов с граф. ускорителями пруд пруди, технология отработана.
А насчет огромных трудозатрат — это да, но кто первый это сделает, тот и будет на коне. Сейчас задача облегчается тем, что раньше для программирования Cray нужно было покупать Cray, а теперь достаточно домашней видеокарты.
Вспоминаем экономию памяти, как в 60е годы.
Насчет 16ти потоков — скорее всего идет речь о 16 группах SIMD потоков, т.е. вы пытаетесь запустить не параллельный по данным код и он делится только на количество микропроцессоров, а не на все их ядра (там же двухуровневая организация).
На Tesla 448 ядер и соответствующим кодом их вполне можно задействовать.
Насчет OpenCL — уже сейчас Intel выпустила его реализацию для процессоров. OpenCL силен тем, что можно напрямую указывать, в каком кэше будут лежать какие данные (сейчас этим оптимизатор занимается автоматом), что позволит получать предсказуемые по производительности результаты на разных платформах. Опять же, я писал в статье, что через OpenCL уже можно управлять целым кластером, так что технология явно универсальна и жизнеспособна.
2) ну, и с gcc так вполне бывает.
Есть идея попробовать сделать архивацию перед пересылкой, на разреженных данных возможно получить выигрыш.
Я не принадлежу к ура-патриотам, но вполне понимаю, что технологии, затрагивающие национальную безопасность никогда не будут полностью корпоративными.
Впрочем, мозги достаточно надежно думают на принципиально ненадежных элементах, так что, думаю, начиная с некоторой сложности все равно придется учиться программировать ненадежные системы.