Здравствуйте, gear nuke, Вы писали:
GN>Да знаю я это... А что толку? Появился Turok — был качественный прорыв в графике, а дальше только количественные (т.к. разрешения мониторов расли...). До Турка был еще прорыв — Alone in the Dark, в какой-то части построили модели из сфер. Так что Турок в какой-то мере шаг назад.
Ты что, со времен Турка вообще ни во что не играл?
Здравствуйте, Andrei F., Вы писали:
AF>4-ядерники в массовой продаже уже несколько лет, а программ которые могут использовать столько ядер — можно на пальцах пересчитать. И выигрыш они дают далеко не 4-кратный.
Может зададимся вопросом: а так ли много есть алгоритмов, которые эффективно параллелятся?
Здравствуйте, CreatorCray, Вы писали:
CC>Может зададимся вопросом: а так ли много есть алгоритмов, которые эффективно параллелятся?
Лучше так: Много ли есть задач для которых нет эффективных параллельных алгоритмов?
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
CC>>Может зададимся вопросом: а так ли много есть алгоритмов, которые эффективно параллелятся? WH>Лучше так: Много ли есть задач для которых нет эффективных параллельных алгоритмов?
"Ты не поверишь!" (С)
Здравствуйте, CreatorCray, Вы писали:
WH>>Лучше так: Много ли есть задач для которых нет эффективных параллельных алгоритмов? CC>"Ты не поверишь!" (С)
Огласите весь список пожалуйста.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, 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)
Здравствуйте, Кэр, Вы писали:
Кэр>В связи с тем, что не за горами CPU с 128 и более ядрами — вопрос, а нужны ли тогда будут GPU? Основная фича GPU — их много. Они тупые, умеют считать только шейдеры, но их много и обработка шейдеров хорошо параллелиться. Однако, существует целый паравоз проблем из-за того, что мы имеем отдельный вид процессоров: отдельная память, отдельные инструкции, просто отдельный вид ассемблерных инструкций. Кэр>Так что закономерный вопрос: когда CPU тоже станет очень много — не проще ли будет гонять графику прямо на CPU. Какие причины будут содержать GPU в комплекте? Не пора ли NVidia сворачивать бизнес?
Я имею некоторый опыт в области gpgpu, видахи быстры только когда можно использовать принцип shared nothing, паралельное выполнение нескольких шейдеров(даже ветвлений одного для разных групп потоков) возможно только на разных SIMD блоках чаще всего. Моё мнение 128 ядерный проц не заменит 1000 ядерную видах)))))) Его просто удобнее программировать, некоторые задачи на видахи не ложаться, даже казалось бы паралельные ( при обработке нейросети нужно пересчитывать веса для связей — там очень большое количество обращений к оператве — плохое соотношение инструкций разных типов, выполняется медленно, кеш не спасает — спасло бы выполнение двух шейдеров на одном симд блоке, но это требует усложнения железа).
Выйдет лараби — там будет возможность стартовать новые потоки прямо на видахе, и вот как раз для него может появится killer app.
Здравствуйте, Andrei F., Вы писали:
AF>Здравствуйте, любой, Вы писали:
Л>>А следовало бы не иметь разделения на процессор и память вообще. Т. е. выполнять операции с числами должна сама память. Разумеется, с возможностью параллелизма на всю свою ёмкость. Также, она должна программироваться на создание определённой структуры передачи и обработки потоков информации.
AF>То, что ты описываешь — это перепрограммируемый систолический массив. Используется кое-где для высокопроизводительных вычислений, и вообще идея очень правильная. Но чтобы пустить это в масовое использование, придется переучивать всех программистов, преодолевая ожесточенное сопротивление AF>Это ведь не мелкий шажок вроде ФП, управляемого кода или синтаксических макросов, вокруг которых столько копий сломали (и до сих пор ломают). Это совершенно другая архитектура, не фон-Неймановская. И совершенно другой подход к программированию. Кайрофобы затопчут нафиг
Боюсь это throughput computing — на него ложатся далеко не все алгоритмы, в любом случае получается очень похоже на нейрочипы — они очень сложные в схемотехнике. Видахи на это похожи слабо, разделение на проц и память там чёткое, кто не верит — читайте доки по gpgpu.
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:
Larrabee will use the x86 instruction set with Larrabee-specific extensions.
Larrabee will feature cache coherency across all its cores.
Larrabee will include very little specialized graphics hardware, instead performing tasks like z-buffering, clipping, and blending in software, using a tile-based rendering approach.
Подход "простой софт, сложная hardware" всегда заруливал подход "сложный софт, простая hardware". "Простой софт" очень хорошо масштабируется. Возможность исполнять x86 инструкции прямо на GPU и когерентность кэша, например, означает что возможно применять кастомную обработку к данным посланным на графическую обработку без потери в скорости — данные уже на шине — т.е. софт который посылает графические данные на обработку может быть изрядно тупее, чем он есть сейчас. Что можно будет делать в таком случае — писать ray tracing к примеру на C# LINQ и относительно просто компилировать это все в команды Larrabee.
Это также означает, что новые фишки типа каких-нибудь новых шейдеров — возможно будут выпускаться просто как алгоритмические решения на обычном наборе ассемблерных инструкций. Не будет необходимости менять железо только чтобы получить эти шейдеры. Это очень круто.
Здравствуйте, Andrei F., Вы писали:
AF>То, что ты описываешь — это перепрограммируемый систолический массив. Используется кое-где для высокопроизводительных вычислений, и вообще идея очень правильная. Но чтобы пустить это в масовое использование, придется переучивать всех программистов, преодолевая ожесточенное сопротивление
Всё, к чему привыкли кодеры, можно съэмулировать. Другое дело, что "правильность идей" бизнесменов не вдохновляет. Им важна лишь сиеминутная прибыль. Удивительно, но не потребности науки, медицины, военных, а развлечения подростков стали стимулом для создания мощных GPU и физических процессоров.
AF>Это ведь не мелкий шажок вроде ФП, управляемого кода или синтаксических макросов, вокруг которых столько копий сломали (и до сих пор ломают). Это совершенно другая архитектура, не фон-Неймановская. И совершенно другой подход к программированию. Кайрофобы затопчут нафиг
Те, кто трассировщики лучей пишут и всякие ядрёные взрывы моделируют, будут только за. А прочих никто не заставляет вникать.
Здравствуйте, любой, Вы писали:
AF>>То, что ты описываешь — это перепрограммируемый систолический массив. Используется кое-где для высокопроизводительных вычислений, и вообще идея очень правильная. Но чтобы пустить это в масовое использование, придется переучивать всех программистов, преодолевая ожесточенное сопротивление Л>Всё, к чему привыкли кодеры, можно съэмулировать. Другое дело, что "правильность идей" бизнесменов не вдохновляет. Им важна лишь сиеминутная прибыль. Удивительно, но не потребности науки, медицины, военных, а развлечения подростков стали стимулом для создания мощных GPU и физических процессоров.
Платежеспособный спрос. Кто-то же должен был оплатить все это.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, Andrei F., Вы писали:
AF>>4-ядерники в массовой продаже уже несколько лет, а программ которые могут использовать столько ядер — можно на пальцах пересчитать. И выигрыш они дают далеко не 4-кратный. CC>Может зададимся вопросом: а так ли много есть алгоритмов, которые эффективно параллелятся?
Здравствуйте, minorlogic, Вы писали: M>Думаю что большая часть.
Хм. Насколько я помню, первый алгоритм, который я изучил, был алгоритм Евклида — который нахождения наибольшего общего делителя.
Можно мне продемонстрировать высокопараллельный его вариант? Для, скажем, сверхбольших чисел — чтобы параллелизм стал оправдан.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Кэр, Вы писали:
Кэр>В связи с тем, что не за горами CPU с 128 и более ядрами — вопрос, а нужны ли тогда будут GPU? Основная фича GPU — их много. Они тупые, умеют считать только шейдеры, но их много и обработка шейдеров хорошо параллелиться. Однако, существует целый паравоз проблем из-за того, что мы имеем отдельный вид процессоров: отдельная память, отдельные инструкции, просто отдельный вид ассемблерных инструкций. Кэр>Так что закономерный вопрос: когда CPU тоже станет очень много — не проще ли будет гонять графику прямо на CPU. Какие причины будут содержать GPU в комплекте? Не пора ли NVidia сворачивать бизнес?
Без шансов, у GPU есть объективные преимущества, которые позволяют на определенном классе алгоритмов давать существенный прирост производительности. И если сделают 128-ядерный CPU, то можно сделать и какой-нибудь 16384-ядерный GPU.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, minorlogic, Вы писали: M>>Думаю что большая часть. S>Хм. Насколько я помню, первый алгоритм, который я изучил, был алгоритм Евклида — который нахождения наибольшего общего делителя. S>Можно мне продемонстрировать высокопараллельный его вариант? Для, скажем, сверхбольших чисел — чтобы параллелизм стал оправдан.
Я не продемонстрирую с силу банального незнания. Но какой из этого можно сделать вывод? Да никакой ..
