Возможно, я где-то выразился неточно, впрочем где я пишу про «сложность написания кода»? Не нашел даже поиском.
Да, дело не в кодировании а в алгоритмах, и проблема переписывания кода в том, что алгоритмы решения множества задач не параллелятся (по данным или вообще).
Нужно придумывать новые, параллельные, именно в этом одна из главных задач текущей гонки.
Дык, именно на этом и нужно зарабатывать. Это реальная, сложная и очень ответственная работа (сам специалист-консультант по восьмерке-торговле). Открытое решение с платной поддержкой.
Выводы я уже озвучил — для больших по времени или памяти задач — тесла.
О! Нашел-таки на сайте статью!
Сейчас на первом месте китайский комп на tesla. Вроде был еще один на amd http://hitech.newsru.com/article/15nov2010/cnno1
но в последних рейтингах я его не нашел, видимо произвели апгрейд на тесла. китайцы на www.top500.org
Я про неустойчивость результата при длительных вычислениях (сутки и более).
Даже на конференции один из докладчиков рассказывал, что при подсчете на двух картах получались разные результаты. Проверифицировали третьей, одна оказалась несколько глючной. Это критично на научных задачах.
Также опираюсь на статью в журнале «Суперкомпьютеры», её, к сожалению, нет на их сайте. Там сравнивались теслы и топовые игровые карты.
Да, возможность работы с динамической памятью в коде на ускорителе была анонсирована в CUDA 4.
CUDA пытаются сделать кроссплатформенным стандартом (проект OCELOT) но я в это не очень верю.
У OpenCL еще один козырь появился — AMD начинает выпуск своих ускорителей вычислений (типа Tesla)
Все зависит от задачи.
Топовые графические карты быстрее и дешевле Tesla.
Но
1) У них меньше объем (видео)памяти. Это критично, например, для нашей молекулярной динамики — большую модель просто не загрузишь.
2) На них менее надежные вычисления. Если на игровой карте раз в час игры промелькнет артефакт, это допустимо. А вот если неправильно посчитается тот же реактивный двигатель… На теслах есть контроль памяти по четности, для критичных алгоритмов, которые считаются сутками, это критично, иначе придется покупать две карты, запускать одинаковые задачи и сравнивать результат для верификации.
3) Сам встречался с тем, что на граф. карте есть предел по времени на одну нитку вычислений, если она «думает» больше, считается зависшей и прибивается, для графики это допустимо — для вычислений — нет.
Насчет же эффективности — у вышеупомянутых двигателистов и распознавателей речи выигрыш в десятки раз, причем это наши разработки. Для молекулярной динамики — выигрыш по ссылке в статье и он тоже очень серьезный.
В общем, все зависит от задач. Сейчас нам (программистам) светит смена парадигмы программирования, переход на параллелизацию всего и вся. Постараюсь в ближайшее время по материалам конференции написать на Хабре статью.
Все это очень интересно, придется много учиться.
Я еще не написал про грабли, связанные с банками памяти… Но это уже тонкие оптимизации, доступные в документации. В статье я постарался сконцентрироваться на не вполне очевидных вещах, без которых нельзя программировать даже если знаешь саму технологию. В документации они описаны, по моему мнению, недостаточно.
Я еще не написал про грабли, связанные с банками памяти… Но это уже тонкие оптимизации, доступные в документации. В статье я постарался сконцентрироваться на не вполне очевидных вещах, без которых нельзя программировать даже если знаешь саму технологию. В документации они описаны, по моему мнению, недостаточно.
По докладу пермяков (у них индустриальный подход, попробовали под свой алгоритм обе технологии и все доступные ускорители, и Intel и AMD, штук 8) на их задаче не было разницы в скорости CUDA-OpenCL, а AMDшные решения оказались чуть быстрее.
С подходом (CUDA-заказные, OpenCL-универсальные) соглашусь. Впрочем, внутренняя логика программирования у этих технологий практически одинаковая, они оба достаточно низкоуровневые и «железо» диктует и возможности, и проблемы.
Да. Затем сюда и пришёл. На той же ПАВТ всего два доклада с реальным ускорением на параллельных ускорителях для сложных реальных задач (распознаватели речи и пермские двигателисты).
По OpenCL в рунете — почти исключительно Хабр.
Это все очень мало, начало. Будем работать!
Скрининг по гомологии, алгоритмы группы genbee, www.bri-shur.com
Сейчас там стоит OpenMP шная версия т.к. два серверных nehalem рвут по производительности достаточно слабую карточку GF120 на текущем (честно говоря — очень тяжелом для массового параллелизма) алгоритме.
На моем же рабочем компьютере FERMIшная GTS450 ненамного, но обходит i5-650.
FERMI, по моему опыту, гораздо лучше работает с «плохими» алгоритмами, хотя там еще пахать и пахать.
Сейчас только что закончилась конференция ПаВТ-2011, выступал представитель NVIDIA представляя CUDA 4. Говорил что одна из основных задач — уменьшить специфичность программирования граф. ускорителей.
Но до конца все равно не удастся, все равно будет SIMD. Может, хоть с памятью разберутся — сейчас приходится играть с банками данных и распараллеливать данные даже на чтение (именно в этом Fermi лучше предыдущих архитектур).
В общем, все очень интересно, параллельное программирование — очень отдельная и сложная тема, распараллеливать алгоритм на миллион ядер пока никто не умеет, а уже нужно.
Да, дело не в кодировании а в алгоритмах, и проблема переписывания кода в том, что алгоритмы решения множества задач не параллелятся (по данным или вообще).
Нужно придумывать новые, параллельные, именно в этом одна из главных задач текущей гонки.
О! Нашел-таки на сайте статью!
Сейчас на первом месте китайский комп на tesla. Вроде был еще один на amd
http://hitech.newsru.com/article/15nov2010/cnno1
но в последних рейтингах я его не нашел, видимо произвели апгрейд на тесла.
китайцы на www.top500.org
Даже на конференции один из докладчиков рассказывал, что при подсчете на двух картах получались разные результаты. Проверифицировали третьей, одна оказалась несколько глючной. Это критично на научных задачах.
Также опираюсь на статью в журнале «Суперкомпьютеры», её, к сожалению, нет на их сайте. Там сравнивались теслы и топовые игровые карты.
CUDA пытаются сделать кроссплатформенным стандартом (проект OCELOT) но я в это не очень верю.
У OpenCL еще один козырь появился — AMD начинает выпуск своих ускорителей вычислений (типа Tesla)
Топовые графические карты быстрее и дешевле Tesla.
Но
1) У них меньше объем (видео)памяти. Это критично, например, для нашей молекулярной динамики — большую модель просто не загрузишь.
2) На них менее надежные вычисления. Если на игровой карте раз в час игры промелькнет артефакт, это допустимо. А вот если неправильно посчитается тот же реактивный двигатель… На теслах есть контроль памяти по четности, для критичных алгоритмов, которые считаются сутками, это критично, иначе придется покупать две карты, запускать одинаковые задачи и сравнивать результат для верификации.
3) Сам встречался с тем, что на граф. карте есть предел по времени на одну нитку вычислений, если она «думает» больше, считается зависшей и прибивается, для графики это допустимо — для вычислений — нет.
Насчет же эффективности — у вышеупомянутых двигателистов и распознавателей речи выигрыш в десятки раз, причем это наши разработки. Для молекулярной динамики — выигрыш по ссылке в статье и он тоже очень серьезный.
В общем, все зависит от задач. Сейчас нам (программистам) светит смена парадигмы программирования, переход на параллелизацию всего и вся. Постараюсь в ближайшее время по материалам конференции написать на Хабре статью.
Все это очень интересно, придется много учиться.
С подходом (CUDA-заказные, OpenCL-универсальные) соглашусь. Впрочем, внутренняя логика программирования у этих технологий практически одинаковая, они оба достаточно низкоуровневые и «железо» диктует и возможности, и проблемы.
По OpenCL в рунете — почти исключительно Хабр.
Это все очень мало, начало. Будем работать!
Сейчас там стоит OpenMP шная версия т.к. два серверных nehalem рвут по производительности достаточно слабую карточку GF120 на текущем (честно говоря — очень тяжелом для массового параллелизма) алгоритме.
На моем же рабочем компьютере FERMIшная GTS450 ненамного, но обходит i5-650.
FERMI, по моему опыту, гораздо лучше работает с «плохими» алгоритмами, хотя там еще пахать и пахать.
Сейчас только что закончилась конференция ПаВТ-2011, выступал представитель NVIDIA представляя CUDA 4. Говорил что одна из основных задач — уменьшить специфичность программирования граф. ускорителей.
Но до конца все равно не удастся, все равно будет SIMD. Может, хоть с памятью разберутся — сейчас приходится играть с банками данных и распараллеливать данные даже на чтение (именно в этом Fermi лучше предыдущих архитектур).
В общем, все очень интересно, параллельное программирование — очень отдельная и сложная тема, распараллеливать алгоритм на миллион ядер пока никто не умеет, а уже нужно.