Но там ведь память не безумно быстрая. 25Gb/s. У 8800 намеряли (а не по спекам) - 50.
Собственно, я не против задумки, да и вообще многопроцессорность с общей памятью - это всеобщее будущее. Но на фоне видеокарт текущий Cell выглядит не потрясающе.
Собственно, идея разумная, ибо драйвер может компилировать по-разному для разного железа. Но идея оптимизирующего компилятора (который может потратить на страницу кода и пять минут) мне ближе.
Проще - взять G80. Потому что она на каждом прилавке, можно вставить в PCI-e-16 и любить
как вздумается (в UT2004 поиграть, например).
Cell в составе PS3 - бессмысленен, слишком мало памяти. Сопроцессорных плат пока нет, а когда будут - цены обещают заоблачные.
Потом, с производительностью тоже не все понятно. Формально Cell - это 200+ GFLOPS на single precision.
Однако для матриц 1000x1000 IBM-цы получили 73Gflops. Это много, примерно как два Core2Duo 6700 :).
Только вот у меня - на оптимизированном под старую карту примере от RapidMind на G80 получается 105 Gflop/s на том же размере.
А все эти vray-и - там как код написан ? Мои эксперименты показывают, что ручное написание под SSE3 дает ~10-15-кратный прирост производительности. описание эксперимента
Потом, Core2 - это формально 8 операций на такт (две операции с 4-компонентными векторами), 4 ядра на 3 гигагерца - 100Gflop/s в теории. В практике получается 5.2
У G80 NV насчитала 520 Gflop/s - это 3 операции на такт. MAD и ADD - получается 3.
Но это куда более лукавый подсчет, чем просто простая и сложная SSE-операция.
Неформально - выигрыш будет на том, что Core2 (Woodcrest) уже обратно уперт в шину,
а видеокарты - тоже уперты, но на гораздо более высоких скоростях.
Две проблемы я там ниже обозначил. Третья - это поддержка scatter - в G80 технологически
можно, а скорость не знаю пока.
Все остальное вроде бы решено (в G80) - такой из себя мультипроцессорный компьютер.
CUDA - это надстройка над C (со спецификациями типа Storage для переменных - в локальной
для процессора памяти, в потоковой и так далее). Хотя реальная компиляция в код идет,
как мне кажется, в драйвере.
"Узко специализированный, жестко фиксированный" функционал очень давно кончился. Уже несколько лет как. Программируемые шейдеры были требованием 8-го DirectX, а это 2000-й год.
Тот же 8-й DX требовал уже поддержки плавающей точки.
Понятно, что аппаратно DX8 поддержали не сразу, но первая программируемая карта - это 3-й Geforce, 2001-й год.
Для компьютерной техники 6 лет - это целое поколение, если не два.
На самом деле, основных проблем в вычислениях на карте две
1) железо поддерживает только 32-битную плавающую точку. Этого для задач реального размера - мало
2) Работа с 32-битными целыми (по меньшей мере на G80) - очень медленная. Типа 10 тактов на
операцию (вместо двух).
Обе проблемы, естественно, решат как-то, NVIdia обещает 64-bit float прямо в этом году.
Но тема - очень горячая, хотя и до крайности сырая: CUDA проанонсировали в ноябре, альфа-версия инструментальных средств появилась в декабре, а что-то с чем можно работать появилось только-только.
Без CUDA - это все был жуткий онанизм, с написанием вычислительных шейдеров на GLSL или HLSL. Но писали. Заметим, что Apple и тут впереди планеты всей, Image Core Services используют видюху. Хотя помогает не очень.
А какая парадигма программирования от этого спасет? Если учитывать, что если меняется иерархия объектов то меняется и логика из работы и взаимодействия.
На самом деле, loose-иерархия объектов, причем желательно без ограничения прав доступа - это очень хорошо. Я за последние лет 5 несколько раз занимался расширением функциональности ООП-программ. И это было мучительно, обычно приходится протаскивать какие-то дополнительные параметры/данные/whatever на очень низкий уровень иерархии, а потом столь же мучительно выносить результаты назад.
А если бы алгоритмы были бы отделены от данных - ничего этого бы не было.
Любая парадигма/техника ценна не сама по себе, а только когда не мешает. Если мешает - на помойку.
Предварительно надо подумать нужна ли вообще такая абстракция или лучше выбрать другой уровень абстракции
Так если не нравится - значит надо чинить.
В таком случае какой парадигмы программирования придерживаетесь?
Думать надо верхней жопой. Вот и вся парадигма.
Прекрасно. Значит договорились, что для объектов с очевидной иерархией ООП не нужно.
Неужели с неочевидной будет лучше ?
ООП переносит фокус на проектирование и это прекрасно. Но если потом потребовалась смена функциональности, то чем крепче была иерархия объектов, тем больше она нас поимеет.
Опять только на куски, чтобы не растекаться. Детей пора гулять.
Процедурное программирование рулит? :) В ООП необходимость есть особенно в сложных проектах
ООП - это очень хорошо, пока target не переместилась и не выяснилось, что наша иерархия объектов перестала отражать предметную область.
За последние 16 лет я такое наблюдал регулярно.
Вот это, как раз, абсолютно пофигу. Не нравятся средства языка - ну напишите один раз нашлепку сверху.
А зачем?
А если не нравится ? Это же один эпизод среди человеко-годов в проекте.
Если не влезают в RAM, то с этим надо что-то делать. Решение в лоб это нарастить память чтоб влезало или же делать прекешинг того что наиболее часто используется.
Ну а я о чем говорю ? Ровно о том, что из памяти отдать даже несколько тысяч запросов/сек с одного тазика - не бог весть какая задача. А из базы, точнее с диска, при реальной latency миллисекунд в 20 - ничего не выйдет.
Извините это не вы говорили в самом начале что ООП не догма? :)
То, что я не считаю ООП догмой не означает, что я незнаком с инструментарием.
Но там ведь память не безумно быстрая. 25Gb/s. У 8800 намеряли (а не по спекам) - 50.
Собственно, я не против задумки, да и вообще многопроцессорность с общей памятью - это всеобщее будущее. Но на фоне видеокарт текущий Cell выглядит не потрясающе.
Собственно, идея разумная, ибо драйвер может компилировать по-разному для разного железа. Но идея оптимизирующего компилятора (который может потратить на страницу кода и пять минут) мне ближе.
как вздумается (в UT2004 поиграть, например).
Cell в составе PS3 - бессмысленен, слишком мало памяти. Сопроцессорных плат пока нет, а когда будут - цены обещают заоблачные.
Потом, с производительностью тоже не все понятно. Формально Cell - это 200+ GFLOPS на single precision.
Однако для матриц 1000x1000 IBM-цы получили 73Gflops. Это много, примерно как два Core2Duo 6700 :).
Только вот у меня - на оптимизированном под старую карту примере от RapidMind на G80 получается 105 Gflop/s на том же размере.
описание эксперимента
Потом, Core2 - это формально 8 операций на такт (две операции с 4-компонентными векторами), 4 ядра на 3 гигагерца - 100Gflop/s в теории. В практике получается 5.2
У G80 NV насчитала 520 Gflop/s - это 3 операции на такт. MAD и ADD - получается 3.
Но это куда более лукавый подсчет, чем просто простая и сложная SSE-операция.
Неформально - выигрыш будет на том, что Core2 (Woodcrest) уже обратно уперт в шину,
а видеокарты - тоже уперты, но на гораздо более высоких скоростях.
можно, а скорость не знаю пока.
Все остальное вроде бы решено (в G80) - такой из себя мультипроцессорный компьютер.
CUDA - это надстройка над C (со спецификациями типа Storage для переменных - в локальной
для процессора памяти, в потоковой и так далее). Хотя реальная компиляция в код идет,
как мне кажется, в драйвере.
Тот же 8-й DX требовал уже поддержки плавающей точки.
Понятно, что аппаратно DX8 поддержали не сразу, но первая программируемая карта - это 3-й Geforce, 2001-й год.
Для компьютерной техники 6 лет - это целое поколение, если не два.
1) железо поддерживает только 32-битную плавающую точку. Этого для задач реального размера - мало
2) Работа с 32-битными целыми (по меньшей мере на G80) - очень медленная. Типа 10 тактов на
операцию (вместо двух).
Обе проблемы, естественно, решат как-то, NVIdia обещает 64-bit float прямо в этом году.
Но тема - очень горячая, хотя и до крайности сырая: CUDA проанонсировали в ноябре, альфа-версия инструментальных средств появилась в декабре, а что-то с чем можно работать появилось только-только.
Без CUDA - это все был жуткий онанизм, с написанием вычислительных шейдеров на GLSL или HLSL. Но писали. Заметим, что Apple и тут впереди планеты всей, Image Core Services используют видюху. Хотя помогает не очень.
ссылка на Wired
Ссылки по теме:
http://www.wired.com/news/technology/com…,72090-2.html?tw=wn_story_page_next2
http://www.gpgpu.org/cgi-bin/blosxom.cgi
http://developer.nvidia.com/object/cuda.…
Не говоря о том, что теме в реальных вычислениях - уже года три, если не больше. Кластеры строят.
Но получаться будет албанский.
1) не важно, каким шилом ковырять
2) выбор шила не определяется достоинствами языка
http://public.yahoo.com/~radwin/talks/ph…
А причем тут вообще mod_php я совсем не понял.
Yahoo использует FreeBSD/Apache/PHP/MySQL
Не совсем LAMP, но почти.
И чем хардкорнее был ОО в исходной программе, тем хуже.
Тогда нас поимеют паттерны.
На самом деле, loose-иерархия объектов, причем желательно без ограничения прав доступа - это очень хорошо. Я за последние лет 5 несколько раз занимался расширением функциональности ООП-программ. И это было мучительно, обычно приходится протаскивать какие-то дополнительные параметры/данные/whatever на очень низкий уровень иерархии, а потом столь же мучительно выносить результаты назад.
А если бы алгоритмы были бы отделены от данных - ничего этого бы не было.
Любая парадигма/техника ценна не сама по себе, а только когда не мешает. Если мешает - на помойку.
Предварительно надо подумать нужна ли вообще такая абстракция или лучше выбрать другой уровень абстракции
Так если не нравится - значит надо чинить.
В таком случае какой парадигмы программирования придерживаетесь?
Думать надо верхней жопой. Вот и вся парадигма.
Неужели с неочевидной будет лучше ?
ООП переносит фокус на проектирование и это прекрасно. Но если потом потребовалась смена функциональности, то чем крепче была иерархия объектов, тем больше она нас поимеет.
Процедурное программирование рулит? :) В ООП необходимость есть особенно в сложных проектах
ООП - это очень хорошо, пока target не переместилась и не выяснилось, что наша иерархия объектов перестала отражать предметную область.
За последние 16 лет я такое наблюдал регулярно.
Вот это, как раз, абсолютно пофигу. Не нравятся средства языка - ну напишите один раз нашлепку сверху.
А зачем?
А если не нравится ? Это же один эпизод среди человеко-годов в проекте.
Если не влезают в RAM, то с этим надо что-то делать. Решение в лоб это нарастить память чтоб влезало или же делать прекешинг того что наиболее часто используется.
Ну а я о чем говорю ? Ровно о том, что из памяти отдать даже несколько тысяч запросов/сек с одного тазика - не бог весть какая задача. А из базы, точнее с диска, при реальной latency миллисекунд в 20 - ничего не выйдет.
Извините это не вы говорили в самом начале что ООП не догма? :)
То, что я не считаю ООП догмой не означает, что я незнаком с инструментарием.