Dhrystone на Эльбрусе-4С

[vak]

Появилась некоторая информация про реальную скорость Эльбруса-4С. Подробности в ветке: http://1500py470.livejournal.com/119026.html?thread=1141490#t1141490

Вкратце, тест Dhrystone на 800-мегагерцовом Эльбрусе-4С показывает скорость 2.67 MDPS.

Для сравнения, я померял на своем домашнем аймаке (2.7 GHz Intel Core i5), получается 28.4 MDPS. То есть если пересчитать по частоте, 800-мегагерцовый Эльбрус работает примерно как 250-мегагерцовый Intel i5.

Мои исходники Dhrystone здесь: https://code.google.com/p/vak-opensource/source/browse/trunk/#trunk%2Futilities%2Fdhrystone
Попробуйте скомпилировать и запустить у себя, для сравнения.

P.S. MDPS = Million Dhrystones Per Second.

P.P.S. Чтобы получить DMIPS, нужно измеренное значение умножить на 569. Я поправил исходники теста, теперь он все правильно печатает. То есть реальный DMIPS Эльбруса равен 1520, что примерно соответствует процессору Pentium III с частотой 1000 МГц. Таблица результатов здесь: http://www.roylongbottom.org.uk/dhrystone%20results.htm

Comments

[oboguev.livejournal.com]

Ничего про этот mill не знаю, но сейчас заглянул в гугль, и там написано: "The Mill can perform operations speculatively".

Такими темпами пожалуй выяснится, что у этого mill-а ещё и кэш имеется.

[spamsink]

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

[oboguev.livejournal.com]

Как они могут быть обнадеживающими, если статическое планирование не знает, будет операнд в кэше или не будет?
А откуда оно об этом может знать?
Потому что пятилетний план так предсказывает?

Вообще же, есть полезный закон больших чисел.
Например СССР был большим, и благодаря этому большому N мы сейчас хорошо знаем, что тотально-государственный социализм работает неважно.
Аналогичным же большим проектом был Itanium -- там тоже старались, сильно и долго, но преимущества социализма статического планирования так миру и не явили.

P.S. Употребленная аналогия между статическим планированием и госсоциализмом -- это не просто образ.

[spamsink]

Стопроцентной достоверности никто не требует, а размеры линеек кэша и шаг итерации прекрасно известны статически. Из этого следует, что можно предсказать наличие операнда в кэше с вероятностью, скажем, 15/16. Или 63/64.

Например СССР был большим...

Зачем пользоваться сомнительными аналогиями, если можно ознакомиться, и критиковать не огульно, а детально?

(Disclaimer: мой единственный интерес - что Mill Computing будет нашим клиентом, когда дело дойдет до верификации хардвера.)

[oboguev.livejournal.com]

Да откуда же они могут быть известны статически?
Хорошо конечно, если матрица 200х200.
А если она NxM?

Про асинхронность и мультипроцессорность даже не упоминаю.

[spamsink]

Один простой вопрос: что делают существующие процессоры, когда внезапно какого-нибудь операнда не оказывается в кэше?

[oboguev.livejournal.com]

Очевидно, тормозят до прибытия операнда те операции, для которых нужен операнд, и начинают/продолжают динамическое (в т.ч. спекулятивное) исполнение тех, для которых он не нужен. Согласно динамически отслеживаемому графу зависимостей.

Опыт Итаниума и СССР наставляет нас, что состояния в этом графе (а по большому счету и сам граф) не могут быть удовлетворительно прогнозированы 5-летним планом.

[spamsink]

начинают/продолжают динамическое (в т.ч. спекулятивное) исполнение тех, для которых он не нужен

А берутся они из других тредов. Ну так в обычном процессоре для эффективной реализации этого приходится SMT городить, а в этом хватит и block-level.

не могут быть удовлетворительно прогнозированы 5-летним планом

Да хорош уже, пора бы и с матчастью ознакомиться.

[oboguev.livejournal.com]

Я же написал выше: асинхронность и мультипроцессорность я вообще здесь не рассматриваю. Включая SMT.
Ясно, что для статического планирования это сразу застрелиться.

Я, проявляя доброту, вел речь про исполнение команд из текущего потока.
Execute-ahead, так сказать.

> пора бы и с матчастью ознакомиться

Так матчасть такова: USSR, Itanium. RIP.
Понятно, что причин был комплекс, тем не менее обещания "повышения производительности труда" решительно не материализовались.

[spamsink]

Я так погляжу, упорное нежелание знакомиться с матчастью сопряжено с боязнью узнать что-то новое, отчего мнению придется перемениться?

[oboguev.livejournal.com]

Я иногда употребляю выражение "матчасть", но всегда сопровождая его конкретными ссылками (конкретными -- значит конкретно по вопросу, а не "как конкретный пацан"). Иные же виды употребления звучат -- по крайней мере, для моего нежного уха -- как "пасть порву, моргалы выколю".

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

[spamsink]

LMGTFY: http://millcomputing.com/docs/

[oboguev.livejournal.com]

Я ведь недаром написал:

конкретными -- значит конкретно по вопросу, а не "как конкретный пацан"

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

Извините за само-цитирование.

[spamsink]

Всё-то надо разжевать и в рот положить.

It is well known that exposed-pipe static scheduling yields near-perfect code with minimal power – except when there is a miss in the cache. In a conventional VLIW, a miss stalls the whole machine, whereas an out-of-order architecture can sometimes find other useful operations to execute while waiting on the memory hierarchy. The Mill uses a novel load instruction that tolerates load misses as well as hardware out-of-order approaches can do, while avoiding the need for expensive load buffers and completely avoiding false aliasing. In addition, store misses are impossible on a Mill, and a large fraction of the memory traffic of a conventional processor can be omitted entirely.

[oboguev.livejournal.com]

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

Тем не менее, я не поленился, и открыл powerpoint по ссылке.

"This isn't a load problem. It's a speculation problem".

Whoa!
То есть динамическое планирование у них всё-таки есть, только называется статическим планированием?
Воистину, "чем демократия отличается от народной демократии".

[spamsink]

Нету, нету. Как решается speculation problem, рассказано в http://millcomputing.com/docs/metadata/

Лучше начать с самого начала и смотреть видео, а не powerpoint.

[vak]

Не только из других тредов, из этого треда тоже, в случае out of order микроархитектуры.
Но дело даже не в высокой степени динамики.
Даже чисто статически компилятор Итаниума генерит код, который выполняет в среднем чуть больше 2-х инструкций за такт, из шести возможных.

[spamsink]

Видал я ту архитектуру Итаниума в своё время. Тот же Бабаян, вид сбоку. Mill с этим Итаниумом и рядом не лежал. Чисто статически в Mill распараллеливается гораздо более широкий класс циклов.

[vak]

Я по итаниуму даже книжку купил из любопытства, стоит где-то на полке. Ужасно некрасивая для программиста архитектура.
http://www.amazon.com/Itanium-Architecture-Programmers-Understanding-Processors/dp/0131013726/

Mill штука многообещающая. На какой они сейчас стадии? Есть ли Си-компилятор и программный симулятор? Хотя бы прототип.

[spamsink]

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

Приходи 10 июня http://www.meetup.com/SFBay-Association-of-C-C-Users/events/218992453/ - узнаешь.

[vak]

Тогда уж цель коммерческих компаний - максимизировать прибыль для акционеров, а производительность процессоров просто иногда кореллирует с этим критерием. :)

Идею-то я понимаю и ценю, но хочется дождаться реализации. Дьявол в деталях обычно.

[spamsink]

Чтобы прибыль для акционеров была не одномоментная, а в течение многих лет, увы, приходится всё-таки максимизировать производительность на доллары и ватты. Потому что you cannot fool all the people all the time.

[oboguev.livejournal.com]

Увы, фирма Интел полностью опровергла надежду Достоевского, будто "красота спасёт мир".

[vak]

Красота может и спасёт, но не Интел. :)