Закат GPU?
От: Кэр  
Дата: 12.07.09 18:12
Оценка: 1 (1) +1 -3 :)
В связи с тем, что не за горами CPU с 128 и более ядрами — вопрос, а нужны ли тогда будут GPU? Основная фича GPU — их много. Они тупые, умеют считать только шейдеры, но их много и обработка шейдеров хорошо параллелиться. Однако, существует целый паравоз проблем из-за того, что мы имеем отдельный вид процессоров: отдельная память, отдельные инструкции, просто отдельный вид ассемблерных инструкций.
Так что закономерный вопрос: когда CPU тоже станет очень много — не проще ли будет гонять графику прямо на CPU. Какие причины будут содержать GPU в комплекте? Не пора ли NVidia сворачивать бизнес?
Re: Закат GPU?
От: gear nuke  
Дата: 12.07.09 18:38
Оценка: :))) :)))
Здравствуйте, Кэр, Вы писали:

Кэр>В связи с тем, что не за горами CPU с 128 и более ядрами — вопрос, а нужны ли тогда будут GPU?


Они давно уже не нужны, со времен 3DFx ничего нового не увидел.

Кэр>Какие причины будут содержать GPU в комплекте? Не пора ли NVidia сворачивать бизнес?


Двигатели внутреннего сгорания тоже пора сворачивать, но бизнес есть бизнес.
.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Re: Закат GPU?
От: minorlogic Украина  
Дата: 12.07.09 18:45
Оценка:
Здравствуйте, Кэр, Вы писали:

Кэр>В связи с тем, что не за горами CPU с 128 и более ядрами — вопрос, а нужны ли тогда будут GPU? Основная фича GPU — их много. Они тупые, умеют считать только шейдеры, но их много и обработка шейдеров хорошо параллелиться. Однако, существует целый паравоз проблем из-за того, что мы имеем отдельный вид процессоров: отдельная память, отдельные инструкции, просто отдельный вид ассемблерных инструкций.

Кэр>Так что закономерный вопрос: когда CPU тоже станет очень много — не проще ли будет гонять графику прямо на CPU. Какие причины будут содержать GPU в комплекте? Не пора ли NVidia сворачивать бизнес?

На мой взгляд , тут идет сближение с обоих сторон. GPU учаться новым командам, ветвления и т.п. а CPU наращивают мускулы. Близится их соединение.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re: Закат GPU?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 12.07.09 20:40
Оценка: +2
Здравствуйте, Кэр, Вы писали:

Кэр>В связи с тем, что не за горами CPU с 128 и более ядрами — вопрос, а нужны ли тогда будут GPU? Основная фича GPU — их много. Они тупые, умеют считать только шейдеры, но их много и обработка шейдеров хорошо параллелиться. Однако, существует целый паравоз проблем из-за того, что мы имеем отдельный вид процессоров: отдельная память, отдельные инструкции, просто отдельный вид ассемблерных инструкций.

Кэр>Так что закономерный вопрос: когда CPU тоже станет очень много — не проще ли будет гонять графику прямо на CPU. Какие причины будут содержать GPU в комплекте? Не пора ли NVidia сворачивать бизнес?

Ну, во-первых, чтобы процессоры стали тягаться силами с GPU, им надо стать похожими на Cell, а не на x86 или аналог.

Пока что можете посмотреть статистику HPC кластеров — Cell'овые кластера упорно занимают верхние строчки в рейтинге по операциям на ватт. Это значит, что в задачах, которые можно оформить в виде расчётов на SPE, они в разы эффективнее "общего" решения. Тема кластеров на GPU тоже активно развивается.

Но это чуть в сторону, а если вернуться к графике — возможность подсчитать на своей памяти и поближе к собственно генератору видеосигнала тоже очень важна. Эмуляция этого на CPU приведёт к тому, что CPU должен будет заниматься весьма специфической realtime работой на каждый выходной кадр. И зачем оно ему нужно?

Думаю, что решение будет промежуточным — GPU станут ближе к обычным CPU, а CPU массово обзаведутся устройствами вроде Cell'овых SPE. Окончательной же конвергенции не будет — она бессмысленна, это как заставлять мобильный телефон водителя работать инжектором машины.:)
The God is real, unless declared integer.
Re[2]: Закат GPU?
От: Cyberax Марс  
Дата: 12.07.09 20:40
Оценка: 12 (2) +7
Здравствуйте, gear nuke, Вы писали:

Кэр>>В связи с тем, что не за горами CPU с 128 и более ядрами — вопрос, а нужны ли тогда будут GPU?

GN>Они давно уже не нужны, со времен 3DFx ничего нового не увидел.
Чего????? Со времён 3DFx появилось следующее:
1) Hardware T&L (по сути, аппаратное умножение матриц)
2) Первые vertex shaders (теперь уже кроме умножения ещё и несколько простых команд)
3) Первые pixel shaders (то же самое, но в намного более жестокой форме)
4) Гибкие vertex и pixel shaders (теперь с циклами и вызовами подпрограмм!)
5) Geometry shaders и ещё более продвинутые vertex и pixel shaders (возможность почти явной работы с памятью)

CPU не заменят GPU, так как в GPU уж очень спецефичные условия — не нужно предсказание ветвлений, очень сильный параллелизм и т.д. Как вариант, возможно GPU сольётся с CPU, став его блоком (как произошло с FPU).
Sapienti sat!
Re[2]: Закат GPU?
От: thesz Россия http://thesz.livejournal.com
Дата: 12.07.09 21:11
Оценка: +1
Здравствуйте, gear nuke, Вы писали:

GN>Здравствуйте, Кэр, Вы писали:


Кэр>>В связи с тем, что не за горами CPU с 128 и более ядрами — вопрос, а нужны ли тогда будут GPU?


GN>Они давно уже не нужны, со времен 3DFx ничего нового не увидел.


Это ты со зла.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[2]: Закат GPU?
От: thesz Россия http://thesz.livejournal.com
Дата: 12.07.09 21:17
Оценка:
Здравствуйте, minorlogic, Вы писали:

M>Здравствуйте, Кэр, Вы писали:


Кэр>>В связи с тем, что не за горами CPU с 128 и более ядрами — вопрос, а нужны ли тогда будут GPU? Основная фича GPU — их много. Они тупые, умеют считать только шейдеры, но их много и обработка шейдеров хорошо параллелиться. Однако, существует целый паравоз проблем из-за того, что мы имеем отдельный вид процессоров: отдельная память, отдельные инструкции, просто отдельный вид ассемблерных инструкций.

Кэр>>Так что закономерный вопрос: когда CPU тоже станет очень много — не проще ли будет гонять графику прямо на CPU. Какие причины будут содержать GPU в комплекте? Не пора ли NVidia сворачивать бизнес?

M>На мой взгляд , тут идет сближение с обоих сторон. GPU учаться новым командам, ветвления и т.п. а CPU наращивают мускулы. Близится их соединение.


Не пойдёть.

Для GPU очень важна когерентность доступа к коду и данным. Поэтому их можно сделать много.

CPU делаются так, чтобы это было менее важно, чтобы можно было продолжать вычисления, пока часть системы стоит. Поэтому они быстрые.

Если ты попробуешь уменьшить важность когерентности, то ты получишь увеличение аппаратуры: уменьшится число одновременно управляемых ядер, увеличится вся кэш-память, увеличится логика управления кэш-памятью и тп.

Если ты попробуешь уменьшить площадь одного ядра обычного CPU, чтобы сделать их много, то у тебя получится медленный CPU — типа SUN Niagara. Отдельно взятую задачу он будет выполнять медленно.

Рекомендую попробовать самостоятельно сделать и GPU, и CPU. Хотя бы модель. Будешь очень сильно удивлён.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[2]: Закат GPU?
От: thesz Россия http://thesz.livejournal.com
Дата: 12.07.09 21:20
Оценка:
Здравствуйте, netch80, Вы писали:

N>Здравствуйте, Кэр, Вы писали:


N>Но это чуть в сторону, а если вернуться к графике — возможность подсчитать на своей памяти и поближе к собственно генератору видеосигнала тоже очень важна.


Последнее не важно совершенно.

N>Эмуляция этого на CPU приведёт к тому, что CPU должен будет заниматься весьма специфической realtime работой на каждый выходной кадр. И зачем оно ему нужно?


Это делается отдельно стоящей тупой аппаратурой.

N>Думаю, что решение будет промежуточным — GPU станут ближе к обычным CPU, а CPU массово обзаведутся устройствами вроде Cell'овых SPE.


Которые невозможно программировать, кстати. Вычисления на SPE очень трудно сбалансировать, и ещё трудней сделать это автоматически.

N>Окончательной же конвергенции не будет — она бессмысленна, это как заставлять мобильный телефон водителя работать инжектором машины.


Соглашусь.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re: Закат GPU?
От: aminin  
Дата: 13.07.09 04:24
Оценка:
Здравствуйте, Кэр, Вы писали:
Кэр>Так что закономерный вопрос: когда CPU тоже станет очень много — не проще ли будет гонять графику прямо на CPU. Какие причины будут содержать GPU в комплекте? Не пора ли NVidia сворачивать бизнес?

Может быть все придет к подобию Транспьютеров — помню в начале 90х их делали — только ядер будет больше и их можно будет перераспределять как на графику так и на расчетные задачи. Вот с ПО задолбаемся, это факт
а как же Larrabee?
От: minorlogic Украина  
Дата: 13.07.09 05:10
Оценка: 3 (1) +1
http://en.wikipedia.org/wiki/Larrabee_(GPU)

а как же Larrabee?
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re: Закат GPU?
От: Andrei F.  
Дата: 13.07.09 05:59
Оценка: +1
Здравствуйте, Кэр, Вы писали:

Кэр>В связи с тем, что не за горами CPU с 128 и более ядрами — вопрос, а нужны ли тогда будут GPU?


А я подозреваю, что намного ближе закат x86 CPU Архитектура плохо приспособлена для паралеллизма, чем больше ядер — тем меньше выигрыш и больше накладные расходы на синхронизацию. 4-ядерники в массовой продаже уже несколько лет, а программ которые могут использовать столько ядер — можно на пальцах пересчитать. И выигрыш они дают далеко не 4-кратный.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[3]: Закат GPU?
От: gear nuke  
Дата: 13.07.09 07:15
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Чего????? Со времён 3DFx появилось следующее:


[]

Да знаю я это... А что толку? Появился Turok — был качественный прорыв в графике, а дальше только количественные (т.к. разрешения мониторов расли...). До Турка был еще прорыв — Alone in the Dark, в какой-то части построили модели из сфер. Так что Турок в какой-то мере шаг назад.

C>CPU не заменят GPU, так как в GPU уж очень спецефичные условия — не нужно предсказание ветвлений, очень сильный параллелизм и т.д. Как вариант, возможно GPU сольётся с CPU, став его блоком (как произошло с FPU).


Именно 2й вариант и будет, то есть GPU умрет под натиском каких-нибудь SSE6. FPU сохранился т.к была необходима обратная совместимость с существующим ассемблерным кодом.

Кто сейчас играет на рынке? AMD(ATI) + Intel vs. nVidia. Не равные силы. Современные видеоускорители напоминают DOS — людям нужна была совместимость с атавизмами вроде CP/M, поэтому это когда-то пользовалось бешенным спросом.
.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Re[2]: Закат GPU?
От: ilnar Россия  
Дата: 13.07.09 07:16
Оценка: +1
Здравствуйте, Andrei F., Вы писали:

AF>Здравствуйте, Кэр, Вы писали:


Кэр>>В связи с тем, что не за горами CPU с 128 и более ядрами — вопрос, а нужны ли тогда будут GPU?


AF>А я подозреваю, что намного ближе закат x86 CPU Архитектура плохо приспособлена для паралеллизма, чем больше ядер — тем меньше выигрыш и больше накладные расходы на синхронизацию. 4-ядерники в массовой продаже уже несколько лет, а программ которые могут использовать столько ядер — можно на пальцах пересчитать. И выигрыш они дают далеко не 4-кратный.


ну, если бы дело было только в процессоре, намного больше программ бы достигали 4-х кратного ускорения.
нельзя забывать про другие узкие места как шина, работа с памятью, дисками, с ой же видеокартой.
хотя архитектуру постепенно меняют — тот же Nehalem, и дальше — свой контроллер памяти, свой отдельный банк памяти, с QPI между процами
Re: Закат GPU?
От: messir VolanD Беларусь http://www.google.com/profiles/p.drobushevich
Дата: 13.07.09 07:50
Оценка:
Здравствуйте, Кэр, Вы писали:

Кэр>В связи с тем, что не за горами CPU с 128 и более ядрами — вопрос, а нужны ли тогда будут GPU? Основная фича GPU — их много. Они тупые, умеют считать только шейдеры, но их много и обработка шейдеров хорошо параллелиться. Однако, существует целый паравоз проблем из-за того, что мы имеем отдельный вид процессоров: отдельная память, отдельные инструкции, просто отдельный вид ассемблерных инструкций.

Кэр>Так что закономерный вопрос: когда CPU тоже станет очень много — не проще ли будет гонять графику прямо на CPU. Какие причины будут содержать GPU в комплекте? Не пора ли NVidia сворачивать бизнес?

Если так рассуждать, то скорее Intel пора сворачиваться. Я немного ещё не в теме, но есть такая штука CUDE(wiki), видел на конференции как на базе её неплохи вычислительные кластеры строили для реальных задач. Если годичной давности статейки на ixbt:
NVIDIA CUDA — неграфические вычисления на графических процессорах
NVIDIA CUDA — неграфические вычисления на графических процессорах: Часть 2 — Примеры внедрения NVIDIA CUDA
думаю есть что по новее, просто сейчас пока некогда более детально изучить тему, но воообще направление интересное
cuda
Re[3]: Закат GPU?
От: gear nuke  
Дата: 13.07.09 08:11
Оценка: :))) :))
Здравствуйте, thesz, Вы писали:

T>Это ты со зла.


Да! Где же Duke Nukem Forever???
.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Re: Закат GPU?
От: любой  
Дата: 13.07.09 08:18
Оценка: +3 -2
Здравствуйте, Кэр, Вы писали:

...

Графические процессоры ближе к той архитектуре, которой следовало бы быть у компьютеров. А следовало бы не иметь разделения на процессор и память вообще. Т. е. выполнять операции с числами должна сама память. Разумеется, с возможностью параллелизма на всю свою ёмкость. Также, она должна программироваться на создание определённой структуры передачи и обработки потоков информации.
художников никогда не обижал
Re[4]: Закат GPU?
От: Cyberax Марс  
Дата: 13.07.09 10:24
Оценка:
Здравствуйте, gear nuke, Вы писали:

GN>Да знаю я это... А что толку? Появился Turok — был качественный прорыв в графике, а дальше только количественные (т.к. разрешения мониторов расли...). До Турка был еще прорыв — Alone in the Dark, в какой-то части построили модели из сфер. Так что Турок в какой-то мере шаг назад.

Не-не. Ты нифига, значит, не знаешь что происходило в графике. Я перечислил именно качественные прорывы.

GN>Именно 2й вариант и будет, то есть GPU умрет под натиском каких-нибудь SSE6. FPU сохранился т.к была необходима обратная совместимость с существующим ассемблерным кодом.

Не умрёт. Сама по себе архитектура GPU другая. NVidia хвасталась, что их современный GPU по мощности равен примерно сотне CPU. Что где-то так и есть, в принципе, если посмотреть на результаты Folding@home.

GN>Кто сейчас играет на рынке? AMD(ATI) + Intel vs. nVidia. Не равные силы. Современные видеоускорители напоминают DOS — людям нужна была совместимость с атавизмами вроде CP/M, поэтому это когда-то пользовалось бешенным спросом.

Так с кем ускорители совместимость-то хранят? Direct3D менялся чуть менее чем полностью на каждое поколение графических систем. Современные видеокарты с программируемым pipeline'ом имеют мало общего с 3DFx.
Sapienti sat!
Re: а как же Larrabee?
От: thesz Россия http://thesz.livejournal.com
Дата: 13.07.09 10:51
Оценка:
Здравствуйте, minorlogic, Вы писали:

M>http://en.wikipedia.org/wiki/Larrabee_(GPU)


M>а как же Larrabee?


Что я там говорил? По-моему, так:

Если ты попробуешь уменьшить площадь одного ядра обычного CPU, чтобы сделать их много, то у тебя получится медленный CPU — типа SUN Niagara. Отдельно взятую задачу он будет выполнять медленно.


Читаем про Лараби:

In-order execution means lower performance for individual cores, but since they are smaller, more can fit on a single chip, increasing overall throughput.


Обычный размен.

На компиляции с помощью одного ядра современный Core 2 будет рвать Лараби, как Тузик грелку.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[2]: Закат GPU?
От: Andrei F.  
Дата: 13.07.09 11:10
Оценка:
Здравствуйте, любой, Вы писали:

Л>А следовало бы не иметь разделения на процессор и память вообще. Т. е. выполнять операции с числами должна сама память. Разумеется, с возможностью параллелизма на всю свою ёмкость. Также, она должна программироваться на создание определённой структуры передачи и обработки потоков информации.


То, что ты описываешь — это перепрограммируемый систолический массив. Используется кое-где для высокопроизводительных вычислений, и вообще идея очень правильная. Но чтобы пустить это в масовое использование, придется переучивать всех программистов, преодолевая ожесточенное сопротивление
Это ведь не мелкий шажок вроде ФП, управляемого кода или синтаксических макросов, вокруг которых столько копий сломали (и до сих пор ломают). Это совершенно другая архитектура, не фон-Неймановская. И совершенно другой подход к программированию. Кайрофобы затопчут нафиг
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[2]: а как же Larrabee?
От: minorlogic Украина  
Дата: 13.07.09 11:19
Оценка:
Здравствуйте, thesz, Вы писали:

T>На компиляции с помощью одного ядра современный Core 2 будет рвать Лараби, как Тузик грелку.


Это очевидно, но в том то и дело что ядер будет много.
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[4]: Закат GPU?
От: CreatorCray  
Дата: 13.07.09 11:35
Оценка:
Здравствуйте, gear nuke, Вы писали:

GN>Да знаю я это... А что толку? Появился Turok — был качественный прорыв в графике, а дальше только количественные (т.к. разрешения мониторов расли...). До Турка был еще прорыв — Alone in the Dark, в какой-то части построили модели из сфер. Так что Турок в какой-то мере шаг назад.


Ты что, со времен Турка вообще ни во что не играл?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re: а как же Larrabee?
От: CreatorCray  
Дата: 13.07.09 11:35
Оценка: +1
Здравствуйте, minorlogic, Вы писали:

M>http://en.wikipedia.org/wiki/Larrabee_(GPU)

M>а как же Larrabee?
Он же вроде как еще не вышел.
Выйдет — посмотрим.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[2]: Закат GPU?
От: CreatorCray  
Дата: 13.07.09 11:35
Оценка:
Здравствуйте, Andrei F., Вы писали:

AF>4-ядерники в массовой продаже уже несколько лет, а программ которые могут использовать столько ядер — можно на пальцах пересчитать. И выигрыш они дают далеко не 4-кратный.

Может зададимся вопросом: а так ли много есть алгоритмов, которые эффективно параллелятся?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[3]: Закат GPU?
От: WolfHound  
Дата: 13.07.09 11:59
Оценка: +2
Здравствуйте, CreatorCray, Вы писали:

CC>Может зададимся вопросом: а так ли много есть алгоритмов, которые эффективно параллелятся?

Лучше так: Много ли есть задач для которых нет эффективных параллельных алгоритмов?
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[4]: Закат GPU?
От: CreatorCray  
Дата: 13.07.09 12:00
Оценка:
Здравствуйте, WolfHound, Вы писали:

CC>>Может зададимся вопросом: а так ли много есть алгоритмов, которые эффективно параллелятся?

WH>Лучше так: Много ли есть задач для которых нет эффективных параллельных алгоритмов?
"Ты не поверишь!" (С)
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[5]: Закат GPU?
От: WolfHound  
Дата: 13.07.09 12:04
Оценка: +2 :))
Здравствуйте, CreatorCray, Вы писали:

WH>>Лучше так: Много ли есть задач для которых нет эффективных параллельных алгоритмов?

CC>"Ты не поверишь!" (С)
Огласите весь список пожалуйста.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[3]: а как же Larrabee?
От: thesz Россия http://thesz.livejournal.com
Дата: 13.07.09 12:13
Оценка: +1
Здравствуйте, minorlogic, Вы писали:

M>Здравствуйте, thesz, Вы писали:


T>>На компиляции с помощью одного ядра современный Core 2 будет рвать Лараби, как Тузик грелку.


M>Это очевидно, но в том то и дело что ядер будет много.


Если у нас 90% (обработка) может быть выполнено произвольно параллельно, а 10% (анализ) не может быть выполнено параллельно, то производительность упрётся в эти 10%. Тогда-то и вылезет ILP и out-of-order.

Это, кстати, типичная проблема, решаемая гетерогенными системами. Как, например, Core2 + GPU.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re: Закат GPU?
От: Bla-la-mut  
Дата: 13.07.09 12:18
Оценка: 1 (1)
Здравствуйте, Кэр, Вы писали:

Кэр>В связи с тем, что не за горами CPU с 128 и более ядрами — вопрос, а нужны ли тогда будут GPU? Основная фича GPU — их много. Они тупые, умеют считать только шейдеры, но их много и обработка шейдеров хорошо параллелиться. Однако, существует целый паравоз проблем из-за того, что мы имеем отдельный вид процессоров: отдельная память, отдельные инструкции, просто отдельный вид ассемблерных инструкций.

Кэр>Так что закономерный вопрос: когда CPU тоже станет очень много — не проще ли будет гонять графику прямо на CPU. Какие причины будут содержать GPU в комплекте? Не пора ли NVidia сворачивать бизнес?
Я имею некоторый опыт в области gpgpu, видахи быстры только когда можно использовать принцип shared nothing, паралельное выполнение нескольких шейдеров(даже ветвлений одного для разных групп потоков) возможно только на разных SIMD блоках чаще всего. Моё мнение 128 ядерный проц не заменит 1000 ядерную видах)))))) Его просто удобнее программировать, некоторые задачи на видахи не ложаться, даже казалось бы паралельные ( при обработке нейросети нужно пересчитывать веса для связей — там очень большое количество обращений к оператве — плохое соотношение инструкций разных типов, выполняется медленно, кеш не спасает — спасло бы выполнение двух шейдеров на одном симд блоке, но это требует усложнения железа).
Выйдет лараби — там будет возможность стартовать новые потоки прямо на видахе, и вот как раз для него может появится killer app.
Re[3]: Закат GPU?
От: Bla-la-mut  
Дата: 13.07.09 12:22
Оценка:
Здравствуйте, Andrei F., Вы писали:

AF>Здравствуйте, любой, Вы писали:


Л>>А следовало бы не иметь разделения на процессор и память вообще. Т. е. выполнять операции с числами должна сама память. Разумеется, с возможностью параллелизма на всю свою ёмкость. Также, она должна программироваться на создание определённой структуры передачи и обработки потоков информации.


AF>То, что ты описываешь — это перепрограммируемый систолический массив. Используется кое-где для высокопроизводительных вычислений, и вообще идея очень правильная. Но чтобы пустить это в масовое использование, придется переучивать всех программистов, преодолевая ожесточенное сопротивление

AF>Это ведь не мелкий шажок вроде ФП, управляемого кода или синтаксических макросов, вокруг которых столько копий сломали (и до сих пор ломают). Это совершенно другая архитектура, не фон-Неймановская. И совершенно другой подход к программированию. Кайрофобы затопчут нафиг
Боюсь это throughput computing — на него ложатся далеко не все алгоритмы, в любом случае получается очень похоже на нейрочипы — они очень сложные в схемотехнике. Видахи на это похожи слабо, разделение на проц и память там чёткое, кто не верит — читайте доки по gpgpu.
Re: а как же Larrabee?
От: Кэр  
Дата: 13.07.09 12:34
Оценка: +1
Здравствуйте, minorlogic, Вы писали:

M>http://en.wikipedia.org/wiki/Larrabee_(GPU)


M>а как же Larrabee?


Именно про это я и говорю:

Differences with current GPUs
Larrabee will differ from other discrete GPUs currently on the market such as the GeForce 200 Series and the Radeon 4000 series in three major ways:


Подход "простой софт, сложная hardware" всегда заруливал подход "сложный софт, простая hardware". "Простой софт" очень хорошо масштабируется. Возможность исполнять x86 инструкции прямо на GPU и когерентность кэша, например, означает что возможно применять кастомную обработку к данным посланным на графическую обработку без потери в скорости — данные уже на шине — т.е. софт который посылает графические данные на обработку может быть изрядно тупее, чем он есть сейчас. Что можно будет делать в таком случае — писать ray tracing к примеру на C# LINQ и относительно просто компилировать это все в команды Larrabee.
Это также означает, что новые фишки типа каких-нибудь новых шейдеров — возможно будут выпускаться просто как алгоритмические решения на обычном наборе ассемблерных инструкций. Не будет необходимости менять железо только чтобы получить эти шейдеры. Это очень круто.
Re[3]: Закат GPU?
От: любой  
Дата: 13.07.09 12:36
Оценка:
Здравствуйте, Andrei F., Вы писали:

AF>То, что ты описываешь — это перепрограммируемый систолический массив. Используется кое-где для высокопроизводительных вычислений, и вообще идея очень правильная. Но чтобы пустить это в масовое использование, придется переучивать всех программистов, преодолевая ожесточенное сопротивление

Всё, к чему привыкли кодеры, можно съэмулировать. Другое дело, что "правильность идей" бизнесменов не вдохновляет. Им важна лишь сиеминутная прибыль. Удивительно, но не потребности науки, медицины, военных, а развлечения подростков стали стимулом для создания мощных GPU и физических процессоров.

AF>Это ведь не мелкий шажок вроде ФП, управляемого кода или синтаксических макросов, вокруг которых столько копий сломали (и до сих пор ломают). Это совершенно другая архитектура, не фон-Неймановская. И совершенно другой подход к программированию. Кайрофобы затопчут нафиг

Те, кто трассировщики лучей пишут и всякие ядрёные взрывы моделируют, будут только за. А прочих никто не заставляет вникать.
художников никогда не обижал
Re[4]: Закат GPU?
От: Andrei F.  
Дата: 13.07.09 13:00
Оценка:
Здравствуйте, Bla-la-mut, Вы писали:

BLM>Боюсь это throughput computing — на него ложатся далеко не все алгоритмы


В первый раз встречаю такой термин. Откуда это?
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[4]: Закат GPU?
От: GarryIV  
Дата: 13.07.09 14:13
Оценка:
Здравствуйте, любой, Вы писали:

AF>>То, что ты описываешь — это перепрограммируемый систолический массив. Используется кое-где для высокопроизводительных вычислений, и вообще идея очень правильная. Но чтобы пустить это в масовое использование, придется переучивать всех программистов, преодолевая ожесточенное сопротивление

Л>Всё, к чему привыкли кодеры, можно съэмулировать. Другое дело, что "правильность идей" бизнесменов не вдохновляет. Им важна лишь сиеминутная прибыль. Удивительно, но не потребности науки, медицины, военных, а развлечения подростков стали стимулом для создания мощных GPU и физических процессоров.

Платежеспособный спрос. Кто-то же должен был оплатить все это.
WBR, Igor Evgrafov
Re[3]: Закат GPU?
От: minorlogic Украина  
Дата: 14.07.09 05:35
Оценка:
Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, Andrei F., Вы писали:


AF>>4-ядерники в массовой продаже уже несколько лет, а программ которые могут использовать столько ядер — можно на пальцах пересчитать. И выигрыш они дают далеко не 4-кратный.

CC>Может зададимся вопросом: а так ли много есть алгоритмов, которые эффективно параллелятся?

Думаю что большая часть.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[4]: Закат GPU?
От: Sinclair Россия https://github.com/evilguest/
Дата: 14.07.09 09:12
Оценка:
Здравствуйте, minorlogic, Вы писали:
M>Думаю что большая часть.
Хм. Насколько я помню, первый алгоритм, который я изучил, был алгоритм Евклида — который нахождения наибольшего общего делителя.
Можно мне продемонстрировать высокопараллельный его вариант? Для, скажем, сверхбольших чисел — чтобы параллелизм стал оправдан.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[5]: Закат GPU?
От: Cyberax Марс  
Дата: 14.07.09 09:21
Оценка:
Здравствуйте, Sinclair, Вы писали:

M>>Думаю что большая часть.

S>Хм. Насколько я помню, первый алгоритм, который я изучил, был алгоритм Евклида — который нахождения наибольшего общего делителя.
S>Можно мне продемонстрировать высокопараллельный его вариант? Для, скажем, сверхбольших чисел — чтобы параллелизм стал оправдан.
http://arxiv.org/abs/0907.0718
http://portal.acm.org/citation.cfm?id=1393801
http://portal.acm.org/citation.cfm?id=384101.384142
Sapienti sat!
Re[6]: Закат GPU?
От: Sinclair Россия https://github.com/evilguest/
Дата: 14.07.09 09:46
Оценка:
Здравствуйте, Cyberax, Вы писали:
C>http://arxiv.org/abs/0907.0718
C>http://portal.acm.org/citation.cfm?id=1393801
C>http://portal.acm.org/citation.cfm?id=384101.384142
Отвал башки. Особенно первый — который опубликовали неделю тому.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[7]: Закат GPU?
От: Cyberax Марс  
Дата: 14.07.09 09:49
Оценка: +1 :)
Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Cyberax, Вы писали:

C>>http://arxiv.org/abs/0907.0718
C>>http://portal.acm.org/citation.cfm?id=1393801
C>>http://portal.acm.org/citation.cfm?id=384101.384142
S>Отвал башки. Особенно первый — который опубликовали неделю тому.
Меня после умножения Карацубы уже ничем не удивить
Sapienti sat!
Re: Закат GPU?
От: Sergey Chadov Россия  
Дата: 14.07.09 15:42
Оценка: +1
Здравствуйте, Кэр, Вы писали:

Кэр>В связи с тем, что не за горами CPU с 128 и более ядрами — вопрос, а нужны ли тогда будут GPU? Основная фича GPU — их много. Они тупые, умеют считать только шейдеры, но их много и обработка шейдеров хорошо параллелиться. Однако, существует целый паравоз проблем из-за того, что мы имеем отдельный вид процессоров: отдельная память, отдельные инструкции, просто отдельный вид ассемблерных инструкций.

Кэр>Так что закономерный вопрос: когда CPU тоже станет очень много — не проще ли будет гонять графику прямо на CPU. Какие причины будут содержать GPU в комплекте? Не пора ли NVidia сворачивать бизнес?

Без шансов, у GPU есть объективные преимущества, которые позволяют на определенном классе алгоритмов давать существенный прирост производительности. И если сделают 128-ядерный CPU, то можно сделать и какой-нибудь 16384-ядерный GPU.
--
Sergey Chadov

... << RSDN@Home 1.2.0 alpha rev. 685>>
Re[5]: Закат GPU?
От: minorlogic Украина  
Дата: 14.07.09 16:24
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, minorlogic, Вы писали:

M>>Думаю что большая часть.
S>Хм. Насколько я помню, первый алгоритм, который я изучил, был алгоритм Евклида — который нахождения наибольшего общего делителя.
S>Можно мне продемонстрировать высокопараллельный его вариант? Для, скажем, сверхбольших чисел — чтобы параллелизм стал оправдан.

Я не продемонстрирую с силу банального незнания. Но какой из этого можно сделать вывод? Да никакой ..
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[2]: Закат GPU?
От: Кэр  
Дата: 14.07.09 16:50
Оценка:
Здравствуйте, Sergey Chadov, Вы писали:

SC>Без шансов, у GPU есть объективные преимущества, которые позволяют на определенном классе алгоритмов давать существенный прирост производительности. И если сделают 128-ядерный CPU, то можно сделать и какой-нибудь 16384-ядерный GPU.


Как я написал здесь:
http://www.rsdn.ru/forum/philosophy/3466219.1.aspx
Автор: Кэр
Дата: 13.07.09


идея заключается в том, чтобы резко упростить задачу обработки графики. Сейчас логику обработки графики приходится выражать на очень узкоспециализированных процессорах. С очень ужатыми возможностями. Larrabee выглядит очень интересным проектом прежде всего потому, что приносит возможности полноформатных процессоров, которые стали достаточно дешевы чтобы тягаться в своем количестве с количеством GPU.
Теперь осталось посмотреть, заборет ли Larrabee решения от NVidia — противостояние должно начаться уже скоро (в случае с Radeon'ами — есть подозрение, что AMD копает в том же направлении).
Re[3]: Закат GPU?
От: Sergey Chadov Россия  
Дата: 14.07.09 17:13
Оценка: +2
Здравствуйте, Кэр, Вы писали:

Кэр>идея заключается в том, чтобы резко упростить задачу обработки графики. Сейчас логику обработки графики приходится выражать на очень узкоспециализированных процессорах. С очень ужатыми возможностями. Larrabee выглядит очень интересным проектом прежде всего потому, что приносит возможности полноформатных процессоров, которые стали достаточно дешевы чтобы тягаться в своем количестве с количеством GPU.

Кэр>Теперь осталось посмотреть, заборет ли Larrabee решения от NVidia — противостояние должно начаться уже скоро (в случае с Radeon'ами — есть подозрение, что AMD копает в том же направлении).

GPU — это уже далеко не только графика. К тому же, чем проще процессор — тем больше их можно сделать, в этом смысле без разницы, будет ли это GPU или какой-нибудь векторный сопроцессор. Чудес не бывает, если Larrabee приносит возможности полноформатных процессоров, то он что-то и уносит.
--
Sergey Chadov

... << RSDN@Home 1.2.0 alpha rev. 685>>
Re[4]: Закат GPU?
От: Кэр  
Дата: 14.07.09 17:42
Оценка:
Здравствуйте, Sergey Chadov, Вы писали:

SC>...чем проще процессор — тем больше их можно сделать...


Смотря кому. Intel в плане разработки процессоров впереди планеты всей. Да возможно NVidia чтобы сделать когерентный кэш придется потратить очень хорошие деньги и ресурсы. И тратить потом хорошие деньги на каждую копию. Intel возможно сможет это делать гораздо дешевле.
Сам же факт того, что команды процессора становятся полноценными — приносит невероятный простор в действиях. Если найдутся светлые головы, которые этот простор в действиях применят на практике могут получится очень крутые результаты. В таком случае слоган "эта крутая штука работает только на Larrabee" — может прикрыть бизнес NVidia очень быстро.
Причем надо заметить — для этого не придется оттягивать релиз игры на то время, когда новые видеокарточки наберут массу. И не нужно будет думать (или придется думать в меньшей степени) на тему — а как быть с предыдущим поколением процессоров, где нет набора этих команд.
Видео-карточка — это прежде всего платформа. Если под эту платформу легко разрабатывать — то это практически гарантия, что платформа будет успешна.
Re[5]: Закат GPU?
От: Sergey Chadov Россия  
Дата: 14.07.09 17:51
Оценка:
Здравствуйте, Кэр, Вы писали:

SC>>...чем проще процессор — тем больше их можно сделать...


Кэр>Сам же факт того, что команды процессора становятся полноценными — приносит невероятный простор в действиях. Если найдутся светлые головы, которые этот простор в действиях применят на практике могут получится очень крутые результаты.

Ключевой момент в том, что это дается не просто так. и на задачах, которые сейчас решаются на GPU все равно можно сделать быстрее путем упрощения процессоров и увеличения их количества.

Кэр> В таком случае слоган "эта крутая штука работает только на Larrabee" — может прикрыть бизнес NVidia очень быстро.

Даже если и так, почему ты думаешь, что Intel, уперевшись через несколько лет в предел производительности не пойдет другим путем?
--
Sergey Chadov

... << RSDN@Home 1.2.0 alpha rev. 685>>
Re[6]: Закат GPU?
От: Кэр  
Дата: 14.07.09 19:27
Оценка: 12 (1)
Здравствуйте, Sergey Chadov, Вы писали:

Кэр>>Сам же факт того, что команды процессора становятся полноценными — приносит невероятный простор в действиях. Если найдутся светлые головы, которые этот простор в действиях применят на практике могут получится очень крутые результаты.

SC>Ключевой момент в том, что это дается не просто так. и на задачах, которые сейчас решаются на GPU все равно можно сделать быстрее путем упрощения процессоров и увеличения их количества.

У меня это не тема моей специальности, поэтому я поговорил сейчас с другом, который занимается этим очень серьезно. Насколько я понял — основная проблема текущего подхода — из шейдеров невозможно сделать вторичный запрос к сцене. Т.е. эффект тени, например, приходится рендерить через ОЧЕНЬ большой изврат. Точнее целый набор таких извратов — каждый по случаю.

Larrabee предоставит возможность общаться со сценой напрямую и это мега-круто. Интел упирает на то, что сцену можно будет рендерить с помощью ray-tracing, а не растеризации. И если будет реально можно — то это кул. И это же будет означать Larrabee only.

Вот, кстати, интервью одного из мозгов Unreal Engine:
http://arstechnica.com/gaming/news/2008/09/gpu-sweeney-interview.ars
Re[7]: Закат GPU?
От: Sergey Chadov Россия  
Дата: 15.07.09 07:53
Оценка:
Здравствуйте, Кэр, Вы писали:


Кэр>У меня это не тема моей специальности, поэтому я поговорил сейчас с другом, который занимается этим очень серьезно. Насколько я понял — основная проблема текущего подхода — из шейдеров невозможно сделать вторичный запрос к сцене. Т.е. эффект тени, например, приходится рендерить через ОЧЕНЬ большой изврат. Точнее целый набор таких извратов — каждый по случаю.


Еще раз, GPU — это уже далеко не только графика, давно уже существуют технологии GPGPU, то есть general-purpose GPU. На GPU решаются самые разные задачи, от моделирования фолдинга белков до брутфорса паролей. На некоторых задачах сообщается о приросте производительности в несколько сотен раз.
В большинстве случаев конечно поскромнее, например может быть когда-нибудь выйдет-таки моя статья о реализации решения разреженных СЛАУ, там прирост производитеьности на GeForce GTX 260 по сравнению с Q6600 раз в 7, причем думаю это далеко не предел того, что можно из него выжать.

Кэр>Larrabee предоставит возможность общаться со сценой напрямую и это мега-круто. Интел упирает на то, что сцену можно будет рендерить с помощью ray-tracing, а не растеризации. И если будет реально можно — то это кул. И это же будет означать Larrabee only.


Я сейчас точно сказать не могу, но по-моему реализации raytracing на CUDA есть и показывают вполне неплохие результаты.
Re[7]: Закат GPU?
От: CreatorCray  
Дата: 15.07.09 08:21
Оценка:
Здравствуйте, Кэр, Вы писали:

Кэр>Т.е. эффект тени, например, приходится рендерить через ОЧЕНЬ большой изврат. Точнее целый набор таких извратов — каждый по случаю.

Какие именно тени? Насколько я помню что стенсильные что проективные ничего особо извратного в себе не содержат.

Кэр>И это же будет означать Larrabee only.

Для геймдевелопера это означает сильное сужение круга покупателей. Что есть сильно плохо.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[5]: Закат GPU?
От: gear nuke  
Дата: 15.07.09 11:07
Оценка: -1 :)
Здравствуйте, Cyberax, Вы писали:

C>Не-не. Ты нифига, значит, не знаешь что происходило в графике. Я перечислил именно качественные прорывы.


ДВС тоже можно называть качественным прорывом по сравнению с паровым котлом, однако для автомобиля это дало только количественуй бонус — меньше размер. А качественно новое транспортное средство получилось добавлением крыльев и пропеллера. Вот так же и те прорывы в GPU — на картинке они не особо отразились. Заявления о кинематографическом качестве я уж и не помню скорлько лет вижу

C>Не умрёт. Сама по себе архитектура GPU другая.


Архитектура CPU тоже не стоит на месте. Самое смешное будет через неск лет, мы посмотрим на это и увидим, что оба правы, но называться это будет всё же CPU

C>NVidia хвасталась, что их современный GPU по мощности равен примерно сотне CPU. Что где-то так и есть, в принципе, если посмотреть на результаты Folding@home.


Мощьность — отличная характеристика, можно посчитать насколько лучше современные GPU обогревают помещение И пример Folding@home тоже очень показателен — вычисления ведутся по сути "в пустую". Нам же важен конечный результат

C>Так с кем ускорители совместимость-то хранят?


Ни с кем, потому и отомрёт, в отличие от FPU.
.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Re[6]: Закат GPU?
От: Cyberax Марс  
Дата: 15.07.09 14:12
Оценка: +1
Здравствуйте, gear nuke, Вы писали:

C>>Не умрёт. Сама по себе архитектура GPU другая.

GN>Архитектура CPU тоже не стоит на месте. Самое смешное будет через неск лет, мы посмотрим на это и увидим, что оба правы, но называться это будет всё же CPU
Она идёт в другом направлении.

C>>NVidia хвасталась, что их современный GPU по мощности равен примерно сотне CPU. Что где-то так и есть, в принципе, если посмотреть на результаты Folding@home.

GN>Мощьность — отличная характеристика, можно посчитать насколько лучше современные GPU обогревают помещение И пример Folding@home тоже очень показателен — вычисления ведутся по сути "в пустую". Нам же важен конечный результат
Что значит 'ведутся по сути "в пустую"'? У GPU эффективность настолько высокая, что из них кластеры уже строят. На своих задачах они рвут CPU как тузик грелку.
Sapienti sat!
Re[8]: Закат GPU?
От: Кэр  
Дата: 15.07.09 14:52
Оценка:
Здравствуйте, Sergey Chadov, Вы писали:

SC>Еще раз, GPU — это уже далеко не только графика, давно уже существуют технологии GPGPU, то есть general-purpose GPU. На GPU решаются самые разные задачи, от моделирования фолдинга белков до брутфорса паролей. На некоторых задачах сообщается о приросте производительности в несколько сотен раз.


Давайте вы прочитаете статью, которую я привел. Статья поддерживает мою позицию практически по всем направлениям. Если вы начнете возражать аргументации из этой статьи — мы сразу пропустим несколько шагов в этом разговоре.

Конкретно в этом случае:

That's certainly the case with multicore CPUs. To take a simple 10-line sorting algorithm and translate that to run efficiently on a lot of cores requires exploding that to maybe 50 lines of code. You have significant productivity loss as you get into these more advanced architectures, so a key aspect of programmer productivity is to be able to write simple code that runs in parallel. NVIDIA has done some really cool work with CUDA to show that GPUs can actually run code written in a C-subset language. But can we take CUDA's restricted feature set—it doesn't support recursion or function pointers—and can we make that into a full C++ compatible language? There are a lot of open questions there.


Почему вообще смотрят в стороную поддержки полноценного С++ (т.е. речь по сути идет о софтверном рендере — все возвращается на круги своя):

JS: Ah, I see. So DirectX support in products like Larrabee will really be about backwards compatibility, and not so much a forward-looking feature. So then you think that DX10 is really the last gasp of this on the Windows side, in terms of what's actually being used... of course, I guess nobody's really using it right now.

TS: I think DirectX 9 was the last graphics API that really mattered. DirectX 9 was a revolution: completely programmable shaders of unlimited length with full floating-point precision support. Compared with the fixed-function, 8-bit pipeline it replaced, it was revolutionary. Everything since has been incremental, and kind of backward-looking.

So, DirectX 10 takes DirectX 9 and adds some weird fixed-function components on top of it, which fit in a very particular place in the pipeline, and are hard to use. I'm not saying that it's entirely unwarranted, but I think that DirectX 9 was the last game-changing step in the graphics APIs, and the next non-incremental step will be the move back to programming languages.

To take the long-term view of it, in the early 90s, we had the software rendering era—Quake, Doom, Unreal—all the genre-defining games based on software rendering. The next big step was the fixed-function, 8-bit rendering era; it started with 3Dfx Voodoo, and then NVIDIA, through DirectX 8. And then you got into the DirectX 9 era—where the shading pipeline was programmable, but everything else was fixed-function. The next step is just programmable everything, and back to C++.

There, you have four discrete steps that were the really big steps in consumer graphics. I see no more big steps until we're completely software, and I see that happening over the next few years. There's no doubt that's the design behind Larrabee—to enable programmers to do completely custom rendering from the ground up if they want to do that.


SC>В большинстве случаев конечно поскромнее, например может быть когда-нибудь выйдет-таки моя статья о реализации решения разреженных СЛАУ, там прирост производитеьности на GeForce GTX 260 по сравнению с Q6600 раз в 7, причем думаю это далеко не предел того, что можно из него выжать.


В данном случае надо "сравнивать" конечно с Larrabee и для полной честности — с новым поколением GeForce процессоров, которые тоже должны выйти в 2010 году. Но судя по всему оба этих процессора будут по большей части CPU чем GPU в том плане, что они будут fully programmable. Поживем, увидим.

SC>Я сейчас точно сказать не могу, но по-моему реализации raytracing на CUDA есть и показывают вполне неплохие результаты.


Так CUDA — на самом деле это и есть большой шаг в сторону CPU на самом деле. Сейчас там много ограничений — subset of C — это на самом деле грустно. С++ выглядит здесь гораздо более внушительно.
Re[8]: Закат GPU?
От: Кэр  
Дата: 15.07.09 15:09
Оценка: -2
Здравствуйте, CreatorCray, Вы писали:

Кэр>>Т.е. эффект тени, например, приходится рендерить через ОЧЕНЬ большой изврат. Точнее целый набор таких извратов — каждый по случаю.

CC>Какие именно тени? Насколько я помню что стенсильные что проективные ничего особо извратного в себе не содержат.

Если я не ошибаюсь вы довольно частый участник КСВ с аргументацией "в линуксе все то же самое, что и винде". У меня нет никакого желания вести здесь подобную дискуссию относительно степени извратности наложения теней с помощью шейдеров. В софтверном рендере — будет нормальный доступ к сцене и объектам описывающих эту сцену. В текущем графическом pipeline — такой возможности нет. При расчете теней — это очень сильное ограничение. Удастся ли резко здесь улучшить ситуацию с появлением Larrabee — неизвестно, нужно ставить эксперименты и смотреть. Но теоретически — шанс очень хороший.

Кэр>>И это же будет означать Larrabee only.

CC>Для геймдевелопера это означает сильное сужение круга покупателей. Что есть сильно плохо.

Ой да бросьте. Мы же говорим про индустрию развлечений. Будет новый Crysis требовать Larrabee — сразу круг пользователей расшириться очень сильно.
Re[9]: Закат GPU?
От: Sergey Chadov Россия  
Дата: 15.07.09 16:29
Оценка:
Здравствуйте, Кэр, Вы писали:

Кэр>Здравствуйте, Sergey Chadov, Вы писали:


SC>>Еще раз, GPU — это уже далеко не только графика, давно уже существуют технологии GPGPU, то есть general-purpose GPU. На GPU решаются самые разные задачи, от моделирования фолдинга белков до брутфорса паролей. На некоторых задачах сообщается о приросте производительности в несколько сотен раз.


Кэр>Давайте вы прочитаете статью, которую я привел. Статья поддерживает мою позицию практически по всем направлениям. Если вы начнете возражать аргументации из этой статьи — мы сразу пропустим несколько шагов в этом разговоре.


Это все к делу не относится. Дело обстоит так: существует две архитектуры вычислительных устройств, одна из них подразумевает относительно небольшое количество продвинутых процессоров, другая — большое количество процессоров-дебилов. Это грубо говоря, аналогично можно говорить и о памяти итп. Я не вижу никаких предпосылок, почему одна из этих арихтектур может вытеснить другую, поскольку существуют разные задачи, часть из которых объективно лучше(заметно лучше) решается на одной, часть — на другой. Возможно, эти архитектуры сблизятся: GPU станет ближе к CPU хотя бы для гибкости и простоты программироавния, CPU к GPU хотя бы потому, что при большом количестве ядер многие из используемых сейчас схем просто плохореализуемы.

SC>>Я сейчас точно сказать не могу, но по-моему реализации raytracing на CUDA есть и показывают вполне неплохие результаты.


Кэр>Так CUDA — на самом деле это и есть большой шаг в сторону CPU на самом деле. Сейчас там много ограничений — subset of C — это на самом деле грустно.


"subset of C++" вообще-то. В частости, шаблонные функции вполне работают.

Кэр> С++ выглядит здесь гораздо более внушительно.

Да, но чудес не бывает, за простоту программирования всегда приходится расплачиваться.
--
Sergey Chadov

... << RSDN@Home 1.2.0 alpha rev. 685>>
Re: Закат GPU?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 15.07.09 17:51
Оценка: +1
Здравствуйте, Кэр, Вы писали:

Кэр>В связи с тем, что не за горами CPU с 128 и более ядрами — вопрос, а нужны ли тогда будут GPU? Основная фича GPU — их много. Они тупые, умеют считать только шейдеры, но их много и обработка шейдеров хорошо параллелиться. Однако, существует целый паравоз проблем из-за того, что мы имеем отдельный вид процессоров: отдельная память, отдельные инструкции, просто отдельный вид ассемблерных инструкций.


Да, зато имеем ряд преимуществ — GPU на порядок минимум мощнее многоядерного процессора.

Кэр>Так что закономерный вопрос: когда CPU тоже станет очень много — не проще ли будет гонять графику прямо на CPU. Какие причины будут содержать GPU в комплекте? Не пора ли NVidia сворачивать бизнес?


Нет, не пора. Потребности в хорошей графике никогда не бывают достаточными, дашь бОльше CPU(ядер) значит надо дать больше памяти , шире и быстрее шина, и кеш посильне и тд и тд, и после всего этого всех этих ресурсов будет еле-еле хватать на игрушку последнего поколения.

Перформанс не растет линейно из за добавления CPU. Одноядрные CPU уже выдохлись, со временем выдохнутяс и многоядерные в том виде, как они сейчас.

Где взять перформансу — GPU(ну или специлизированые xPU) ! Кстати говоря, некоторые пробуют юзать GPU для ускорения вычислений не связаных с графикой.
Re[9]: Закат GPU?
От: CreatorCray  
Дата: 16.07.09 07:16
Оценка:
Здравствуйте, Кэр, Вы писали:

Кэр>>>Т.е. эффект тени, например, приходится рендерить через ОЧЕНЬ большой изврат. Точнее целый набор таких извратов — каждый по случаю.

CC>>Какие именно тени? Насколько я помню что стенсильные что проективные ничего особо извратного в себе не содержат.

Кэр>Если я не ошибаюсь вы довольно частый участник КСВ с аргументацией "в линуксе все то же самое, что и винде".

Тебе не передать как ты ошибаешься. Вообще считаю сие оскорблением.

Кэр> У меня нет никакого желания вести здесь подобную дискуссию относительно степени извратности наложения теней с помощью шейдеров.

Ты просто алгоритм назови.

Кэр>>>И это же будет означать Larrabee only.

CC>>Для геймдевелопера это означает сильное сужение круга покупателей. Что есть сильно плохо.
Кэр>Ой да бросьте. Мы же говорим про индустрию развлечений. Будет новый Crysis требовать Larrabee — сразу круг пользователей расшириться очень сильно.
Я в этой самой индустрии 4 года до недавнего времени работал.
Так что про зависимость круга пользователей в от системных требований мне рассказывать не надо.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[10]: Закат GPU?
От: Кэр  
Дата: 16.07.09 13:58
Оценка:
Здравствуйте, CreatorCray, Вы писали:

Кэр>>>>Т.е. эффект тени, например, приходится рендерить через ОЧЕНЬ большой изврат. Точнее целый набор таких извратов — каждый по случаю.

CC>>>Какие именно тени? Насколько я помню что стенсильные что проективные ничего особо извратного в себе не содержат.
Кэр>>Если я не ошибаюсь вы довольно частый участник КСВ с аргументацией "в линуксе все то же самое, что и винде".
CC>Тебе не передать как ты ошибаешься. Вообще считаю сие оскорблением.

Если ошибаюсь — тогда приношу извинения. Просто я стараюсь избегать дискуссий вида "Опен-офис также хорош как и MS офис" и дальше флейм на 500 страниц с подробным перечислением пунктов меню обоих офисов. В данный момент мне кажется, что разговор уходит в ту же сторону — сейчас мы выберем пару алгоритмов рендеринга теней, на базе которых будем утверждать, что доступ к сцене, например, при рендеринге теней вообще не особо нужен.

CC>Я в этой самой индустрии 4 года до недавнего времени работал.

CC>Так что про зависимость круга пользователей в от системных требований мне рассказывать не надо.

Мощно. Авторитетно. Т.е. толпа народа не покупала топовые карточки, чтобы только в Crysis побегать?
Re[10]: Закат GPU?
От: Кэр  
Дата: 16.07.09 14:17
Оценка:
Здравствуйте, Sergey Chadov, Вы писали:

SC>>>Еще раз, GPU — это уже далеко не только графика, давно уже существуют технологии GPGPU, то есть general-purpose GPU. На GPU решаются самые разные задачи, от моделирования фолдинга белков до брутфорса паролей. На некоторых задачах сообщается о приросте производительности в несколько сотен раз.


Кэр>>Давайте вы прочитаете статью, которую я привел. Статья поддерживает мою позицию практически по всем направлениям. Если вы начнете возражать аргументации из этой статьи — мы сразу пропустим несколько шагов в этом разговоре.


SC>Это все к делу не относится.


Может сразу стоит зафиксировать, о чем моя позиция — я говорю именно про использование GPU в игровой индустрии. Потому что если GPU в текущем виде не будут больше использоваться в game dev — то я считаю это закатом GPU. Биологи могут строить кластеры и писать вычисления на чем угодно. Если GPU уходят из game dev'а — то все остальные применения GPU — это капля в море.
И если при достаточном качестве картинки разработка игр под Larrabee вдруг будет стоить $1 mln вместо $10 mln — то игры будут выпускаться под Larrabee. Никого не будет волновать, что если сесть и напрячься, то можно вытянуть чуть побольше текстурок на обычных GPU. Это просто не стоит 9-ти миллионов.

SC>Дело обстоит так: существует две архитектуры вычислительных устройств, одна из них подразумевает относительно небольшое количество продвинутых процессоров, другая — большое количество процессоров-дебилов. Это грубо говоря, аналогично можно говорить и о памяти итп. Я не вижу никаких предпосылок, почему одна из этих арихтектур может вытеснить другую, поскольку существуют разные задачи, часть из которых объективно лучше(заметно лучше) решается на одной, часть — на другой. Возможно, эти архитектуры сблизятся: GPU станет ближе к CPU хотя бы для гибкости и простоты программироавния, CPU к GPU хотя бы потому, что при большом количестве ядер многие из используемых сейчас схем просто плохореализуемы.


Предпосылки вытеснения архитектуры, о которых я говорю конкретно для задач разработки игр — пока CPU рос вверх была ниша специальных процессоров. Они были относительное простые и их можно было сделать относительно много (больше чем CPU) и которые ускоряли конкретное софтверное решение рендеринга изображений изобретенное 25 лет назад. Это вовсе не означает, что это единственный способ, как можно рендерить изображение. Просто это способ, который умеют ускорять текущие GPU. Так вот пока CPU рос только вверх — ниша была гарантированна для подобных решений. Как только CPU достигли верхнего потолка и начали расти вширь — над текущим видом GPU навис большой такой меч. Просто потому что CPU предлагают модель, под которую разработывать будет гораздо проще.

SC>>>Я сейчас точно сказать не могу, но по-моему реализации raytracing на CUDA есть и показывают вполне неплохие результаты.

Кэр>>Так CUDA — на самом деле это и есть большой шаг в сторону CPU на самом деле. Сейчас там много ограничений — subset of C — это на самом деле грустно.
SC>"subset of C++" вообще-то. В частости, шаблонные функции вполне работают.

Шаблонные функции особенно в контексте отсутствия классов — это по сути макросы find&replace. Не достаточно чтобы можно было назвать CUDA subset of C++. Да и не так это важно — так как Larrabee будет исполнять x86 инструкции. Это означает, что у нас в руках огромное количество языков, которые будут исполняться на Larabee, а не один одинокий CUDA.

Кэр>> С++ выглядит здесь гораздо более внушительно.

SC>Да, но чудес не бывает, за простоту программирования всегда приходится расплачиваться.

Чудес не бывает. Но и простота и свобода реализации стоят очень многого.
Re[11]: Закат GPU?
От: CreatorCray  
Дата: 16.07.09 14:39
Оценка:
Здравствуйте, Кэр, Вы писали:

Кэр>Если ошибаюсь — тогда приношу извинения. Просто я стараюсь избегать дискуссий вида "Опен-офис также хорош как и MS офис" и дальше флейм на 500 страниц с подробным перечислением пунктов меню обоих офисов. В данный момент мне кажется, что разговор уходит в ту же сторону — сейчас мы выберем пару алгоритмов рендеринга теней, на базе которых будем утверждать, что доступ к сцене, например, при рендеринге теней вообще не особо нужен.

Опять мимо. Мне интересно было что это был за алгоритм, поскольку два мне известных под описание не подходят.

CC>>Я в этой самой индустрии 4 года до недавнего времени работал.

CC>>Так что про зависимость круга пользователей в от системных требований мне рассказывать не надо.
Кэр>Мощно. Авторитетно. Т.е. толпа народа не покупала топовые карточки, чтобы только в Crysis побегать?
Как ты думаешь, сколько толпа гиков будет в процентах от толпы, всех тех, кто купил Crysis?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[12]: Закат GPU?
От: Кэр  
Дата: 17.07.09 05:16
Оценка:
Здравствуйте, CreatorCray, Вы писали:

Кэр>>Если ошибаюсь — тогда приношу извинения. Просто я стараюсь избегать дискуссий вида "Опен-офис также хорош как и MS офис" и дальше флейм на 500 страниц с подробным перечислением пунктов меню обоих офисов. В данный момент мне кажется, что разговор уходит в ту же сторону — сейчас мы выберем пару алгоритмов рендеринга теней, на базе которых будем утверждать, что доступ к сцене, например, при рендеринге теней вообще не особо нужен.

CC>Опять мимо. Мне интересно было что это был за алгоритм, поскольку два мне известных под описание не подходят.

Под какое описание они не подходят? Они сделаны специально так чтобы прыгать вокруг GPU железа. В частности в стенсильных тенях (shadow volume видимо которые) есть четкая проблема — грани теней слишком резкие. Потому что как раз нельзя сделать вторичный запрос к сцене из шейдера.
Вот пример таких теней из DOOM3. Имхо, тени тошнотворные и нифига не реалистичные.
http://en.wikipedia.org/wiki/File:Doom3shadows.jpg

Кэр>>Мощно. Авторитетно. Т.е. толпа народа не покупала топовые карточки, чтобы только в Crysis побегать?

CC>Как ты думаешь, сколько толпа гиков будет в процентах от толпы, всех тех, кто купил Crysis?

Я вижу как продажи эксклюзивов на консолях бустят продажи. Думаю что здесь тоже можно применять подобный подход. Остальные втянуться. Лишь бы платформа получилась удобная. Как только можно будет опять софтверный рендер делать на уровне текущих рендереров — обратно дороги не будет.
Re[13]: Закат GPU?
От: CreatorCray  
Дата: 17.07.09 08:47
Оценка:
Здравствуйте, Кэр, Вы писали:

Кэр>>>Если ошибаюсь — тогда приношу извинения. Просто я стараюсь избегать дискуссий вида "Опен-офис также хорош как и MS офис" и дальше флейм на 500 страниц с подробным перечислением пунктов меню обоих офисов. В данный момент мне кажется, что разговор уходит в ту же сторону — сейчас мы выберем пару алгоритмов рендеринга теней, на базе которых будем утверждать, что доступ к сцене, например, при рендеринге теней вообще не особо нужен.

CC>>Опять мимо. Мне интересно было что это был за алгоритм, поскольку два мне известных под описание не подходят.
Кэр>Под какое описание они не подходят?
Под алгоритм, который требует обращений ко всей сцене при отрисовке тени.
Просто название скажи, мне интересно.

Кэр> Они сделаны специально так чтобы прыгать вокруг GPU железа.

Разумеется. А программы написанные под х86 написаны специально чтоб прыгать вокруг CPU железа.

Кэр>Вот пример таких теней из DOOM3. Имхо, тени тошнотворные и нифига не реалистичные.

Кэр>http://en.wikipedia.org/wiki/File:Doom3shadows.jpg
Нормальные стенсильные тени
Зубчатые проективные выглядят не лучше.
Для реалистичных реалтайм теней (да еще и с учетом переотражений) сильно дофига расчетов надо.

Кэр>>>Мощно. Авторитетно. Т.е. толпа народа не покупала топовые карточки, чтобы только в Crysis побегать?

CC>>Как ты думаешь, сколько толпа гиков будет в процентах от толпы, всех тех, кто купил Crysis?
Кэр>Я вижу как продажи эксклюзивов на консолях бустят продажи.
Консоль это жёстко фиксированное железо и жесткие требования к performance и даже времени запуска игры/загрузки уровня.
Какое отношение консоли имеют к покупке топовых карточек?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[2]: Закат GPU?
От: badcoder  
Дата: 17.07.09 09:40
Оценка:
Здравствуйте, Sergey Chadov, Вы писали:

SC>Без шансов, у GPU есть объективные преимущества, которые позволяют на определенном классе алгоритмов давать существенный прирост производительности. И если сделают 128-ядерный CPU, то можно сделать и какой-нибудь 16384-ядерный GPU.



Дайте-ка я сморожу, GPU ведь считает на float (страдает точность)? Или я уже отстал?
Re[8]: Закат GPU?
От: IID Россия  
Дата: 17.07.09 09:43
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Меня после умножения Карацубы уже ничем не удивить


Кстати, умножение через таблицы квадратов использовалось в ранних компьютерных играх. Т.к. в те годы популярные процессоры домашних машин не имели команд умножения (Z-80, 6502, или же оно было медленным. Например, в культовой игре тех лет — Elite используется как раз такой метод. Для точного знакового/беззнакового умножения 8бит х 8бит == 16бит достаточно таблички всего в 1кб, двух команд косвенной адресации, и одного 16битного вычитания. Что вполне по силам домашним компьютерам тех лет.
kalsarikännit
Re[3]: Закат GPU?
От: CreatorCray  
Дата: 17.07.09 11:19
Оценка:
Здравствуйте, badcoder, Вы писали:

B>Дайте-ка я сморожу, GPU ведь считает на float (страдает точность)? Или я уже отстал?

Отстал чуток
Есть int, float и double
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[3]: Закат GPU?
От: Sergey Chadov Россия  
Дата: 17.07.09 13:05
Оценка:
Здравствуйте, badcoder, Вы писали:

B>Здравствуйте, Sergey Chadov, Вы писали:


SC>>Без шансов, у GPU есть объективные преимущества, которые позволяют на определенном классе алгоритмов давать существенный прирост производительности. И если сделают 128-ядерный CPU, то можно сделать и какой-нибудь 16384-ядерный GPU.



B>Дайте-ка я сморожу, GPU ведь считает на float (страдает точность)? Или я уже отстал?


Во-первых, многим задачам на это наплевать, а в некоторых, которым не наплевать, можно выкрутиться . Во-вторых, считает уже и double, но очень хреново, поэтому все равно все считают во float. Ну так никто не идеален
--
Sergey Chadov

... << RSDN@Home 1.2.0 alpha rev. 685>>
Re[14]: Закат GPU?
От: Кэр  
Дата: 17.07.09 14:08
Оценка: :)))
Здравствуйте, CreatorCray, Вы писали:

Кэр>>Под какое описание они не подходят?

CC>Под алгоритм, который требует обращений ко всей сцене при отрисовке тени.
CC>Просто название скажи, мне интересно.

Вам нужен именнованный алгоритм, работающий на процессоре, который еще не вышел? Мне интересно зачем? Если вы не можете придумать вообще никакого алгоритма и вам нужно вообще хоть что-нибудь — при рендеринге тех же shadow volume теней — пробежаться по массиву пиксейлей подготовленных для рендеринга и навести blur эффект только на границы теней. В софтверном рендерере это будет возможно. Более того из-за локальности доступа (интересуют только соседи) и небольшого количества данных (интересуют только те пиксели, что должны попасть на экран) — это должно работать весьма шустро.

Кэр>> Они сделаны специально так чтобы прыгать вокруг GPU железа.

CC>Разумеется. А программы написанные под х86 написаны специально чтоб прыгать вокруг CPU железа.

Площадка для прыжков больше на сотни порядков. Никто не заставляет крутиться в рамках graphical pipeline придуманной более 20 лет назад.

CC>Для реалистичных реалтайм теней (да еще и с учетом переотражений) сильно дофига расчетов надо.


Да нет, надо всего-то получить побольше свободы в действиях и в определении того как это будет рендериться. Это область неизведанная. Не было еще такого количества CPU да еще и с векторными инструкциями собранных под одной крышей.

Кэр>>Я вижу как продажи эксклюзивов на консолях бустят продажи.

CC>Консоль это жёстко фиксированное железо и жесткие требования к performance и даже времени запуска игры/загрузки уровня.
CC>Какое отношение консоли имеют к покупке топовых карточек?

Они показывают пример, как наличие эксклюзивного софта может бустить продажи определенного hardware. Я не знаю, что там в Интел происходит, но будь я на их месте — я бы тесно сотрудничал с парой-тройкой ведущих гейм-дев компаний с целью выпуска чего-нибудь яркого на Larrabee к моменту выпуска. При условии, если Larrabee будет тянуть все современные игры и наличии таких эксклюзивов — буст продаж должен быть хороший.
Re[3]: а как же Larrabee?
От: thesz Россия http://thesz.livejournal.com
Дата: 20.07.09 08:53
Оценка:
Здравствуйте, minorlogic, Вы писали:

M>Здравствуйте, thesz, Вы писали:


T>>На компиляции с помощью одного ядра современный Core 2 будет рвать Лараби, как Тузик грелку.


M>Это очевидно, но в том то и дело что ядер будет много.


Компиляция плохо распараллеливается (на coarse grained parallelism, как в Лараби).
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[11]: Закат GPU?
От: thesz Россия http://thesz.livejournal.com
Дата: 20.07.09 10:42
Оценка: +1
Кэр>Шаблонные функции особенно в контексте отсутствия классов — это по сути макросы find&replace. Не достаточно чтобы можно было назвать CUDA subset of C++.

Примитив соединения двух векторов:
vector<T,LA+LB> concat(vector<T,LA>, vector<T,LB>).

Кэр>Да и не так это важно — так как Larrabee будет исполнять x86 инструкции. Это означает, что у нас в руках огромное количество языков, которые будут исполняться на Larabee, а не один одинокий CUDA.


x86 в контексте Лараби означает очень низкую производительность.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[2]: Закат GPU?
От: thesz Россия http://thesz.livejournal.com
Дата: 20.07.09 10:50
Оценка: -1 :)
Кэр>>В связи с тем, что не за горами CPU с 128 и более ядрами — вопрос, а нужны ли тогда будут GPU? Основная фича GPU — их много. Они тупые, умеют считать только шейдеры, но их много и обработка шейдеров хорошо параллелиться. Однако, существует целый паравоз проблем из-за того, что мы имеем отдельный вид процессоров: отдельная память, отдельные инструкции, просто отдельный вид ассемблерных инструкций.
I>Да, зато имеем ряд преимуществ — GPU на порядок минимум мощнее многоядерного процессора.

На каких задачах?

I>Нет, не пора. Потребности в хорошей графике никогда не бывают достаточными, дашь бОльше CPU(ядер) значит надо дать больше памяти , шире и быстрее шина, и кеш посильне и тд и тд, и после всего этого всех этих ресурсов будет еле-еле хватать на игрушку последнего поколения.

I>Перформанс не растет линейно из за добавления CPU. Одноядрные CPU уже выдохлись, со временем выдохнутяс и многоядерные в том виде, как они сейчас.

http://wavescalar.cs.washington.edu/
http://en.wikipedia.org/wiki/Explicit_Data_Graph_Execution#EDGE

У любой технологии есть свои пределы. Так что "выдохнуться и многоядерные" не несёт собого смысла.

I>Где взять перформансу — GPU(ну или специлизированые xPU) ! Кстати говоря, некоторые пробуют юзать GPU для ускорения вычислений не связаных с графикой.


Если бы это было выгодно (по затраченным на сборку, поддержку и программирование усилиям), то IBM бы давно потеряла все контракты на суперкомпьютеры.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[3]: Закат GPU?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 20.07.09 12:26
Оценка:
Здравствуйте, thesz, Вы писали:

Кэр>>>В связи с тем, что не за горами CPU с 128 и более ядрами — вопрос, а нужны ли тогда будут GPU? Основная фича GPU — их много. Они тупые, умеют считать только шейдеры, но их много и обработка шейдеров хорошо параллелиться. Однако, существует целый паравоз проблем из-за того, что мы имеем отдельный вид процессоров: отдельная память, отдельные инструкции, просто отдельный вид ассемблерных инструкций.

I>>Да, зато имеем ряд преимуществ — GPU на порядок минимум мощнее многоядерного процессора.

T>На каких задачах?


Обработка графической информации.

I>>Где взять перформансу — GPU(ну или специлизированые xPU) ! Кстати говоря, некоторые пробуют юзать GPU для ускорения вычислений не связаных с графикой.


T>Если бы это было выгодно (по затраченным на сборку, поддержку и программирование усилиям), то IBM бы давно потеряла все контракты на суперкомпьютеры.


GPU не избавляют от необходимости иметь супер-компьютеры.
Re[4]: Закат GPU?
От: thesz Россия http://thesz.livejournal.com
Дата: 20.07.09 12:48
Оценка: +1
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, thesz, Вы писали:


Кэр>>>>В связи с тем, что не за горами CPU с 128 и более ядрами — вопрос, а нужны ли тогда будут GPU? Основная фича GPU — их много. Они тупые, умеют считать только шейдеры, но их много и обработка шейдеров хорошо параллелиться. Однако, существует целый паравоз проблем из-за того, что мы имеем отдельный вид процессоров: отдельная память, отдельные инструкции, просто отдельный вид ассемблерных инструкций.

I>>>Да, зато имеем ряд преимуществ — GPU на порядок минимум мощнее многоядерного процессора.

T>>На каких задачах?

I>Обработка графической информации.

А на физике? Хотя бы игровой. Там оно как?

I>>>Где взять перформансу — GPU(ну или специлизированые xPU) ! Кстати говоря, некоторые пробуют юзать GPU для ускорения вычислений не связаных с графикой.

T>>Если бы это было выгодно (по затраченным на сборку, поддержку и программирование усилиям), то IBM бы давно потеряла все контракты на суперкомпьютеры.
I>GPU не избавляют от необходимости иметь супер-компьютеры.

А почему?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[5]: Закат GPU?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 20.07.09 12:55
Оценка:
Здравствуйте, thesz, Вы писали:

Кэр>>>>>В связи с тем, что не за горами CPU с 128 и более ядрами — вопрос, а нужны ли тогда будут GPU? Основная фича GPU — их много. Они тупые, умеют считать только шейдеры, но их много и обработка шейдеров хорошо параллелиться. Однако, существует целый паравоз проблем из-за того, что мы имеем отдельный вид процессоров: отдельная память, отдельные инструкции, просто отдельный вид ассемблерных инструкций.

I>>>>Да, зато имеем ряд преимуществ — GPU на порядок минимум мощнее многоядерного процессора.

T>>>На каких задачах?

I>>Обработка графической информации.

T>А на физике? Хотя бы игровой. Там оно как?


Понемногу осваивается. Кроме того, есть GPGPU которая помогает ускорять многие вещи и разгрузить CPU.

I>>>>Где взять перформансу — GPU(ну или специлизированые xPU) ! Кстати говоря, некоторые пробуют юзать GPU для ускорения вычислений не связаных с графикой.

T>>>Если бы это было выгодно (по затраченным на сборку, поддержку и программирование усилиям), то IBM бы давно потеряла все контракты на суперкомпьютеры.
I>>GPU не избавляют от необходимости иметь супер-компьютеры.

T>А почему?


Потому что задачи и требования другие.
Re[2]: Закат GPU?
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 20.07.09 13:12
Оценка:
Кэр>>Так что закономерный вопрос: когда CPU тоже станет очень много — не проще ли будет гонять графику прямо на CPU. Какие причины будут содержать GPU в комплекте? Не пора ли NVidia сворачивать бизнес?

M>На мой взгляд , тут идет сближение с обоих сторон. GPU учаться новым командам, ветвления и т.п. а CPU наращивают мускулы. Близится их соединение.


Подобное давно уже есть. Процессор Cell — именно соединение управляющего процессора с несколькими потоковыми.
Sony не жалуется.
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[2]: Закат GPU?
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 20.07.09 13:29
Оценка:
AF>А я подозреваю, что намного ближе закат x86 CPU Архитектура плохо приспособлена для паралеллизма, чем больше ядер — тем меньше выигрыш и больше накладные расходы на синхронизацию. 4-ядерники в массовой продаже уже несколько лет, а программ которые могут использовать столько ядер — можно на пальцах пересчитать. И выигрыш они дают далеко не 4-кратный.

Ну PowerPC они вроде порвали причём на старте, если считать стартом освобождение IBM от ограничений лицензии.
Sun тоже еле движется со своим троглодитом.
Cell пока не очень популярен ибо сильно потоковый.

ИМХО скорее у интела получится снизить затраты на синхронизацию (или какие там ещё проблемы), чем конкурентам сделать что-то круче.
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[6]: Закат GPU?
От: thesz Россия http://thesz.livejournal.com
Дата: 20.07.09 13:36
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, thesz, Вы писали:


Кэр>>>>>>В связи с тем, что не за горами CPU с 128 и более ядрами — вопрос, а нужны ли тогда будут GPU? Основная фича GPU — их много. Они тупые, умеют считать только шейдеры, но их много и обработка шейдеров хорошо параллелиться. Однако, существует целый паравоз проблем из-за того, что мы имеем отдельный вид процессоров: отдельная память, отдельные инструкции, просто отдельный вид ассемблерных инструкций.

I>>>>>Да, зато имеем ряд преимуществ — GPU на порядок минимум мощнее многоядерного процессора.

T>>>>На каких задачах?

I>>>Обработка графической информации.
T>>А на физике? Хотя бы игровой. Там оно как?
I>Понемногу осваивается. Кроме того, есть GPGPU которая помогает ускорять многие вещи и разгрузить CPU.

И какие же вещи они, эти магические GPU, ускоряют?

(физика интересна вот, почему: решение "в лоб" приводит к необходимости решения задачи LCP, плохо решаемый без out-of-order, но можно брать очень маленький шаг времени — ~0,001 секунды и меньше, — и тогда можно не решать LCP, поскольку ошибка будет мала. прямой размен производительности на простоту программирования.)

I>>>GPU не избавляют от необходимости иметь супер-компьютеры.

T>>А почему?
I>Потому что задачи и требования другие.

И какие же?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[6]: Закат GPU?
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 20.07.09 13:46
Оценка:
WH>>>Лучше так: Много ли есть задач для которых нет эффективных параллельных алгоритмов?
CC>>"Ты не поверишь!" (С)
WH>Огласите весь список пожалуйста.

И отфильтруйте по тем задачам, которые могут подвесить по производительности ядро процессора ну допустим i7-950 допустим на пару секунд.
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[2]: Закат GPU?
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 20.07.09 14:03
Оценка:
Л>Графические процессоры ближе к той архитектуре, которой следовало бы быть у компьютеров. А следовало бы не иметь разделения на процессор и память вообще. Т. е. выполнять операции с числами должна сама память. Разумеется, с возможностью параллелизма на всю свою ёмкость. Также, она должна программироваться на создание определённой структуры передачи и обработки потоков информации.

Ты проектировал процессоры? Или так, мысль вслух вшептнул?
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[6]: Закат GPU?
От: WinterMute Россия http://yarrr.ru
Дата: 20.07.09 14:33
Оценка: -1 :))
WH>>>Лучше так: Много ли есть задач для которых нет эффективных параллельных алгоритмов?
CC>>"Ты не поверишь!" (С)
WH>Огласите весь список пожалуйста.

Первое что приходит на ум: поиск в отсортированнном массиве. Не такая уж редкая задача.
Re[4]: а как же Larrabee?
От: Andrei F.  
Дата: 20.07.09 15:04
Оценка:
Здравствуйте, thesz, Вы писали:

T>Компиляция плохо распараллеливается (на coarse grained parallelism, как в Лараби).


Каждому ядру — по файлу исходника, и пусть компилируют.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[7]: Закат GPU?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 20.07.09 19:12
Оценка:
Здравствуйте, thesz, Вы писали:

I>>>>Обработка графической информации.

T>>>А на физике? Хотя бы игровой. Там оно как?
I>>Понемногу осваивается. Кроме того, есть GPGPU которая помогает ускорять многие вещи и разгрузить CPU.

T>И какие же вещи они, эти магические GPU, ускоряют?


Это не магические GPU. Это обычные специализированые процессоры.

http://www.gpgpu.ru/

I>>>>GPU не избавляют от необходимости иметь супер-компьютеры.

T>>>А почему?
I>>Потому что задачи и требования другие.

T>И какие же?


В основном моделирование различных процессов, мега-вычисления различные
при чем, кстати говоря!, многие суперкомпьютеры построены на GPU, которыми управляют обычные СPU. В итоге можно в системе размером с настольный ПК выжать производительность минимум на порядок и даже два выше обычного ПК такого же размера.
Re[5]: а как же Larrabee?
От: thesz Россия http://thesz.livejournal.com
Дата: 20.07.09 20:00
Оценка:
Здравствуйте, Andrei F., Вы писали:

AF>Здравствуйте, thesz, Вы писали:


T>>Компиляция плохо распараллеливается (на coarse grained parallelism, как в Лараби).


AF>Каждому ядру — по файлу исходника, и пусть компилируют.


Значительное время в компиляции C++ занимает разбор, который — в случае gcc, — параллелизуется плохо.

И там на каждом ядре будет по копии всего синтаксического дерева всего проекта, ты не подумал об этом?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[8]: Закат GPU?
От: thesz Россия http://thesz.livejournal.com
Дата: 20.07.09 20:03
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, thesz, Вы писали:


I>>>>>Обработка графической информации.

T>>>>А на физике? Хотя бы игровой. Там оно как?
I>>>Понемногу осваивается. Кроме того, есть GPGPU которая помогает ускорять многие вещи и разгрузить CPU.

T>>И какие же вещи они, эти магические GPU, ускоряют?

I>Это не магические GPU. Это обычные специализированые процессоры.

И какие же вещи они, эти магические обычные специализированные процессоры, ускоряют?

I>http://www.gpgpu.ru/


Перечисли, пожалуйста. А то я не понимаю, что ускоряется с помощью CUDA, а что с помощью OpenCL.

I>>>>>GPU не избавляют от необходимости иметь супер-компьютеры.

T>>>>А почему?
I>>>Потому что задачи и требования другие.
T>>И какие же?
I>В основном моделирование различных процессов, мега-вычисления различные
I>при чем, кстати говоря!, многие суперкомпьютеры построены на GPU, которыми управляют обычные СPU.

Как много таких в Top500?

I>В итоге можно в системе размером с настольный ПК выжать производительность минимум на порядок и даже два выше обычного ПК такого же размера.


На каких задачах? С числами какой точности?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[7]: Закат GPU?
От: thesz Россия http://thesz.livejournal.com
Дата: 20.07.09 20:08
Оценка: +1
Здравствуйте, VGn, Вы писали:

WH>>>>Лучше так: Много ли есть задач для которых нет эффективных параллельных алгоритмов?

CC>>>"Ты не поверишь!" (С)
WH>>Огласите весь список пожалуйста.

VGn>И отфильтруйте по тем задачам, которые могут подвесить по производительности ядро процессора ну допустим i7-950 допустим на пару секунд.


RSA с большим ключом, SHA-1 большого сообщения.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[6]: а как же Larrabee?
От: Andrei F.  
Дата: 21.07.09 04:49
Оценка:
Здравствуйте, thesz, Вы писали:

T>И там на каждом ядре будет по копии всего синтаксического дерева всего проекта, ты не подумал об этом?


Зачем для всего дерева? Только AST тех хэдеров, которые импортируются в файл. Понятно, что сначала нужно будет построить дерево зависимостей файлов, и по нему уже распределять работу.
И всё будет вполне прилично параллелиться, даже без необходимости менять сам компилятор.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[7]: Закат GPU?
От: WolfHound  
Дата: 21.07.09 20:02
Оценка: +1
Здравствуйте, WinterMute, Вы писали:

WM>Первое что приходит на ум: поиск в отсортированнном массиве. Не такая уж редкая задача.

1)"поиск в отсортированном массиве" это как правило часть конкретного решения конкретной задачи.
2)Параллелить операцию со сложностью O(Log(N)) мягко говоря мало смысла в любом случае.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[8]: Закат GPU?
От: WolfHound  
Дата: 21.07.09 20:11
Оценка:
Здравствуйте, thesz, Вы писали:

T>RSA с большим ключом,

Принято.
Но асимметричные шифры для больших сообщений как правило не используют.
А если брать симметричные то мы имеем например http://en.wikipedia.org/wiki/Salsa20

T>SHA-1 большого сообщения.

Опять таки если не зацикливаться на конкретном алгоритме то см md6.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[6]: а как же Larrabee?
От: WolfHound  
Дата: 21.07.09 20:24
Оценка:
Здравствуйте, thesz, Вы писали:

T>Значительное время в компиляции C++ занимает разбор, который — в случае gcc, — параллелизуется плохо.

T>И там на каждом ядре будет по копии всего синтаксического дерева всего проекта, ты не подумал об этом?
Есть такая хрень IncrediBuild называется... она явно показывает что компиляцию можно распараллелить не только по ядрам но и по куче машин.
Да и вижулстудия когда видит несколько ядер начинает несколько исходников параллельно компилировать.
В том же немерле хоть и пока не сделано но вполне реально запускать типизацию всех функций пареллено.
Короче твое утверждение про то что компиляторы не пареллеляться мягко говоря не соответствует действительности.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[7]: а как же Larrabee?
От: thesz Россия http://thesz.livejournal.com
Дата: 21.07.09 20:38
Оценка:
Здравствуйте, Andrei F., Вы писали:

AF>Здравствуйте, thesz, Вы писали:


T>>И там на каждом ядре будет по копии всего синтаксического дерева всего проекта, ты не подумал об этом?


AF>Зачем для всего дерева? Только AST тех хэдеров, которые импортируются в файл.


Весьма объёмная часть от проекта. Отличающаяся по объёму от всего проекта в константу раз, а, значит, имеющая ту же сложность O(размер_проекта).

Иными словами — дерево всего проекта.

AF>Понятно, что сначала нужно будет построить дерево зависимостей файлов, и по нему уже распределять работу.

AF>И всё будет вполне прилично параллелиться, даже без необходимости менять сам компилятор.

Вот "без необходимости" это я бы порекомендовал проверить.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[9]: Закат GPU?
От: thesz Россия http://thesz.livejournal.com
Дата: 21.07.09 20:42
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, thesz, Вы писали:


T>>RSA с большим ключом,

WH>Принято.
WH>Но асимметричные шифры для больших сообщений как правило не используют.

Большой ключ это не большое сообщение.

WH>А если брать симметричные то мы имеем например http://en.wikipedia.org/wiki/Salsa20


В своё время это был DES(Block[i] XOR i).

T>>SHA-1 большого сообщения.

WH>Опять таки если не зацикливаться на конкретном алгоритме то см md6.

Ага, понятно. Я подожду, пока это будет проверено.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[7]: а как же Larrabee?
От: thesz Россия http://thesz.livejournal.com
Дата: 21.07.09 20:45
Оценка: -1
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, thesz, Вы писали:


T>>Значительное время в компиляции C++ занимает разбор, который — в случае gcc, — параллелизуется плохо.

T>>И там на каждом ядре будет по копии всего синтаксического дерева всего проекта, ты не подумал об этом?
WH>Есть такая хрень IncrediBuild называется... она явно показывает что компиляцию можно распараллелить не только по ядрам но и по куче машин.
WH>Да и вижулстудия когда видит несколько ядер начинает несколько исходников параллельно компилировать.
WH>В том же немерле хоть и пока не сделано но вполне реально запускать типизацию всех функций пареллено.
WH>Короче твое утверждение про то что компиляторы не пареллеляться мягко говоря не соответствует действительности.

Распараллель разбор C++ исходника, тогда поговорим. Разбор занимает много времени, что-то порядка 20%, что ли.

Лично моё мнение таково: для распараллеливания придётся переползти с LALR на CYK (он работает над всем файлом сразу), а это означает серъёзную переработку разбора и его окружения.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[10]: Закат GPU?
От: WolfHound  
Дата: 21.07.09 21:06
Оценка:
Здравствуйте, thesz, Вы писали:

WH>>А если брать симметричные то мы имеем например http://en.wikipedia.org/wiki/Salsa20

T>В своё время это был DES(Block[i] XOR i).
Вот так больше похоже Block[i] XOR DES(i)
Но DES давно разломали.
А не сильно покоцанную сальсу даже не поцарапали.

T>Ага, понятно. Я подожду, пока это будет проверено.

Даже если поломают md6 то все равно не тех же принципах сделают легко распараллеливаемую хешфункцию.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[8]: а как же Larrabee?
От: WolfHound  
Дата: 21.07.09 21:23
Оценка: 1 (1) :)
Здравствуйте, thesz, Вы писали:

T>Распараллель разбор C++ исходника, тогда поговорим. Разбор занимает много времени, что-то порядка 20%, что ли.

1)Где ты видел проект из одного файла? Еще раз читай про IncrediBuild и то как он работает. Сборку реальных проектов ускоряет капитально. Сам видел.
2)С++ имеет абсолютно дебильную структуру которую невозможно эффективно парсить. К счастью не все языки столь дурацки сделаны.
3)20%? На парсинг? Не верю! А если появляются шаблоны то там разбор текста ты и в микроскоп не увидишь.
4)Когда дело доходит до оптимизации и кодогенерации там можно параллелить и параллелить.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[11]: Закат GPU?
От: thesz Россия http://thesz.livejournal.com
Дата: 21.07.09 22:02
Оценка: +1
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, thesz, Вы писали:


WH>>>А если брать симметричные то мы имеем например http://en.wikipedia.org/wiki/Salsa20

T>>В своё время это был DES(Block[i] XOR i).
WH>Вот так больше похоже Block[i] XOR DES(i)

Легко показать, почему так нельзя.

Мы знаем что известный нам block[i] стал block[j] в другом сообщении. Значит, мы сможем вычислить block[j] в первом. В случае DES(block[i] XOR i) будет сложнее так сделать. А если мы ещё и добавим случайное число DES(block[i] XOR i XOR nonce), то так поступить будет невозможно в принципе.

WH>Но DES давно разломали.


Возьми любой другой современный блочный шифр. DES был в качестве примера.

WH>А не сильно покоцанную сальсу даже не поцарапали.


Она молодая.

T>>Ага, понятно. Я подожду, пока это будет проверено.

WH>Даже если поломают md6 то все равно не тех же принципах сделают легко распараллеливаемую хешфункцию.

Это невыгодно, поскольку ускоряет перебор.

Я вполне серьёзен.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[9]: а как же Larrabee?
От: thesz Россия http://thesz.livejournal.com
Дата: 21.07.09 22:05
Оценка: -2 :)))
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, thesz, Вы писали:


T>>Распараллель разбор C++ исходника, тогда поговорим. Разбор занимает много времени, что-то порядка 20%, что ли.

WH>1)Где ты видел проект из одного файла?

После препроцессора он становится одним файлом.

WH>Еще раз читай про IncrediBuild и то как он работает. Сборку реальных проектов ускоряет капитально. Сам видел.


Да и make -n тоже, вроде, как.

WH>2)С++ имеет абсолютно дебильную структуру которую невозможно эффективно парсить. К счастью не все языки столь дурацки сделаны.


А мы их отметём, как неорганиозванные.

WH>3)20%? На парсинг? Не верю! А если появляются шаблоны то там разбор текста ты и в микроскоп не увидишь.

WH>4)Когда дело доходит до оптимизации и кодогенерации там можно параллелить и параллелить.

Мои коллеги-компиляторщики, писавшие автоматически распараллеливающий компилятор на основе gcc, не делали попыток автоматически распараллелить свой компилятор. За безнадёжностью.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[12]: Закат GPU?
От: WolfHound  
Дата: 21.07.09 22:40
Оценка:
Здравствуйте, thesz, Вы писали:

WH>>Вот так больше похоже Block[i] XOR DES(i)

T>Легко показать, почему так нельзя.
Cальса работает так: Block[i] xor Salsa(key, nonce, i)
Как следствие этим шифром можно зашифровать любое количество бит не парясь с паддингом и все классы атак которые основаны на всяких хитрых манипуляциях с сообщением также отваливаются.

WH>>А не сильно покоцанную сальсу даже не поцарапали.

T>Она молодая.
Это не отменяет того что по ней капитально прошлись всеми известными криптоанализами.
Если бы DES придумали сегодня то его бы разломали на раз.

T>Это невыгодно, поскольку ускоряет перебор.

T>Я вполне серьёзен.
Есть ссылки?
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[10]: а как же Larrabee?
От: WolfHound  
Дата: 21.07.09 22:55
Оценка: :)
Здравствуйте, thesz, Вы писали:

T>После препроцессора он становится одним файлом.

Я начинаю сомневаться в том что ты знаешь как компилируется С++.
В один файл сливаются все заголовки прямо или косвенно подключенные к cpp файлу.
Но разные cpp файлы в один не сливаются.

T>Да и make -n тоже, вроде, как.

Во-во. По тому я и говорю что компиляция реальных проектов весьма неплохо параллелится даже с учетом современных тупых компиляторов.

T>А мы их отметём, как неорганиозванные.

А если не отметать?

T>Мои коллеги-компиляторщики, писавшие автоматически распараллеливающий компилятор на основе gcc, не делали попыток автоматически распараллелить свой компилятор. За безнадёжностью.

За безнадежностью распараллеливания gcc?
Я бы тоже не решился параллелить страшный сишный код.
А вот код написанный на функциональном языке причем без грязи можно распареллелить очень не плохо. Хотябы на уровне замены в нескольких местах map на parallelMap.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[12]: Закат GPU?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 22.07.09 03:51
Оценка: 1 (1)
Здравствуйте, thesz, Вы писали:

T>>>Ага, понятно. Я подожду, пока это будет проверено.

WH>>Даже если поломают md6 то все равно не тех же принципах сделают легко распараллеливаемую хешфункцию.
T>Это невыгодно, поскольку ускоряет перебор. ;)
T>Я вполне серьёзен.

Перебор чего и как? Вычисление хэша короткого ввода (как пароль), для которого нужен перебор, это не ускорит. А задача "вычислить соответствующий данному хэшу документ, соответствующий всем нормам соответствующей грамматики" и так параллелится за счёт множества проб.
The God is real, unless declared integer.
Re[8]: а как же Larrabee?
От: Andrei F.  
Дата: 22.07.09 04:24
Оценка:
Здравствуйте, thesz, Вы писали:

T>Весьма объёмная часть от проекта. Отличающаяся по объёму от всего проекта в константу раз, а, значит, имеющая ту же сложность O(размер_проекта).

T>Иными словами — дерево всего проекта.

Вот за что я не люблю теоретиков.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[8]: а как же Larrabee?
От: CreatorCray  
Дата: 22.07.09 07:51
Оценка:
Здравствуйте, thesz, Вы писали:

T>Распараллель разбор C++ исходника, тогда поговорим. Разбор занимает много времени, что-то порядка 20%, что ли.

Параллелить можно по-разному.
Можно каждый цикл параллелить, а можно логический блок.
Можно пытаться ускорить разбор одного файла, как ты предлагаешь. А можно обработать одновременно несколько файлов, как сделано производителями компиляторов (микрософт и интел)
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[10]: а как же Larrabee?
От: CreatorCray  
Дата: 22.07.09 07:51
Оценка:
Здравствуйте, thesz, Вы писали:

T>>>Распараллель разбор C++ исходника, тогда поговорим. Разбор занимает много времени, что-то порядка 20%, что ли.

WH>>1)Где ты видел проект из одного файла?
T>После препроцессора он становится одним файлом.
Нет!
Если у тебя есть 1.cpp и 2.сpp то после препроцессора у тебя все равно 2 файла. И тот самый разбор исходника будет происходить уже после препроцессора.

WH>>Еще раз читай про IncrediBuild и то как он работает. Сборку реальных проектов ускоряет капитально. Сам видел.

T>Да и make -n тоже, вроде, как.
Он тоже умеет раскидывать компиляцию по разным компам и ядрам проца?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[13]: Закат GPU?
От: thesz Россия http://thesz.livejournal.com
Дата: 22.07.09 10:07
Оценка:
Здравствуйте, netch80, Вы писали:

N>Здравствуйте, thesz, Вы писали:


T>>Это невыгодно, поскольку ускоряет перебор.


N>Перебор чего и как? Вычисление хэша короткого ввода (как пароль), для которого нужен перебор, это не ускорит. А задача "вычислить соответствующий данному хэшу документ, соответствующий всем нормам соответствующей грамматики" и так параллелится за счёт множества проб.


Да, не подумал.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[13]: Закат GPU?
От: thesz Россия http://thesz.livejournal.com
Дата: 22.07.09 10:11
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, thesz, Вы писали:


WH>>>Вот так больше похоже Block[i] XOR DES(i)

T>>Легко показать, почему так нельзя.
WH>Cальса работает так: Block[i] xor Salsa(key, nonce, i)
WH>Как следствие этим шифром можно зашифровать любое количество бит не парясь с паддингом и все классы атак которые основаны на всяких хитрых манипуляциях с сообщением также отваливаются.

Сальса — потоковый шифр. nonce ему помогает, но спасает не полностью.

WH>>>А не сильно покоцанную сальсу даже не поцарапали.

T>>Она молодая.
WH>Это не отменяет того что по ней капитально прошлись всеми известными криптоанализами.
WH>Если бы DES придумали сегодня то его бы разломали на раз.

Современные варианты криптоанализа (конкретно, дифференциальный криптоанализ) снижают стоимость перебора DES с 2**56 до 2**49.5. Это при условии, что ты можешь зашифровать порядка 2**20 выбранных тобой блоков (chosen plaintext). При использовании известных тебе блоков (known plaintext) количество необходимых данных растёт порядка на полтора или два, сейчас уже и не помню.

DES очень, очень хороший шифр.

T>>Это невыгодно, поскольку ускоряет перебор.

T>>Я вполне серьёзен.
WH>Есть ссылки?

Тут неподалёку netch80 указал, что я неправ.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[9]: а как же Larrabee?
От: thesz Россия http://thesz.livejournal.com
Дата: 22.07.09 10:12
Оценка: +1 :)
Здравствуйте, Andrei F., Вы писали:

AF>Здравствуйте, thesz, Вы писали:


T>>Весьма объёмная часть от проекта. Отличающаяся по объёму от всего проекта в константу раз, а, значит, имеющая ту же сложность O(размер_проекта).

T>>Иными словами — дерево всего проекта.

AF>Вот за что я не люблю теоретиков.


И за что конкретно ты не любишь конкретно кого?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[9]: а как же Larrabee?
От: thesz Россия http://thesz.livejournal.com
Дата: 22.07.09 10:18
Оценка:
Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, thesz, Вы писали:


T>>Распараллель разбор C++ исходника, тогда поговорим. Разбор занимает много времени, что-то порядка 20%, что ли.

CC>Параллелить можно по-разному.
CC>Можно каждый цикл параллелить, а можно логический блок.
CC>Можно пытаться ускорить разбор одного файла, как ты предлагаешь. А можно обработать одновременно несколько файлов, как сделано производителями компиляторов (микрософт и интел)

Итак, мы большую часть времени работаем с одним файлом. Большим файлом, на мег (реальный пример).

Как обработка нескольких файлов сможет ускорить нам компиляцию нашего большого файла?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[11]: а как же Larrabee?
От: thesz Россия http://thesz.livejournal.com
Дата: 22.07.09 10:22
Оценка:
Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, thesz, Вы писали:


T>>>>Распараллель разбор C++ исходника, тогда поговорим. Разбор занимает много времени, что-то порядка 20%, что ли.

WH>>>1)Где ты видел проект из одного файла?
T>>После препроцессора он становится одним файлом.
CC> Нет!
CC>Если у тебя есть 1.cpp и 2.сpp то после препроцессора у тебя все равно 2 файла. И тот самый разбор исходника будет происходить уже после препроцессора.

Если у меня 1.cc, включающий в себя 2.h, то после препроцессора он станет 1.i и будет включать в себя оба.

Объём заголовочных файлов сравним с объёмом файлов с исходниками.

WH>>>Еще раз читай про IncrediBuild и то как он работает. Сборку реальных проектов ускоряет капитально. Сам видел.

T>>Да и make -n тоже, вроде, как.

make -j N
make --jobs=N

CC>Он тоже умеет раскидывать компиляцию по разным компам и ядрам проца?


Он несколько процессов запускает.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[12]: а как же Larrabee?
От: CreatorCray  
Дата: 22.07.09 11:57
Оценка:
Здравствуйте, thesz, Вы писали:

T>>>>>Распараллель разбор C++ исходника, тогда поговорим. Разбор занимает много времени, что-то порядка 20%, что ли.

WH>>>>1)Где ты видел проект из одного файла?
T>>>После препроцессора он становится одним файлом.
CC>> Нет!
CC>>Если у тебя есть 1.cpp и 2.сpp то после препроцессора у тебя все равно 2 файла. И тот самый разбор исходника будет происходить уже после препроцессора.
T>Если у меня 1.cc, включающий в себя 2.h, то после препроцессора он станет 1.i и будет включать в себя оба.

Еще раз: Где ты видел проект из одного файла? Из одного .cpp файла?
Такой сценарий никто даже и не рассматривает.

WH>>>>Еще раз читай про IncrediBuild и то как он работает. Сборку реальных проектов ускоряет капитально. Сам видел.

T>>>Да и make -n тоже, вроде, как.
CC>>Он тоже умеет раскидывать компиляцию по разным компам и ядрам проца?
T>Он несколько процессов запускает.
Это придумано уже давно.
Но колво процессов на конкретно взятой девелоперской машине в первую очередь ограничено колвом ядер проца.
У меня на старой работе колво задействованных в компиляции через Incredibuild ядер доходило до 30.
Прирост скорости получался почти линейный.
Так что IB все таки для не-одного-девелопера все таки лучше
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[10]: а как же Larrabee?
От: CreatorCray  
Дата: 22.07.09 11:57
Оценка:
Здравствуйте, thesz, Вы писали:

T>Итак, мы большую часть времени работаем с одним файлом. Большим файлом, на мег (реальный пример).

Уточни пожалуйста, чтож это за проект такой, который состоит из одного файла исходников в метр толщиной.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[13]: а как же Larrabee?
От: thesz Россия http://thesz.livejournal.com
Дата: 22.07.09 12:30
Оценка:
Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, thesz, Вы писали:


T>>>>>>Распараллель разбор C++ исходника, тогда поговорим. Разбор занимает много времени, что-то порядка 20%, что ли.

WH>>>>>1)Где ты видел проект из одного файла?
T>>>>После препроцессора он становится одним файлом.
CC>>> Нет!
CC>>>Если у тебя есть 1.cpp и 2.сpp то после препроцессора у тебя все равно 2 файла. И тот самый разбор исходника будет происходить уже после препроцессора.
T>>Если у меня 1.cc, включающий в себя 2.h, то после препроцессора он станет 1.i и будет включать в себя оба.

CC>Еще раз: Где ты видел проект из одного файла? Из одного .cpp файла?

CC>Такой сценарий никто даже и не рассматривает.

Вот, смотри. У нас есть объём всего проекта, V. Количество информации в заголовочных файлах этого проекта будет kV, k<1 и зависит от среднего стиля кодирования (количества взаимозависимостей). Средний *.cc будет использовать только определённый процент q от общего количества всех заголовочных файлов, итого, к .cc (который имеет размер v не зависящий от размера проекта) добавился код. Общий объём одного .cc и всех нужных ему файлов составит v+kV. Сложность обработки будет O(V), если ты понимаешь, что такое сложность.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[14]: а как же Larrabee?
От: CreatorCray  
Дата: 22.07.09 12:46
Оценка:
Здравствуйте, thesz, Вы писали:

"Ты не зюзюкай, ты рукой махни" (С)

Сколько LOC у вас приходится на .h и на .cpp файлы?
Или у вас в .h шаблоны на шаблонах?
Про PCH опять таки забыли.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[15]: а как же Larrabee?
От: thesz Россия http://thesz.livejournal.com
Дата: 22.07.09 12:59
Оценка: :)
Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, thesz, Вы писали:


CC>"Ты не зюзюкай, ты рукой махни" (С)

CC>Сколько LOC у вас приходится на .h и на .cpp файлы?

Я на плюсах не пишу. Под рукой у меня исходников нет.

CC>Или у вас в .h шаблоны на шаблонах?


Достаточно классов с отдельными методами.

CC>Про PCH опять таки забыли.


И что, результат чтения PCH нам уже не надо хранить?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[9]: Закат GPU?
От: thesz Россия http://thesz.livejournal.com
Дата: 22.07.09 13:51
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, thesz, Вы писали:


T>>SHA-1 большого сообщения.

WH>Опять таки если не зацикливаться на конкретном алгоритме то см md6.

Вот ещё возражение против MD6: бОльший расход памяти по сравнению с обычными подсчётами контрольных сумм. У MD4/5/SHA он O(1), у MD6 он O(log(размер_сообщения)).

Не для всякого применения подойдёт, поскольку может не влезть в некоторые микроконтроллеры.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[10]: Закат GPU?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 23.07.09 06:36
Оценка:
Здравствуйте, thesz, Вы писали:

T>>>SHA-1 большого сообщения.

WH>>Опять таки если не зацикливаться на конкретном алгоритме то см md6.

T>Вот ещё возражение против MD6: бОльший расход памяти по сравнению с обычными подсчётами контрольных сумм. У MD4/5/SHA он O(1), у MD6 он O(log(размер_сообщения)).


Это не единственный вариант. Цитирую каноническое описание Ривеста (оно в википедии первой ссылкой):

Since the standard MD6 mode requires storage proportional to the height of the tree, there is an alternative low-storage variant mode obtained by adjusting the optional parameter L that decreases both the storage requirements and the parallelizability; setting L = 0 results in a Merkle-Damgard-like sequential mode of operation.


T>Не для всякого применения подойдёт, поскольку может не влезть в некоторые микроконтроллеры.


Для микроконтроллеров сделают реализацию при L == 0 и память будет требоваться линейно.
The God is real, unless declared integer.
Re[16]: а как же Larrabee?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 23.07.09 06:55
Оценка:
Здравствуйте, thesz, Вы писали:

CC>>Про PCH опять таки забыли.

T>И что, результат чтения PCH нам уже не надо хранить? ;)

Надо. Но в тех случаях, когда (по твоим формулам) V станет заметным (сотни, тысячи и больше), сработают два фактора:
1) (менее существенный) k за счёт предкомпиляции уменьшится на порядок или больше. в результате, омикрон-оценки потеряют смысл — они хороши только на асимптотике, с противоположного конца константы оказывают больше влияния.
2) (более существенный) сложность проекта будет заставлять разбивать его на отдельные части (библиотеки, плагины...), в результате получится что-то вроде v + k * V' + k * W, где V' — сколько осталось заголовков на часть, W — общих заголовков используемых других частей.

Практические способности человека заставляют поддерживать V на низком уровне (реально — не более сотни включаемых файлов среднего размера, 10-50K), иначе приближается путаница между включениями; её можно отодвинуть жесточайшей дисциплиной, но не устранить совсем.
The God is real, unless declared integer.
Re[11]: Закат GPU?
От: thesz Россия http://thesz.livejournal.com
Дата: 23.07.09 06:59
Оценка:
Здравствуйте, netch80, Вы писали:

N>Здравствуйте, thesz, Вы писали:


N>Это не единственный вариант. Цитирую каноническое описание Ривеста (оно в википедии первой ссылкой):


N>

N>Since the standard MD6 mode requires storage proportional to the height of the tree, there is an alternative low-storage variant mode obtained by adjusting the optional parameter L that decreases both the storage requirements and the parallelizability; setting L = 0 results in a Merkle-Damgard-like sequential mode of operation.


T>>Не для всякого применения подойдёт, поскольку может не влезть в некоторые микроконтроллеры.

N>Для микроконтроллеров сделают реализацию при L == 0 и память будет требоваться линейно.

То есть, микроконтроллеры будут понимать не все варианты входных потоков. Это усложняет жизнь, хотя и немного.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[12]: Закат GPU?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 23.07.09 07:00
Оценка:
Здравствуйте, thesz, Вы писали:

T>>>Не для всякого применения подойдёт, поскольку может не влезть в некоторые микроконтроллеры.

N>>Для микроконтроллеров сделают реализацию при L == 0 и память будет требоваться линейно.
T>То есть, микроконтроллеры будут понимать не все варианты входных потоков. Это усложняет жизнь, хотя и немного.

Этой реплики я не понял. Того, что они будут понимать входной поток данных как последовательность байт, вполне достаточно для вычисления хэша, пусть и чуть медленнее. Или ты о чём?
The God is real, unless declared integer.
Re[13]: Закат GPU?
От: thesz Россия http://thesz.livejournal.com
Дата: 23.07.09 08:40
Оценка:
Здравствуйте, netch80, Вы писали:

N>Здравствуйте, thesz, Вы писали:


T>>>>Не для всякого применения подойдёт, поскольку может не влезть в некоторые микроконтроллеры.

N>>>Для микроконтроллеров сделают реализацию при L == 0 и память будет требоваться линейно.
T>>То есть, микроконтроллеры будут понимать не все варианты входных потоков. Это усложняет жизнь, хотя и немного.

N>Этой реплики я не понял. Того, что они будут понимать входной поток данных как последовательность байт, вполне достаточно для вычисления хэша, пусть и чуть медленнее. Или ты о чём?


L — это параметр алгоритма. Вычисления по MD6-256-L0 не равны вычислениям MD6-256-L64.

У нас на одной из работ был криптомодуль собственной разработки на аналоге 8051. MD5 он умел, программной памяти хватало, а вот MD6-256-L64 он бы не смог.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[14]: Закат GPU?
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 23.07.09 10:14
Оценка:
Здравствуйте, thesz, Вы писали:

N>>>>Для микроконтроллеров сделают реализацию при L == 0 и память будет требоваться линейно.

T>>>То есть, микроконтроллеры будут понимать не все варианты входных потоков. Это усложняет жизнь, хотя и немного.
N>>Этой реплики я не понял. Того, что они будут понимать входной поток данных как последовательность байт, вполне достаточно для вычисления хэша, пусть и чуть медленнее. Или ты о чём?
T>L — это параметр алгоритма. Вычисления по MD6-256-L0 не равны вычислениям MD6-256-L64.

Таки да — есть подтверждение тому в тексте документа.

T>У нас на одной из работ был криптомодуль собственной разработки на аналоге 8051. MD5 он умел, программной памяти хватало, а вот MD6-256-L64 он бы не смог.


Ну, 8051 по нынешним меркам уже за гранью добра и зла.:) Хотя местами есть звери и послабее, но это уже в ситуации, где нормальную микруху вообще не поставишь.
The God is real, unless declared integer.
Re[15]: Закат GPU?
От: thesz Россия http://thesz.livejournal.com
Дата: 23.07.09 11:38
Оценка:
Здравствуйте, netch80, Вы писали:

N>Здравствуйте, thesz, Вы писали:


N>>>>>Для микроконтроллеров сделают реализацию при L == 0 и память будет требоваться линейно.

T>>>>То есть, микроконтроллеры будут понимать не все варианты входных потоков. Это усложняет жизнь, хотя и немного.
N>>>Этой реплики я не понял. Того, что они будут понимать входной поток данных как последовательность байт, вполне достаточно для вычисления хэша, пусть и чуть медленнее. Или ты о чём?
T>>L — это параметр алгоритма. Вычисления по MD6-256-L0 не равны вычислениям MD6-256-L64.

N>Таки да — есть подтверждение тому в тексте документа.


Да это следует из обычной логики. Равенство a+(b+(c+d)) и ((a+b)+(c+d)) ослабляет криптостойкость функция сжатия, как я понимаю.

T>>У нас на одной из работ был криптомодуль собственной разработки на аналоге 8051. MD5 он умел, программной памяти хватало, а вот MD6-256-L64 он бы не смог.


N>Ну, 8051 по нынешним меркам уже за гранью добра и зла. Хотя местами есть звери и послабее, но это уже в ситуации, где нормальную микруху вообще не поставишь.


Заметная часть AVR, MicroChip, ADSP21xx.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[4]: dmitriy_k
От: dmitriy_k  
Дата: 03.08.09 08:56
Оценка: -1
Здравствуйте, thesz, Вы писали:

T>>>На компиляции с помощью одного ядра современный Core 2 будет рвать Лараби, как Тузик грелку.

M>>Это очевидно, но в том то и дело что ядер будет много.
T>Если у нас 90% (обработка) может быть выполнено произвольно параллельно, а 10% (анализ) не может быть выполнено параллельно, то производительность упрётся в эти 10%. Тогда-то и вылезет ILP и out-of-order.
А вот тут могут уже всплыть алогоритмы которые мягко говоря неоэффиктивны последовательно, но если у нас _много_ процессоров — то могут дать лучщий эффект — не смотря на то что общие количество процессоро-часов — больше
dmitriy_k
Re[5]: dmitriy_k
От: thesz Россия http://thesz.livejournal.com
Дата: 03.08.09 12:42
Оценка:
Здравствуйте, dmitriy_k, Вы писали:

_>Здравствуйте, thesz, Вы писали:


T>>>>На компиляции с помощью одного ядра современный Core 2 будет рвать Лараби, как Тузик грелку.

M>>>Это очевидно, но в том то и дело что ядер будет много.
T>>Если у нас 90% (обработка) может быть выполнено произвольно параллельно, а 10% (анализ) не может быть выполнено параллельно, то производительность упрётся в эти 10%. Тогда-то и вылезет ILP и out-of-order.
_>А вот тут могут уже всплыть алогоритмы которые мягко говоря неоэффиктивны последовательно, но если у нас _много_ процессоров — то могут дать лучщий эффект — не смотря на то что общие количество процессоро-часов — больше

Это анализ, в отличии от обработки его параллелизм имеет гораздо меньшую гранулярность (ILP).

Потрудись в следующий раз читать то, на что отвечаешь.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[10]: а как же Larrabee?
От: Sinclair Россия https://github.com/evilguest/
Дата: 04.08.09 02:58
Оценка:
Здравствуйте, thesz, Вы писали:
T>Как обработка нескольких файлов сможет ускорить нам компиляцию нашего большого файла?
Очень просто. Типичный C++ исходник — это 95% заголовки, 5% собственно исходник.
В итоге, парсинг уникального для проекта кода занимает смешное, по сравнению с библиотечными заголовками, время. В частности, поэтому системы, в которых нет заголовков (pascal, java, C#) рвут плюсы по скорости компиляции в кровавые ошмётки.

Поэтому первая же идея, которая приходит в голову — скормить на вход компилятору несколько .cpp файлов — скорее всего, в них будут использоваться более-менее одни и те же хидеры, и на их повторном разборе можно очень сильно сэкономить. Вторая идея, которая приходит в голову — это реализовать предкомпилированные хидеры, но там есть несколько нюансов, из-за которых это сделать сложнее и дороже, чем повторное использование результатов разбора.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[4]: Закат GPU?
От: Lorenzo_LAMAS  
Дата: 05.08.09 09:08
Оценка:
GN>Да! Где же Duke Nukem Forever???

Пару месяцев назад окончательно R.I.P. вроде как.
Of course, the code must be complete enough to compile and link.
Re[5]: Закат GPU?
От: gear nuke  
Дата: 05.08.09 13:03
Оценка:
Здравствуйте, Lorenzo_LAMAS, Вы писали:

L_L>Пару месяцев назад окончательно R.I.P. вроде как.


А когда начинали, обещали к выпуску подходящего железа Не буду делать из этого каких-то выводов, просто ради факта — Manhattan Project зачем то релизился, хотя в планах вроде как и не было
.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Re[11]: а как же Larrabee?
От: Erop Россия  
Дата: 10.08.09 17:05
Оценка:
Здравствуйте, CreatorCray, Вы писали:

CC>Уточни пожалуйста, чтож это за проект такой, который состоит из одного файла исходников в метр толщиной.

Ну какой-нибудь генерённый код. Скажем у тебя есть какие-то данные, которые описывают структуру чего-то, а они компилируются в код, который эту структуру к чему-то как-то применяет...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[2]: а как же Larrabee?
От: Erop Россия  
Дата: 10.08.09 17:06
Оценка:
Здравствуйте, CreatorCray, Вы писали:

M>>а как же Larrabee?

CC>Он же вроде как еще не вышел.
CC>Выйдет — посмотрим.

В частности на пенальти, когда разные ядра лезут в одну и ту же память...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[5]: Закат GPU?
От: Erop Россия  
Дата: 10.08.09 17:27
Оценка:
Здравствуйте, Кэр, Вы писали:

Кэр>Смотря кому. Intel в плане разработки процессоров впереди планеты всей. Да возможно NVidia чтобы сделать когерентный кэш придется потратить очень хорошие деньги и ресурсы. И тратить потом хорошие деньги на каждую копию. Intel возможно сможет это делать гораздо дешевле.

Да это не важно. Просто так или иначе этой куче процов нужно будет как-то разделять шину данных, как-то поддерживать когерентным кэш и т. д. Так что, скорее всего, алгоритмы будут всё равно сильно очень ограниченны по паттернам доступа к ОЗУ. Так что не ясно будет ли большой бонус от "всеядности" процессоров. А вот пенальти будут значительные. Ясно что, CUDFовских ядер можно насажать за те же деньги намного больше...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[9]: Закат GPU?
От: Erop Россия  
Дата: 10.08.09 17:31
Оценка: -1
Здравствуйте, Кэр, Вы писали:

Кэр>Так CUDA — на самом деле это и есть большой шаг в сторону CPU на самом деле. Сейчас там много ограничений — subset of C — это на самом деле грустно. С++ выглядит здесь гораздо более внушительно.


То, что в CUDA такой убогий язык -- это всего лишь проблемы SDK, а не архитектуры. По существу CUDA не позволяет использовать указатели на функции (ну и виртуальные методы соответственно). Всё остальное С++ в принципе доступно, просто у них компилятор всё ещё убогий, но к аппаратной архитектуре это всё никакого отношения не имеет...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[12]: Закат GPU?
От: Erop Россия  
Дата: 10.08.09 17:34
Оценка:
Здравствуйте, thesz, Вы писали:

T>x86 в контексте Лараби СКОРЕЕ ВСЕГО означает очень низкую производительность.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[13]: Закат GPU?
От: thesz Россия http://thesz.livejournal.com
Дата: 11.08.09 09:05
Оценка:
Здравствуйте, Erop, Вы писали:

E>Здравствуйте, thesz, Вы писали:


T>>x86 в контексте Лараби СКОРЕЕ ВСЕГО означает очень низкую производительность.


Что сие означает?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[14]: Закат GPU?
От: Erop Россия  
Дата: 11.08.09 09:28
Оценка:
Здравствуйте, thesz, Вы писали:

T>>>x86 в контексте Лараби СКОРЕЕ ВСЕГО означает очень низкую производительность.

T>Что сие означает?

ЧТо кто его знает, какое оно будет? Или они уже зарелизили, а я просто не в курсе?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[13]: Закат GPU?
От: thesz Россия http://thesz.livejournal.com
Дата: 11.08.09 09:32
Оценка:
Здравствуйте, Erop, Вы писали:

E>Здравствуйте, thesz, Вы писали:


T>>x86 в контексте Лараби СКОРЕЕ ВСЕГО означает очень низкую производительность.


Уж коли встал, надо продолжить.

СКОРЕЕ ВСЕГО означает ОЧЕНЬ высокую вероятность.

Практически все команды x86 переводятся в несколько команд RISC стиля.

Если мы будем выполнять эти команды без требовательного к ресурсам чипа out-of-order, то у нас получится медленное выполнение, поскольку команды зависят одна от другой (add [ebx],eax раскладывается на MIPS-style load temp,[ebx]; add temp2,temp,eax; store temp2,[ebx], то же самое и для сопроцессора). OOO требует достаточно большой ассоциативной памяти, на всякий случай.

Мы можем выполнять примитивные команды в стиле Sun Niagara, это снизит ощущаемую процессором задержку выполнения, но это всё равно означает низкую производительность одного потока — вместо 1GHz получится исполнение на 500, 250 или 125MHz.

Поэтому на x86 не обойтись без OOO для получения высокой однопоточной производительности.

А где OOO, там меньше ядер. Один декодер x87 в RISC чего стоит — он занимает чуть ли не половину площади кристалла, отпущенную под процессор, судя по фотографиям. Тогда, как просто 64-бит FPU без регистров должен занимать на 0.13u всего порядка 0.5кв.мм.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[15]: Закат GPU?
От: thesz Россия http://thesz.livejournal.com
Дата: 11.08.09 09:32
Оценка:
Здравствуйте, Erop, Вы писали:

E>Здравствуйте, thesz, Вы писали:


T>>>>x86 в контексте Лараби СКОРЕЕ ВСЕГО означает очень низкую производительность.

T>>Что сие означает?

E>ЧТо кто его знает, какое оно будет? Или они уже зарелизили, а я просто не в курсе?


Это следует из обычных несложных прикидок.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[16]: Закат GPU?
От: Erop Россия  
Дата: 11.08.09 09:34
Оценка: +1
Здравствуйте, thesz, Вы писали:

T>>>>>x86 в контексте Лараби СКОРЕЕ ВСЕГО означает очень низкую производительность.

T>>>Что сие означает?
E>>ЧТо кто его знает, какое оно будет? Или они уже зарелизили, а я просто не в курсе?
T>Это следует из обычных несложных прикидок.

Из обычных прикидок, тем более несложных, может следовать только в модальности "скорее всего"...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[17]: Закат GPU?
От: thesz Россия http://thesz.livejournal.com
Дата: 11.08.09 10:07
Оценка:
Здравствуйте, Erop, Вы писали:

E>Здравствуйте, thesz, Вы писали:


T>>>>>>x86 в контексте Лараби СКОРЕЕ ВСЕГО означает очень низкую производительность.

T>>>>Что сие означает?
E>>>ЧТо кто его знает, какое оно будет? Или они уже зарелизили, а я просто не в курсе?
T>>Это следует из обычных несложных прикидок.

E>Из обычных прикидок, тем более несложных, может следовать только в модальности "скорее всего"...


По соображениям, изложенным рядом, тебе сказать нечего?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[10]: Закат GPU?
От: CreatorCray  
Дата: 11.08.09 12:07
Оценка:
Здравствуйте, Erop, Вы писали:

E>То, что в CUDA такой убогий язык -- это всего лишь проблемы SDK, а не архитектуры. По существу CUDA не позволяет использовать указатели на функции (ну и виртуальные методы соответственно). Всё остальное С++ в принципе доступно, просто у них компилятор всё ещё убогий, но к аппаратной архитектуре это всё никакого отношения не имеет...

Еще как имеет. Железо затачивалось под игровые цели, и эти заточки вытарчивают даже в тесле.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[18]: Закат GPU?
От: Erop Россия  
Дата: 11.08.09 12:44
Оценка:
Здравствуйте, thesz, Вы писали:

T>По соображениям, изложенным рядом, тебе сказать нечего?

Ну в Интел же не дураки сидят? Зачем-то же они за этот проект взялись? Наверное есть какие-то ходы неочевидные...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[11]: Закат GPU?
От: Erop Россия  
Дата: 11.08.09 12:46
Оценка:
Здравствуйте, CreatorCray, Вы писали:

CC>Еще как имеет. Железо затачивалось под игровые цели, и эти заточки вытарчивают даже в тесле.

Ну и что из С++, кроме указателей на функции нельзя сделать на КУДЕ аппаратно? Кое-что будет медленно (если ветвиться программа будет много и по разному в разных ядрах), но чтобы совсем нельзя, вроде бы нет ничего...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[19]: Закат GPU?
От: thesz Россия http://thesz.livejournal.com
Дата: 11.08.09 14:55
Оценка:
Здравствуйте, Erop, Вы писали:

E>Здравствуйте, thesz, Вы писали:


T>>По соображениям, изложенным рядом, тебе сказать нечего?

E>Ну в Интел же не дураки сидят? Зачем-то же они за этот проект взялись? Наверное есть какие-то ходы неочевидные...

GPU не проводит анализа. Он работает только на обработке. Larabee же типичный GPU, x86 там стоит только в качестве маркетингового хода и, получается из анализа, бесполезен.

А на обработке более широкая шина (8*single float SIMD)может многое дать.

Хотя я всё равно сомневаюсь насчёт пользы широкой шины.

Большая часть операций в GPU трехмерные и ещё много скалярных. Поэтому на предыдущем поколении стояли 2xSIMD, что позволяло лучше утилизировать площадь: скалярная операция занимала всего 2 слота SIMD вместо 4 на SSE. На другие 2 можно было что-то запихнуть в параллель со скалярной операцией (SSE не даёт использовать оставшиеся три пути, если работаешь со скаляром в регистре).

Насчёт "не дураков в Интеле" напомню про проблемы длинного конвейера в P4.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[12]: Закат GPU?
От: CreatorCray  
Дата: 12.08.09 13:39
Оценка:
Здравствуйте, Erop, Вы писали:

CC>>Еще как имеет. Железо затачивалось под игровые цели, и эти заточки вытарчивают даже в тесле.

E>Ну и что из С++, кроме указателей на функции нельзя сделать на КУДЕ аппаратно? Кое-что будет медленно (если ветвиться программа будет много и по разному в разных ядрах), но чтобы совсем нельзя, вроде бы нет ничего...
Например там нельзя никак сделать полноценную рекурсию, т.к. нету стека

железо ж изначально затачивалось под конкретные задачи растеризации графики.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[13]: Закат GPU?
От: Erop Россия  
Дата: 12.08.09 14:13
Оценка:
Здравствуйте, CreatorCray, Вы писали:

CC>Например там нельзя никак сделать полноценную рекурсию, т.к. нету стека

Ну и фиг с ней. Кому она нужна на тех задачах? Там вообще ветвиться сильно стрёмно...

CC>железо ж изначально затачивалось под конкретные задачи растеризации графики.

Ну там ограничения внеязыковой характер носят. Скорее некоторые алгоритмы запрещены, чем какие-то С++ конструкции...

Короче, убогость КУДАшного языка -- это именно убогость языка. То, что железо имеет некоторые ограничения -- это плата за то, что оно дешёвое, и при этом может таки обеспечить массовую параллельность. А убогость SDK -- это просто так, убогость SDK без всякого доп. смысла...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[14]: Закат GPU?
От: CreatorCray  
Дата: 12.08.09 14:42
Оценка:
Здравствуйте, Erop, Вы писали:

CC>>Например там нельзя никак сделать полноценную рекурсию, т.к. нету стека

E>Ну и фиг с ней. Кому она нужна на тех задачах? Там вообще ветвиться сильно стрёмно...
Ну ну. И ты еще про какие то С++ фичи речь ведешь?

CC>>железо ж изначально затачивалось под конкретные задачи растеризации графики.

E>Ну там ограничения внеязыковой характер носят. Скорее некоторые алгоритмы запрещены, чем какие-то С++ конструкции...
Ты вообще с их железом сталкивался? Представление имеешь как именно оно устроено и работает?

E>Короче, убогость КУДАшного языка -- это именно убогость языка.

Убогость языка обусловлена возможностями железа.
А так под куду хоть на их асме пиши — вот уж где весь доступ к потенциалу железяки.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[15]: Закат GPU?
От: Erop Россия  
Дата: 12.08.09 15:42
Оценка:
Здравствуйте, CreatorCray, Вы писали:

CC>Ну ну. И ты еще про какие то С++ фичи речь ведешь?

А в чём проблемы? Запрет ветвиться -- это ограничение на алгоритм, а не на язык...

CC>Ты вообще с их железом сталкивался? Представление имеешь как именно оно устроено и работает?

Да, сталкивался и знаком. Правда в том SDK, с которым сталкивался я ещё не было и шаблонов. Просто какой-то кусок С своеобразный.
Но убогость того копмилятора ни с чем не была связана. Например никто не мешает иметь внутри КУДЫ класс вроде CComplex, скажем. Но убогое SDK не даёт.

E>>Короче, убогость КУДАшного языка -- это именно убогость языка.

CC>Убогость языка обусловлена возможностями железа.
CC>А так под куду хоть на их асме пиши — вот уж где весь доступ к потенциалу железяки.

Да ладно. Например в том SDK, с которым я имел дело, не знаю, модет с тех пор что-то пофиксили, нельзя было пользоваться строгой типизацией, например. При чём тут возможности железа?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[14]: Закат GPU?
От: thesz Россия http://thesz.livejournal.com
Дата: 12.08.09 19:23
Оценка:
Здравствуйте, Erop, Вы писали:

E>Здравствуйте, CreatorCray, Вы писали:


CC>>Например там нельзя никак сделать полноценную рекурсию, т.к. нету стека

E>Ну и фиг с ней. Кому она нужна на тех задачах? Там вообще ветвиться сильно стрёмно...

Трассировка лучей.

Глобальное освещение.

CC>>железо ж изначально затачивалось под конкретные задачи растеризации графики.

E>Ну там ограничения внеязыковой характер носят. Скорее некоторые алгоритмы запрещены, чем какие-то С++ конструкции...

Запрещены интересные алгоритмы.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[15]: Закат GPU?
От: Cyberax Марс  
Дата: 12.08.09 19:25
Оценка:
Здравствуйте, thesz, Вы писали:

E>>Ну и фиг с ней. Кому она нужна на тех задачах? Там вообще ветвиться сильно стрёмно...

T>Трассировка лучей.
NVidia таки выпустила какой-то SDK с трассировкой. Значит, как-то забороли.
Sapienti sat!
Re[15]: Закат GPU?
От: Erop Россия  
Дата: 12.08.09 19:53
Оценка:
Здравствуйте, thesz, Вы писали:

T>Трассировка лучей.

T>Глобальное освещение.
T>Запрещены интересные алгоритмы.

Это всё никак не специфично для С++
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re: Закат GPU?
От: Andrei F.  
Дата: 01.10.09 13:33
Оценка: 7 (1)
Здравствуйте, Кэр, Вы писали:

Кэр>В связи с тем, что не за горами CPU с 128 и более ядрами — вопрос, а нужны ли тогда будут GPU? Основная фича GPU — их много. Они тупые, умеют считать только шейдеры, но их много и обработка шейдеров хорошо параллелиться. Однако, существует целый паравоз проблем из-за того, что мы имеем отдельный вид процессоров: отдельная память, отдельные инструкции, просто отдельный вид ассемблерных инструкций.

Кэр>Так что закономерный вопрос: когда CPU тоже станет очень много — не проще ли будет гонять графику прямо на CPU. Какие причины будут содержать GPU в комплекте? Не пора ли NVidia сворачивать бизнес?

Нет особой разницы какой там набор инструкций, если программист пишет на языке высокого уровня.
А тем временем, nVidia заявляет в своей новой видеокарте поддержку С++ http://www.geeks3d.com/20090930/nvidia-gt300-has-512-cores-and-supports-c/
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re: more and more cores!
От: Golovach Ivan Украина http://kharkovitcourses.blogspot.com
Дата: 12.11.09 22:07
Оценка:
Здравствуйте, Кэр, Вы писали:

Кэр>В связи с тем, что не за горами CPU с 128 и более ядрами — вопрос, а нужны ли тогда будут GPU? Основная фича GPU — их много. Они тупые, умеют считать только шейдеры, но их много и обработка шейдеров хорошо параллелиться. Однако, существует целый паравоз проблем из-за того, что мы имеем отдельный вид процессоров: отдельная память, отдельные инструкции, просто отдельный вид ассемблерных инструкций.

Кэр>Так что закономерный вопрос: когда CPU тоже станет очень много — не проще ли будет гонять графику прямо на CPU. Какие причины будут содержать GPU в комплекте? Не пора ли NVidia сворачивать бизнес?

Radeon HD 5900: оружие против Fermi выйдет в конце ноября — http://kharkovconcurrencygroup.blogspot.com/2009/10/radeon-hd-5900-fermi.html
Собственно "Radeon HD 5900: оружие против Fermi выйдет в конце ноября". — http://www.3dnews.ru/news/radeon_hd_5900_oruzhie_protiv_fermi_viidet_v_kontse_noyabrya/
Цитаты:
"Поскольку ускорители Radeon HD 5950 и HD 5970 по сути являются сдвоенными версиями Radeon HD 5850 и HD 5870, логично предположить, что в распоряжении первого имеется 2880 универсальных потоковых процессоров, в распоряжении второго — 3200."
Похоже, Radeon-ATI-AMD пока ставят на кол-во процессоров, а не на распространение среди разработчиков (как CUDA-Fermi-nVidia(http://www.nvidia.com/object/fermi_architecture.html)). Хотя OpenCL уже поддерживают.
P.S. Ощущение, что настольные системы буквально "мгновенно" проскочат 1TFlop и приблизятся к 1PetaFlop (10^15 FLoating-point OPerations per second).
P.P.S. Ведь Radeon использует CrossFire(http://en.wikipedia.org/wiki/ATI_CrossFire), следовательно их можно вставлять по 4 в материнку, следовательно — !!!12.800!!! потоковых ядер в системе.
-----
у ATI — 12.800 будет в течении 1-2 лет
у Intel с ее Terraflop Research Chip будет 80 ядер лет через 3-4
как бы 2 порядка.
concurrency многопоточность
Re[2]: more and more cores!
От: Silver_s Ниоткуда  
Дата: 25.11.09 16:24
Оценка: +3
Здравствуйте, Golovach Ivan, Вы писали:
GI>Похоже, Radeon-ATI-AMD пока ставят на кол-во процессоров, а не на распространение среди разработчиков (как CUDA-Fermi-nVidia(http://www.nvidia.com/object/fermi_architecture.html)). Хотя OpenCL уже поддерживают.

Они Bulldozer делают. Обещают что когда сделают в 2011, мало не покажется. В одном кристалле, и GPU и CPU без медленной шины.

В ближайшие 3-4 года скорее всего бардак будет с паралельными вычислениями на настольных ПК. Потом какой нибудь стандарт примут.
Тут главное не сколько процессоров и не на каком языке программы писать (Cuda,c++,..). А какая архитектура окажется оптимальнее для каких задач. Пока все планируют разное(AMD,NVidia,Intel)
Сейчас даже на 2-4 ядрах не так то просто соптимизировать.
Re[9]: Закат GPU?
От: Turyst  
Дата: 25.11.09 16:30
Оценка: -1
Здравствуйте, thesz, Вы писали:

T>Здравствуйте, Ikemefula, Вы писали:


I>>Здравствуйте, thesz, Вы писали:


I>>>>>>Обработка графической информации.

T>>>>>А на физике? Хотя бы игровой. Там оно как?
I>>>>Понемногу осваивается. Кроме того, есть GPGPU которая помогает ускорять многие вещи и разгрузить CPU.

T>>>И какие же вещи они, эти магические GPU, ускоряют?

I>>Это не магические GPU. Это обычные специализированые процессоры.

T>И какие же вещи они, эти магические обычные специализированные процессоры, ускоряют?


I>>http://www.gpgpu.ru/


T>Перечисли, пожалуйста. А то я не понимаю, что ускоряется с помощью CUDA, а что с помощью OpenCL.


I>>>>>>GPU не избавляют от необходимости иметь супер-компьютеры.

T>>>>>А почему?
I>>>>Потому что задачи и требования другие.
T>>>И какие же?
I>>В основном моделирование различных процессов, мега-вычисления различные
I>>при чем, кстати говоря!, многие суперкомпьютеры построены на GPU, которыми управляют обычные СPU.

T>Как много таких в Top500?


I>>В итоге можно в системе размером с настольный ПК выжать производительность минимум на порядок и даже два выше обычного ПК такого же размера.


T>На каких задачах? С числами какой точности?


PhysX как раз щитает на GPU если есть возможность.
Re[8]: Закат GPU?
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 25.11.09 17:27
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, WinterMute, Вы писали:


WM>>Первое что приходит на ум: поиск в отсортированнном массиве. Не такая уж редкая задача.

WH>1)"поиск в отсортированном массиве" это как правило часть конкретного решения конкретной задачи.
WH>2)Параллелить операцию со сложностью O(Log(N)) мягко говоря мало смысла в любом случае.

Эх... Вот только в нашей жизни конкретная задача как раз и состоит в том, чтобы взять значение, найти его в одном массиве, потом найденное поискать в другом, если не нашли, то добавить...

Ну а так все параллелится, но зачастую это отдельная задача, которую надо решать... Например, архивация. Да, можно брать разные куски исходных данных, но это надо модифицировать исходный алгоритм + следить за тем, чтобы куски были записаны на диск в правильной последовательности. Шифрование...
Re[6]: Закат GPU?
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 25.11.09 17:33
Оценка: -1
Здравствуйте, minorlogic, Вы писали:

M>Я не продемонстрирую с силу банального незнания. Но какой из этого можно сделать вывод? Да никакой ..


Вывод сделать просто: распараллелить не просто. Потому как твоих знаний достаточно только для того, чтобы реализовать однопоточный вариант. А вот в случае многопоточного возникает банальное незнание: надо читать литературу, не всякий в ней разберется. А это время/деньги... И вечный вопрос "нафига"?
Re[4]: Закат GPU?
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 25.11.09 17:47
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, CreatorCray, Вы писали:


CC>>Может зададимся вопросом: а так ли много есть алгоритмов, которые эффективно параллелятся?

WH>Лучше так: Много ли есть задач для которых нет эффективных параллельных алгоритмов?

Проблема в том, что придумывать и реализовывать эти такие эффективные параллельные алгоритмы в общем случае геморнее. А задачи всякие раз стоят уникальные.
Re: Закат GPU?
От: FR  
Дата: 08.12.09 09:32
Оценка:
Здравствуйте, Кэр, Вы писали:

Кэр>Так что закономерный вопрос: когда CPU тоже станет очень много — не проще ли будет гонять графику прямо на CPU. Какие причины будут содержать GPU в комплекте? Не пора ли NVidia сворачивать бизнес?


Что-то у интела похоже даже и отдельный GPU не получается http://cnews.ru/news/top/index.shtml?2009/12/08/372464#top_static
Re[2]: Закат GPU?
От: Aleх  
Дата: 08.12.09 22:32
Оценка:
Здравствуйте, FR, Вы писали:

FR>Здравствуйте, Кэр, Вы писали:


Кэр>>Так что закономерный вопрос: когда CPU тоже станет очень много — не проще ли будет гонять графику прямо на CPU. Какие причины будут содержать GPU в комплекте? Не пора ли NVidia сворачивать бизнес?


FR>Что-то у интела похоже даже и отдельный GPU не получается http://cnews.ru/news/top/index.shtml?2009/12/08/372464#top_static


Жалко. Только вот там написано:

По-видимому, Intel поняла, что Larrabee в его текущем состоянии не является конкурентоспособным продуктом. За несколько дней до сентябрьской конференции IDF компания AMD представила графический процессор Radeon HD 5870 с вычислительной мощностью около 3 терафлопс, а затем – Radeon HD 5970, мощность которого составила более 5 терафлопс. Рабочий образец Larrabee имел мощность 1 терафлопс, в проекте компании было увеличение мощности в два раза.

Не пойму, чего все так гонятся за этими терафлопсами? Они являются не единственной характеристикой процессора. Если я хочу запускать алгоритмы на графах, нафига мне флопсы вообще?
Re[3]: Закат GPU?
От: FR  
Дата: 09.12.09 05:12
Оценка:
Здравствуйте, Aleх, Вы писали:

A>Не пойму, чего все так гонятся за этими терафлопсами? Они являются не единственной характеристикой процессора. Если я хочу запускать алгоритмы на графах, нафига мне флопсы вообще?


Если характеристики опытного образца в несколько раз хуже чем у серийных образцов конкурентов, на рынке ловить нечего, разве что демпинговать или искать узкие ниши, ни то ни другое не в привычках интела
Re[3]: Закат GPU?
От: CreatorCray  
Дата: 10.12.09 14:52
Оценка:
Здравствуйте, Aleх, Вы писали:

A>Не пойму, чего все так гонятся за этими терафлопсами? Они являются не единственной характеристикой процессора. Если я хочу запускать алгоритмы на графах, нафига мне флопсы вообще?

Надо полагать тебе надо все таки быстрые алгоритмы.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.