Читая веб и блоги: CUDA и прочее программирование на NVidia 8800
На удивление мало жизни происходит по запросу 'NVidia CUDA' в поиске по блогам и новостям. Что у Яндекса, что у Google. Мне это сильно удивительно - штука многообещающая, первая версия SDK датирована ноябрем (появилась примерно 1-го декабря), публичный SDK появился практически месяц назад, а большинство упоминаний в духе "вот вышло", в крайнем случае "читал доку". Таких текстов - навалом, маркетинг NVidia работает. Но скучно.
Помимо форумов NVidia, где заводится по 5-6 новых топиков в день, интересных публикаций немного.
Для начала: Beyond3D опубликовал большой текст про CUDA. Более подробный, чем все что я видел до сих пор (ну, кроме собственно документации).
Bryan O Sullivan критикует CUDA и предрекает тяжелую жизнь.
Цитаты с комментариями:
Given the degree of manual control over variable placement that NVIDIA s C extensions seem to enforce, it s not clear to me that their compiler team has had a chance to automate any of the transfer of data between levels of the memory hierarchy yet.А вот на мой взгляд, наоборот плохо что часть функционала прячется компилятором/драйвером/scheduler и его нельзя оттуда достать. Если посмотреть на эффективные реализации BLAS, то видно что критичный код там или выписан руками под разные архитектуры или еще и подбирается наиболее эффективная реализация на конкретной машине.
И то, что NVidia всячески просит делать всего побольше - тредов, блоков исполнения и т.п. , а компилятор и аппаратура разберутся - это хорошо для масштабирования на будущие системы /наверное/, но будет субоптимально на конкретной железке.
We have plenty of previous examples of hardware that failed to live up to their early marketing promise, from the i860 to the PS3. CUDA looks set to follow in their footsteps: I expect that it will take vast amounts of work for programmers to get halfway decent performance out of a CUDA application, and that few will achieve more than 10% of theoretical peak performance.С одной стороны, самописный код писать тяжело, во всяком случае по первости. Т.е. парадигма тяжелая, рекомендации довольно размытые, SDK неидеальный. Концепция быстрой памяти, которую заполняем руками для 21-го века довольно неожиданна :).
С другой стороны, есть BLAS, есть FFT. Добавить LAPACK и некоторое количество целочисленных библиотек (сортировка, деревья строк и т.п.) и будет счастье. Ну и асинхронность, конечно. Т.е. ~90% приложений смогут получить весьма приличный speedup (в разы) за 600 баксофф.
Комментаторы (в той же записи) впрочем, не согласны.
John StoneА я SSE3 с трудом читаю со словарем, отчего мне CUDA только проще.
While some of the criticisms in this article are valid, I ve found writing CUDA programs no more difficult than convincing vectorizing/SSE-capable compilers for regular CPUs to do something useful.
отсюдаВот тут не могу ничего сказать. Самое мутное для newcomer-а место в CUDA - это работа с shared memory и пулами тредов. Мне потребовалась большая переписка с производителем, чтобы в голове щелкнуло и все встало на свои места.
Working on the Cell was soo much easier!
У Cell, как я понимаю, все проще: есть 8 SPE, у каждого - своя память. Пока мы работаем с этой памятью - все очень прозрачно. А вот общение с внешним миром непросто. А в общении с памятью - не такой и большой bandwidth (в сравнении с G80).
Comments
ссылка на "Beyond3D опубликовал большой текст про CUDA" бита
ссылка на "Beyond3D опубликовал большой текст про CUDA" битая...
вот рабочая
http://www.beyond3d.com/content/articles/12/
поправил, спасибо.
поправил, спасибо.