Скорость Эльбруса
2016-02-03 11:41![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
vakПоявились результаты измерения производительности Эльбруса, которым вроде бы можно доверять. Смотрите страницу 7: http://www.kpda.ru/upload/iblock/a80/senkov_25.11.2015.pdf
Тест Dhrystone у меня под рукой, так что я тут быстренько прикинул. Получается, последний Эльбрус-401 выпуска 2015 года в 16 раз медленнее моего iMac 2012 года. Процессоры соответственно Эльбрус-4С 800МГц и Intel Core i5 2.7ГГц.
Интересно, что производительность Эльбруса получилась равной скорости платы Raspberry Pi 2 Model B 1000MHz ($36 на Амазоне).
Тест Dhrystone у меня под рукой, так что я тут быстренько прикинул. Получается, последний Эльбрус-401 выпуска 2015 года в 16 раз медленнее моего iMac 2012 года. Процессоры соответственно Эльбрус-4С 800МГц и Intel Core i5 2.7ГГц.
Интересно, что производительность Эльбруса получилась равной скорости платы Raspberry Pi 2 Model B 1000MHz ($36 на Амазоне).
no subject
Date: 2016-02-05 14:29 (UTC)no subject
Date: 2016-02-05 18:59 (UTC)Проц-то катастрофически, может, и не отстал - на уровне Атома, в целом.
Но вот оптимизация компилятора под него - это задача не такая и ординарная, да и приложения надо под него оптимизировать.
no subject
Date: 2016-02-05 20:23 (UTC)- Сдается мне, что вся эта история просто чистая психология - захотели выпустить такое чтобы на весь мир, не важно что провал.
no subject
Date: 2016-02-05 20:39 (UTC)А сейчас по-моему практически всё - уже в VLIW/EPIC никто не верит, потому что с компилятором не сложилось.
Ну то есть я не спорю конечно, что если Интел не удалось, это не значит что никто не сможет, но только тогда не понятно, зачем нужно было сооружать полномасштабный проект, там где можно было ограничиться намного более дешевыми симуляторами.
no subject
Date: 2016-02-06 10:11 (UTC)Когда-то это понял IBM и выпустил System/360 (получив вначале массу нареканий за плохую плавучку и неэффективность конкретных моделей), при том, что 360/20, считаем, всё выполняла микропрограммно, а в 360/95 уже был out-of-order почти современного вида. А потом это знание протеряли HP и Intel, и выпустили своих уродцев - самое удивительное, что Intel на это пошёл, имея x86, на котором было отлично видно, что рост возможен только на расширяемой универсальной ISA. Видно, кому-то очень хотелось подсидеть внутренних коллег. Хотя у Intel тогда это не единственный просчёт - связались же они с Rambus... А теперь их подвиг повторяет МЦСТ, причём тратя не свои деньги, а государственные, и не имея такой ресурс в виде грамотных инженеров, чтобы написать сравнимо адекватные диспетчер в железе и компилятор в софте.
no subject
Date: 2016-02-06 11:57 (UTC)> Когда-то это понял IBM и выпустил System/360 (получив вначале массу нареканий за плохую плавучку и неэффективность конкретных моделей)
Дело не в этом. Я про технологии ответил в другой ветке, тут отвечу про экономику.
В экономике фирмы есть понятие вилки цен - суть в том, что ВСЕГДА в сколько-то большой выборке покупателей/клиентов есть те кто покупает самое дешевое, а есть те кто охотно платит больше, и если у фирмы есть в товарной линейке разные товары для этих групп, то фирма может заработать значительно больше (разница может быть 30% и более).
В сущности, можно делать проще - хороший продавец обычно в состоянии довольно точно определить платежеспособность покупателя/клиента и продать один и тот-же товар с разницей наценки в РАЗЫ, но в современном мире с большой доступностью информации, высокая вероятность возникновения недовольства покупателей такой политикой, поэтому делают именно линейку с достаточно широкой вилкой возможностей.
Далее, есть такая бизнесовая модель - инновационная - суть что фирма использующая эту модель всегда работает на будущее, всегда на пару шагов впереди конкурентов, и эта фирма использует это преимущество чтобы всё время снимать с рынка сливки (а когда конкуренты уже подбирают мелочь, тут-же фирма-инноватор выпускает новую прорывную технологию).
Итаниум это очевидно была попытка по-быстрому создать совершенно прорывную технологию, которая-бы обеспечила на многие годы Интел преимущество над всеми конкурентами - тогда еще стало понятно, что в коде ЯВУ есть информация, которую можно было-бы применить для более высокой степени оптимизации чем это делают современные компиляторы, и эту оптимизационную информацию можно было передавать внутрь железа EPIC.
Идея несомненно классная, но сколько будет стоить создать новую экосистему разработки софта никто точно не знает, а без новой экосистемы оно не даст ожидаемого эффекта (просто потому что в распространенных ЯВУ недостаточно высокий уровень абстракции, а использовать расширения типа того об чем рассказывают в статье про "Эльбрус" средний программист не будет).
Не взлетело, по одной причине - недостаточно точная оценка возможностей конкурента и рынка, также возможно недооценили себестоимость разработки компиляторов (см далее).
А конкретно имела место слишком грубая (завышенная) оценка готовности рынка купить EPIC, и в то же время заниженная оценка готовности конкурента сделать просто 64-битовый х86, а рынка купить просто 64-битовый х86 от конкурента.
Почему дело в конкуренте я думаю понятно, а вот с рынком ситуация, что на тот момент Интел довольно крепко держал всё в руках, и очевидно сложилась иллюзия, что рынок потерпит на 32 битах, пока не появится массовый Итаниум (и это кстати хорошо заметно по интеловским чипсетам тех времен);
далее очевидно рассчитывалось, что конкуренты еще очень долго не смогут повторить Итаниум, а за это время на гребне волны можно было вложиться в разработку хорошо оптимизирующего компилятора и закрепить свое преимущество, и продажами инвестиции отбить.
А случилось, как говорится, "гладко было на бумаге".
- Конкурент выпустил свою дешевую версию 64-бит; рынок эту версию охотно принял; далее Интелу пришлось изображать непотерянное лицо и покупать лицензию у конкурента и выпускать тоже дешевую версию 64-бит и похоронить Итаниум, не потому что тот был плохой, а потому что следующее окно возможностей столько денег из рынка вытащить, еще неизвестно когда будет.
Вот и весь рассказ.
no subject
Date: 2016-02-11 06:35 (UTC)То же появление amd64 как раз было примером того, о чём я говорю - архитектура допускала лёгкое расширение за счёт целого ряда факторов, включая и очень дешёвую в расширении ISA, и концептуальную годность к такому расширению с сохранению совместимости (на мой взгляд, даже слишком - AMD'шники использовали слишком мало возможностей расширения базы). Intel же почему-то предположил принципиальный технологический тупик x86 (можно попытаться связать это с их отказом от линии P-III и попыткой выжать последние капли через NetBurst).
А дальше начали работать собственно административные и экономические рычаги. Рынок выглядит слишком перспективным для эксперимента (ну, не на 100% эксперимента - i860 уже был опробован - но в широких пределах так точно). Конкуренты не выглядят сильными - вот только что сдохла Alpha и труп был торжественно разделён между участниками похорон. Можно и попробовать.
Но тема данного постинга всё-таки не Intel? Мы на них тратим основной объём, но "в уме" держим Эльбрус-VLIW. И вот тут я как-то не могу принять идею, что то, что не получилось у Intel ударным вложением со всей мощи и ведущего мирового опыта, получится у маленькой российской конторы. (Разве что за ней продолжает непублично стоять тот же Intel, отдавая несостоявшиеся активы туда, где их хоть как-то применят? Конспирология или нет?)
no subject
Date: 2016-02-11 11:05 (UTC)Я всего-лишь сказал, что определила победителя экономика.
А в РФ экономики нет - там плановое хозяйство и вместо экономики действуют совсем другие факторы, типа крепкости яиц и гибкости позвоночника.
А технологии тут влияют конечно, но только те, которые действуют как жесткий ограничитель возможностей.
Если совсем точно, практически любую технологию можно внедрить, если вложить достаточно денег в проработку и в отладку, НО в том и дело, что чтобы иметь эти необходимые деньги, необходимо их заработать.
- У государства просто никогда не было и не будет достаточно денег, чтобы сделать нормальный процессор.
> Но тема данного постинга всё-таки не Intel?
Ну мне конечно хотелось поговорить с умным человеком.
А от Интела мы никуда не денемся - Интел несомненно лидер, причем часто вопреки не лучшему технологическому уровню его продукции.
> я как-то не могу принять идею, что то, что не получилось у Intel ударным вложением со всей мощи и ведущего мирового опыта, получится у маленькой российской конторы.
В том и дело, что тоталитарные режимы способны концентрировать огромные ресурсы на направлениях, которые считают для себя критическими.
То есть за этой маленькой конторой стоит 140-миллионная страна (ну ладно, там из той страны хорошо если миллионов 30 искренне поддерживают такие траты, потому что являются явными выгодоприобретателями, а остальных тупо и цинично доят, и эти остальные ненавидят этот неосовок но противостоять доению сейчас не могут, но это всё не так важно - важно что подоили и подоенное частично потратили на "гравицапу").
Так было например, с ракетной техникой и с ядерным оружием в 1950-1960-х, а в 1970-х появился "ассимметричный ответ" в виде атомных подводных лодок с баллистическими ракетами на борту.
А, ну и само собой, Германия в первой половине 20 века очень много раз успешно использовала передовые технологии, чтобы получить военное преимущество (грузовые автомобили, самолеты, подводные лодки, итд).
Но возвращаясь к субжу, сам факт того, что стали делать НЕ достаточно обкатанный суперскаляр а VLIW, как раз говорит МНЕ, об том что на суперскаляр денег не хватило, точнее не хватило очевидно на полупроводниковые технологии, а вместо этого решили опереться на софтвер, потому что считалось что как раз его РФ сможет сделать.
Конспирологии я не усматриваю - я как раз усматриваю вполне рациональный подход, и на всякий случай тут его сформулирую полностью:
РФ нужен современный микропроцессор (пусть и для онанирования - все же понимают что экономика будет гарантированно отрицательная но вот хотят и всё тут), и нормальный никто не продаст, поэтому вынуждены изъёживаться своими силами;
есть более-менее отлаженные технологии базовых матричных кристаллов, но нет возможности сделать современного уровня литографию;
есть в стране, прямо скажем, неплохие математики, что теоритически могли сделать то что не сделал Интел, и при этом стоят они дешевле чем стоят математики для Интел;
и люди принимающие решения не боятся что их сожрут - просто такая ситуация что у верхов нет выбора - нужно "кушать что дают".
Ну вот, по совокупности входных данных, было принято решение, сделать попытку инновационного прорыва - сделали заведомо ущербный синтезированный процессор, а его ущербность попытались компенсировать компилятором.
no subject
Date: 2016-02-11 11:12 (UTC)no subject
Date: 2016-02-06 03:50 (UTC)no subject
Date: 2016-02-06 05:59 (UTC)И я допускаю, что его вообще невозможно сделать на нынешнем уровне науки - вот просто что для него нужно сделать целую новую экосистему с нуля - новые языки, новые среды разработки, новые библиотеки, новые алгоритмы, новые загрузчики, новые утилиты, и даже возможно новую методологию.
Почему так - да просто в сравнении с CISC/RISC во VLIW/EPIC добавилась новая переменная оптимизации (вот эти самые явно параллельно работающие потоки команд добавили новое ограничение и новое измерение), и эта область ИМХО слабо исследована.
Просто потому что особой нужды в ней не было.
- VLIW было в истории вероятно даже больше десятка, но они все были либо узкоспециализированные для встраиваемых приложений, всяческие DSP, которые программировали для узкого круга задач на машкодах, либо как у Трансметы "черный ящик", который тоже программировали фактически на машкодах, а массовых не было ни одного.
no subject
Date: 2016-02-06 06:12 (UTC)no subject
Date: 2016-02-06 08:51 (UTC)no subject
Date: 2016-02-06 09:34 (UTC)А здесь — один из бывших разработчиков компилятора поотвечал на вопросы: http://eax.me/eaxcast-s01e06/
no subject
Date: 2016-02-06 12:22 (UTC)- Реально все это пока уровня одного западного стартапа, да еще и не дошедшего пока до окупаемости, да и параметры так себе, а презентуют прямо как мировую революцию.
no subject
Date: 2016-02-11 06:46 (UTC)Автор на geektimes, может, и имеет доступ к телу, но он не понимает, что же смотреть. Например, искреннее удивление по поводу conditional return показывает, что он не читал книгу, которую сам же рекламирует.
Разработчик компилятора вообще ничего не сказал по сути.
Если бы был хотя бы инструмент типа http://gcc.godbolt.org/, выставленный на публику - в течение полмесяца можно было бы ожидать полдесятка отзывов от людей, которые действительно что-то понимают в проектировании процессоров и компиляторов.
no subject
Date: 2016-02-11 22:28 (UTC)(no subject)
From:no subject
Date: 2016-02-06 18:31 (UTC)no subject
Date: 2016-02-11 06:52 (UTC)Чорд, это уже сказали раньше ;(
no subject
Date: 2016-02-11 10:23 (UTC)no subject
Date: 2016-02-06 18:28 (UTC)no subject
Date: 2016-02-06 19:56 (UTC)no subject
Date: 2016-02-11 07:00 (UTC)А вот это, между прочим, миф, который опровергнут авторами языка.
"""Thompson went a step further by inventing the ++ and -- operators, which increment or decrement; their prefix or postfix position determines whether the alteration occurs before or after noting the value of the operand. They were not in the earliest versions of B, but appeared along the way. People often guess that they were created to use the auto-increment and auto-decrement address modes provided by the DEC PDP-11 on which C and Unix first became popular. This is historically impossible, since there was no PDP-11 when B was developed. The PDP-7, however, did have a few `auto-increment' memory cells, with the property that an indirect memory reference through them incremented the cell. This feature probably suggested such operators to Thompson; the generalization to make them both prefix and postfix was his own. Indeed, the auto-increment cells were not used directly in implementation of the operators, and a stronger motivation for the innovation was probably his observation that the translation of ++x was smaller than that of x=x+1."""
h ttp://cm. bell-labs. co/who/dmr/chist.html
И C давно уже не является тем "кроссплатформенным ассемблером", потеряв от последнего достаточно много плюшек.
С другой стороны, он всё равно выражает операции в виде, близком к тому, что делается в аппаратуре - и я не вижу, чем это принципиально могло бы помешать укладке на EPIC так же, как его укладывают на CISC и RISC. Компиляторы, умеющие оптимизацию шедулинга с укладкой на исполнительные блоки для x86, вытянут это и для EPIC, если не будет совсем уж странных подводных камней.
no subject
Date: 2016-02-11 11:19 (UTC)Подводный камень есть - дело в том что архитектура CISC/RISC довольно простая и хорошо изучена, то есть там относительно мало возможностей чтобы еще более ее улучшить, но и компиляторы делаются на мощном фундаменте.
В то же время технология VLIW в сравнении с CISC/RISC, имеет несколько дополнительных степеней свободы оптимизации (в комбинаторном смысле), и пока еще они не утоптаны опытным использованием так как CISC/RISC.
Ну другими словами, если сейчас свершится чудо и РФ таки действительно насильственно переведут на VLIW, и страна в нынешнем виде еще просуществует лет 20, то есть ненулевая вероятность, что они за это время сделают много итераций VLIW и компиляторов, и таки нащупают оптимум, который сделает VLIW лучше суперскалярных CISC.
no subject
Date: 2016-02-11 11:58 (UTC)Вообще опыт показал (я довольно плотно сталкивался с эмбеддед), что на частных случаях VLIW, когда есть возможность оптимизации кода вручную, себя показывают очень хорошо, за что и есть несколько эмбеддед VLIW (EPIC типа Итаниума, у которого компилятор вшивал в код подсказки для шедулера, я еще не встречал).
А с общим применением не сложилось, потому что производительность сильно уступает традиционным архитектурам.
Я считаю, проблема в том, что на общем применении подавляющее большинство софта, который вручную никто не оптимизирует и даже просто пишет явно неоптимально, но оптимизирующие компиляторы доводят до более-менее пригодного к использованию состояния.
Вобщем экономика рулит.
При этом я еще допускаю, что есть принципиальная проблема, что VLIW/EPIC нужно разработать принципиально новый алгоритм шедулера, то есть я допускаю что только принципиально новый шедулер даст большой качественный скачок.
(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From: