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

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

Потому что GPU узкозаточенные под одну задачу. А ПЛИС - пустые, и на них можно сделать любую специализированную микросхему. Тактовая частота у ПЛС, конечно, меньше на порядок, чем у bare hardware микросхемы, но при массивных вычислениях это не особая проблема, т.к. и ПЛИС, и процессор солидную часть времени будут висеть в ожидании памяти.

> т.к. и ПЛИС, и процессор солидную часть времени будут висеть в ожидании памяти.

Воот. А мы научились делать так, что проц (для определенного класса задач) не висит в ожидании памяти. И где тогда будут ПЛИС?

Воот. А мы научились делать так, что проц (для определенного класса задач) не висит в ожидании памяти.

Да всегда он висит. Даже доступ в L1 небесплатный.

И где тогда будут ПЛИС?

У ПЛИС несколько сотен тысяч регистров с нулевой латентностью. У x86-64 - только 16, часть из которых по факту недоступна пользователю.

от "масс":

> Даже доступ в L1 небесплатный.

обычно --- бесплатный. ILP + OoO рулят

У x86-64 - только 16

Зачем же так передергивать? у процессоров с ISA x86-64 --- за тысячу аппаратных регистров. причем данные в основном в SSE/AVX регистрах хранятся, а те самые 16 РОН в основном нужны для доступа к L1, т.е. в данном контексте (бесплатного доступа) --- десятки килобайт на ядро, которых самих по себе до десятка уже.

Кроче, потыкавшись в список Altera я не нашел ни одного достойного противника в вычислениях не то что GPU, но даже и самым банальным x86-шкам

например: Cyclone IV GX EP4CGX150DF31 Device Features

360шт 18x18 умножителей. Ну дык в дешевеньком core i5 16шт 64x64 умножителей (и это не считая ALU/AGU), что эквивалентно, насколько я понимаю, 256шт 18x18, причем частота их работы раз в 10-100 больше...

> Да всегда он висит.

ну приводил же уже в этом треде www.linux.org.ru/wiki/en/User:AIv/LRnLA

Наши числодробилки работают с эффективностью 50% от теоретически возможной на задачах с размером больше RAM (обычные с эффективностью меньше 5% на задачах меньших RAM и встают колом если задача в RAM не влезает).

Даже если ПЛИС выдаст 100% (что невозможно, поскольку не только в память все упирается - есть условия приводящие к нарушение конвейризации и тд, тут идеал недостижим), для обоснования их использования, нужно что бы у них флопосов было не меньше чем у CPU, и даже при этом они не дадут существенного выигрыша. Занавес.

ну приводил же уже в этом треде www.linux.org.ru/wiki/en/User:AIv/LRnLA

Как это относится к тому факту, что доступ в L1 у Sandy Bridge - 4 такта, у C2D - 3, а у AMD вообще непонятная порнография с кучей условий и ограничений?

Даже если ПЛИС выдаст 100% (что невозможно, поскольку не только в память все упирается - есть условия приводящие к нарушение конвейризации и тд, тут идеал недостижим)

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

для обоснования их использования, нужно что бы у них флопосов было не меньше чем у CPU, и даже при этом они не дадут существенного выигрыша. Занавес.

Опять же, при чём здесь плавающие числа? Во сколько-нибудь точных вычислениях никаких флоатов нет и быть не может.

> Опять же, при чём здесь плавающие числа? Во сколько-нибудь точных вычислениях никаких флоатов нет и быть не может.

Мы не бухгалтерией занимаемся, у нас тока флоты, реже даблы. Еще раз. Вы агитируете за использование ПЛИС в числ моделировании, и постулируете что ПЛИC даст существенный выигрыш в производительности. Ок, вот конкретная задача, моделирование синтетических сейсмограмм. Есть решение на CPU, область в 1024^3 ячеек, по 6 флотов в ячейке, по одному сложению и одному умножению на флот за шаг (на самом деле чуть больше), 2048 шагов на весьма средней по нынешним временам персоналке c 4х ядерным CPU считается сутки. Нетрудно оценить, что это 50% от макс возможной скорости CPU вообще (как если бы он считал какую нить фигню вообще в RAM не обращаясь).

Вопрос - сколько такая задача будет считаться на ПЛИС эквивалентной стоимости, даже если все потоки идеально спроектированы и нигде нет никакого затыка?

Как это относится к тому факту, что доступ в L1 у Sandy Bridge - 4 такта, у C2D - 3, а у AMD вообще непонятная порнография с кучей условий и ограничений?

Какая разница, насколько криво сделана подсистема памяти у совр CPU если мы можем писать код к-й с ней без потерь взаимодействует? Вам надо решение с идеальным доступом, или решение считающее задачу за мин время?

обычно --- бесплатный. ILP + OoO рулят

Документация с сайта intel.com говорит, что небесплатно. Ты считаешь, что Интел заблуждается?

Зачем же так передергивать? у процессоров с ISA x86-64 --- за тысячу аппаратных регистров. причем данные в основном в SSE/AVX регистрах хранятся, а те самые 16 РОН в основном нужны для доступа к L1,

«Тысячи аппаратных регистров» пользователю (программисту/компилятору) не видны. Ему видно, что регистров, с которыми он может манипулировать, мало, и нужно постоянно делать оффлоад в память. Процессор может делать махинации с оффлоадами, но у него есть определённые обязательства по завершению операций с памятью, которые махинации часто накрывают медным тазом.

На векторных расширениях писать неудобно, ибо поддерживаемый набор инструкций крайне куцый.

например: Cyclone IV GX EP4CGX150DF31 Device Features

360шт 18x18 умножителей. Ну дык в дешевеньком core i5 16шт 64x64 умножителей (и это не считая ALU/AGU), что эквивалентно, насколько я понимаю, 256шт 18x18, причем частота их работы раз в 10-100 больше...

Up to 150k логических элементов (ALM). В FPGA постарше их 360k.

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

Вы вообще знаете, что кроме проблем с потоками данных есть еще 100500 факторов замедляющих счет?

Как это относится к тому факту, что доступ в L1 у Sandy Bridge - 4 такта, у C2D - 3, а у AMD вообще непонятная порнография с кучей условий и ограничений?

как уже было сказано --- это латентность. А темп --- по два-три 128бит обмена за такт, чего обычно вполне достаточно для полной загрузки всех имеющихся функциональных устройств. Латентность же скрывается за счет внеочередного исполнения команд. В GPU вон даже латентность доступа в память по пол-микросекунды скрывается. В результате --- доступ именно что «бесплатен»

при чём здесь плавающие числа?

Ну вот с этого и надо было начинать, советуя FPGA в теме про вычисления.

Во сколько-нибудь точных вычислениях никаких флоатов нет и быть не может

«сколько-нибудь» --- это занятная характеристика «точных вычислений» :) Приведите пример.

Мы не бухгалтерией занимаемся, у нас тока флоты, реже даблы.

А кто занимается? У нас хоть большой iptables можно делать, хоть детектор запуска ракет, хоть лазерного облучения танка, хоть фидхэндлер для биржи. Технология и решаемая ею задача - две разные вещи.

Еще раз. Вы агитируете за использование ПЛИС в числ моделировании, и постулируете что ПЛИC даст существенный выигрыш в производительности. Ок, вот конкретная задача, моделирование синтетических сейсмограмм. Есть решение на CPU, область в 1024^3 ячеек, по 6 флотов в ячейке, по одному сложению и одному умножению на флот за шаг (на самом деле чуть больше), 2048 шагов на весьма средней по нынешним временам персоналке c 4х ядерным CPU считается сутки. Нетрудно оценить, что это 50% от макс возможной скорости CPU вообще (как если бы он считал какую нить фигню вообще в RAM не обращаясь).

Нетрудно оценить, что вам float сам по себе нафиг не впёрся, просто ничего лучше в вашем распоряжении нет. На FPGA можно:

• реализовать численный формат оптимальнее флоатов
• обрабатывать данные параллельно
• использовать высокоскоростной интерфейс для параллельной обработки на нескольких FPGA

Какая разница, насколько криво сделана подсистема памяти у совр CPU если мы можем писать код к-й с ней без потерь взаимодействует?

Такого не бывает. Я очень много писал и пишу всякой разной низкоуровневой фигни, и всегда упираюсь в память. Не упирался только на Z80, где время доступа константное и равно 1 циклу.

Вам надо решение с идеальным доступом, или решение считающее задачу за мин время?

Всё это очень сильно связано между собой.

Ему видно, что регистров, с которыми он может манипулировать, мало, и нужно постоянно делать оффлоад в память.

Я не знаю, есть ли для Lisp оптимизирующие компиляторы, но тот же gcc уже лет 10 может генерить код, в котором нет никаких лишних выгрузок «в память». Я уж молчу о том, что до RAM-а обмены со стеком не доходят с 99.9999% вероятностью (это навскидку). А то, что 16 РОН-ов мало --- так я обычно в ответ прошу привести пример алгоритма где их не хватит. Я, кстати, такие примеры знаю.

На векторных расширениях писать неудобно

По сравнению с чем?

ALM

Всегда хотел узнать --- что именно умеет делать один ALM за один такт. Не просветишь?

> Такого не бывает.

Батенька, Вы по ссылке ходили? Там написано как именно такое бывает и почему.

Всё это очень сильно связано между собой.

Это не ответ. Я Вам привел пример с конкретными цифрами по производительности для конкретной задачи, Вы ответ философию разводите.

> По сравнению с чем?

Вадим, с программированием ПЛИСА-же! Носки не сдувает, охлаждение не то... ну скока там от CPU вентилятор дует? А у ПЛИСов видать такая моща, что как включил девайс - сразу ногам прохладно, не то что у нас...;-)

> Я Вам привел пример с конкретными цифрами по производительности для конкретной задачи

Кхм, «конкретные цифры» - это

Alv> область в 1024^3 ячеек, по 6 флотов в ячейке, по одному сложению и одному умножению на флот за шаг (на самом деле чуть больше), 2048 шагов на весьма средней по нынешним временам персоналке c 4х ядерным CPU считается сутки

?

Боюсь, это цифры конкретны только для людей глубоко в теме, да и то вряд ли. Какое хотя бы соотношение объема входных и выходных данных?

Какое хотя бы соотношение объема входных и выходных данных?

очень правильный вопрос.

[i]с программированием ПЛИСА-же![/i]

;) не подсказывай.

размер задачи 1024*1024*1024*6*4 ~ 25 Гб (уй ее... много че та;-)), не считая массива коэффициентов и пр. фигни.

Сброс на диск (выходные данные) - много меньше, на шаг сбрасывается где то 10^3 флотов (зависит от сист наблюдений) + каждые 128 шагов два что ли глубинных среза, это 1024*1024*6*4 ~ 25 Мб всего лишь.

Задача считается кусками, ну 6 дисков стоят для обеспечения высокой ПСП. Подробности по ссылке, к-ю я в третий раз приводить не буду;-)

> Боюсь, это цифры конкретны только для людей глубоко в теме,

Люди в теме говорят «этого не может быть потому, что этого не может быть никогда» (как mv).

Если им объяснить, они говорят - ВАУ! Да это может быть...

Если они пытаются это воспроизвести, они говорят - Ой ееее... не, это как то слишком... мы лучше GPU или ПЛИС закодим;-)

>*6
на самом деле *9

~ 25 Гб

40 Гб (еще индекс)

Вы вообще знаете, что кроме проблем с потоками данных есть еще 100500 факторов замедляющих счет?

Традиционно, задача или упирается в недостаток вычислительной мощности, или в медленный ввод-вывод.

Да, забыл... но и 25 вызывает у слушателя желание сменить род деятельности и заняться напр. вязанием, а ты сразу 40...

> Подробности по ссылке, к-ю я в третий раз приводить не буду;-)

Я по ней сходил. Но там нет ни признания «мы смогли организовать систолический процессор^W^Wпоточную обработку данных на несколько ядер», ни цифр вида «поток данных из памяти - N, в память - M, при объеме кэша K и его частоте F», . А моей квалификации не хватает даже на прикидочную оценку по материалу из Вики ЛОРа, не говоря уже о pdf-документах, на которые она ссылается.

P.S. а «100% эффективность распараллеливания на любом числе процессоров» вызывает легкие подозрения, да.

ну приводил же уже в этом треде www.linux.org.ru/wiki/en/User:AIv/LRnLA

Ну хорошо, даже не влезло в память, висит на дисковом io. Это как-то задевает факт, что на ПЛИС можно сделать лучше?

Правильно, но если проблемы с памятью решили, то в частности на CPU с их заморочками любой чих приводит к перезапуску конвейра (VLev может более развернуто сказать). Я к тому, что если Вы соптимизировали паямть и ввод-вывод, то все равно 100% не получите. Получите... 50-70-90 - надо ли за это бороться?

> по одному сложению и одному умножению на флот за шаг (на самом деле чуть больше)
да, в исходном алгоритме 66 операций на ячейку ЕМНИП (42 сложения и 24 умножения).

> P.S. а «100% эффективность распараллеливания на любом числе процессоров» вызывает легкие подозрения, да.

Вики написана в научно-популярном стиле. А в pdf просто есть бенчмарки, к-е эти 100% подтверждают, да.

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

А вы статистику perf.counter'ами собираете по своим алгоритмам? Какую долю времени процессор тратит на обслуживание io, а не вычислений? По две-три загрузки кэш-строк на такт у вас всё время быть не может.

Ну вот с этого и надо было начинать, советуя FPGA в теме про вычисления.

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

«сколько-нибудь» --- это занятная характеристика «точных вычислений» :) Приведите пример.

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

> Это как-то задевает факт, что на ПЛИС можно сделать лучше?

Смотрите, есть кривой девайс (персоналка за 500-1000$) и костыльное (обусловленное кривостью девайса) решение, на котором задача считается сутки с эффективностью 50%. Есть гипотетическая расово чистая ПЛИС за те же деньги, которую можно узко-узко заточить на эту задачу и она будет считать с эффективностью 99% (разработчики плачут от умиления)... 10 суток, поскольку банально не хватит флопсов. И чем же решение на ПЛИC лучше?

Заказчику то пофик на чем считается, хоть на счетах - ему сейсмограммы нужны.

да, в исходном алгоритме 66 операций на ячейку ЕМНИП (42 сложения и 24 умножения).

Ну да, тоже соврал... блин, так ответил бы сам, или в вики вставил соотв раздел. Вон tailgunner с пральной критикой текста выступил;-)

Правильно, но если проблемы с памятью решили, то в частности на CPU с их заморочками любой чих приводит к перезапуску конвейра (VLev может более развернуто сказать). Я к тому, что если Вы соптимизировали паямть и ввод-вывод, то все равно 100% не получите. Получите... 50-70-90 - надо ли за это бороться?

Мы ещё и оптимизируем конвейер под задачу. Бороться?... Если за это платят деньги, то почему нет?

да, в исходном алгоритме 66 операций на ячейку ЕМНИП (42 сложения и 24 умножения).

Граф операций как выглядит?

> Если за это платят деньги, то почему нет?

Вам деньги платят за эффективность работы ПЛИС или за реальную скорость счета задачи?

Смотрите, есть кривой девайс (персоналка за 500-1000$) и костыльное (обусловленное кривостью девайса) решение, на котором задача считается сутки с эффективностью 50%. Есть гипотетическая расово чистая ПЛИС за те же деньги, которую можно узко-узко заточить на эту задачу и она будет считать с эффективностью 99% (разработчики плачут от умиления)... 10 суток, поскольку банально не хватит флопсов. И чем же решение на ПЛИC лучше?

У меня очень сильные подозрения на счёт таких «выводов».

Вам деньги платят за эффективность работы ПЛИС или за реальную скорость счета задачи?

Мы платим немалые деньги за ПЛИС (старшие модели от Альтеры - $15k), потому что можем на них эффективно решать задачи, за которые платят деньги. Вычисление того же самого даже на топовом компьютере на два-три порядка медленнее.

> У меня очень сильные подозрения на счёт таких «выводов».

Скорость счета сейсмограмм на CPU я привел, это реальный факт. Приведите свою оценку для ПЛИС. Граф вычислений - из того что можно найти в сети вот тут http://grid2008.jinr.ru/pdf/vlevchenko.pdf для 1D Максвелла (они оч. похожи, для 3D сейсмики сложнее но идея та же). Число операций VLev привел.

> да, в исходном алгоритме 66 операций на ячейку ЕМНИП (42 сложения и 24 умножения).

«36 доступов в память на чтение и 8 на запись в расчете на один шаг по времени на каждую ячейку сетки», т.е. соотношение объема входных данных к объему выходных - 36/8?

> Параметр - скорость работы готового изделия.

При равной стоимости изделия(!).

По этому параметру для задач числ моделирования с конечной скоростью распространения возмущений CPU рвут ПЛИС в клочья.

> Мы платим немалые деньги за ПЛИС (старшие модели от Альтеры - $15k), потому что можем на них эффективно решать задачи, за которые платят деньги. Вычисление того же самого даже на топовом компьютере на два-три порядка медленнее.

Заказчик покупает обычные персоналки за смешные деньги, за 15$ покупается цельный 48 ядерный сервер. На CPU считаются «обычные» сейсмограммы, на 48 ядерных узлах планируется решать задачи на 4ре порядка более сложные. Вычисление того же самого даже на ПЛИС той же стоимости... ну Вы надеюсь скажете на сколько порядков будет медленнее?;-)

Я не знаю, есть ли для Lisp оптимизирующие компиляторы, но тот же gcc уже лет 10 может генерить код, в котором нет никаких лишних выгрузок «в память». Я уж молчу о том, что до RAM-а обмены со стеком не доходят с 99.9999% вероятностью (это навскидку).

Это да, но если надо обработать 40 гб данных, то обмена с памятью будет предостаточно.

Вот по тому url'у автор пишет, что алгоритм полностью параллельный - это как раз стезя ПЛИСов.

А то, что 16 РОН-ов мало --- так я обычно в ответ прошу привести пример алгоритма где их не хватит. Я, кстати, такие примеры знаю.

Легко: сложение векторов :)

По сравнению с чем?

По сравнению со штатным набором инструкций.

Всегда хотел узнать --- что именно умеет делать один ALM за один такт. Не просветишь?

http://www.altera.com/products/devices/stratix-fpgas/about/fpga-architecture/stx-architecture.html

Заказчик покупает обычные персоналки за смешные деньги, за 15$ покупается цельный 48 ядерный сервер. На CPU считаются «обычные» сейсмограммы, на 48 ядерных узлах планируется решать задачи на 4ре порядка более сложные. Вычисление того же самого даже на ПЛИС той же стоимости... ну Вы надеюсь скажете на сколько порядков будет медленнее?;-)

Несвязанные операции делаются за один такт. Степень параллельности ограничена количеством доступных в ПЛИС ячеек.

И мне как-то побоку состояние кармана вашего заказчика в обсуждении технических преимуществ в обработке данных на ПЛИС ;)

>> Параметр - скорость работы готового изделия.

При равной стоимости изделия(!).

Отнюдь не всегда. Бывает, что «за ценой не постоим». Да и программирование (и отладка) вычислительных алгоритмов на ПЛИСах - еще то удовольствие, так что те, кто на это идет, готовы к затратам.

По этому параметру для задач числ моделирования с конечной скоростью распространения возмущений CPU рвут ПЛИС в клочья.

Возможно. No silver bullet и всё такое. Но, справедливости ради, много ли ты знаешь реализаций LRnLA на ПЛИСах?

>А вы статистику perf.counter'ами собираете по своим алгоритмам?
По своим --- нет, мне с ними и так все ясно.
По чужим --- собирал.

Какую долю времени процессор тратит на обслуживание io, а не вычислений?

очевидно, <10%
кстати, я подозреваю, что под io Вы имеете в виду обмены с RAM-ом. Тогда больше. ~30%. Ну и синхронизация между потоками ~10%
Вообще, это все соотношением параметров определяется, которыми можно управлять.

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

Осталось доказать, что «низкий уровень для доступа» --- это именно то, что «одинаково хорошо для любых задач».

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

Мне хотелось, чтобы это сделали Вы. А я в подобных случаях меняю алгоритм на такой, в которых ошибки округления не накапливаются.
И вообще, стандарт IEEE 754 меня более-менее устраивает. Кстати, там и квады есть.

Оценочку, оценочку для озвученной задачи приведите пожалуйста. И откуда она взялась.

Несмотря на мое глубочайшее к Вам уважение (без всякого сарказма), мне вот как то побоку Ваша убежденность во всемогуществе ПЛИС, когда цифры говорят обратное.

> много ли ты знаешь реализаций LRnLA на ПЛИСах?

Ни одной. Но - в этих задачах упор именно во флопсы. Наск я понимаю, ПЛИС по флопсам CPU сливает вчистую, что естественно - там как бэ на другое упор делается? Дальше уже никакой LRnLA не поможет.

>Граф операций как выглядит?
весь или только тот участок, где эти 66 операций?

Оценочку, оценочку для озвученной задачи приведите пожалуйста. И откуда она взялась.

Алгоритма-то нет, какие оценки могут быть? В pdf'ке rартинки с пирамидами латентности «от регистров до WAN» красивые, конечно, но по части самого алгоритма малоинформативны.

всемогуществе ПЛИС, когда цифры говорят обратное.

У вас цифр по реализации на ПЛИС нет. Или есть? Наши цифры говорят о том, что по нашему направлению на ПЛИС мало того, что можно сделать решение с детерминированной латентностью, так ещё только на ПЛИС можно сделать решение, которое работает на полностью загруженном канале данных (10 гбит) и при этом не захлёбывается.

Поползновения производителей процов в сторону ПЛИС (определяемые пользователем макрооперации) тоже говорят как раз о преимуществах ПЛИС.

>«36 доступов в память на чтение и 8 на запись в расчете на один шаг по времени на каждую ячейку сетки», т.е. соотношение объема входных данных к объему выходных - 36/8?
не угадали. ;) Забираю свой комментарий о правильном вопросе.
36/8 (точнее, 45/9) --- это просто соотношение чтений и записей переменных в программе (после оптимизации компилятором будет даже лучше).
А к соотношению входных и выходных данных (в терминологии Фон-Неймана) вообще никакого отношения не имеет.

весь или только тот участок, где эти 66 операций?

Где 66 операций. Степень эффективности ПЛИС, в основном, идёт за счёт паралелльной обработки. Если операции в графе распараллелены слабо, то эффективность, соответственно, снижается.