Скорость Эльбруса
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-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
Date: 2016-02-15 11:45 (UTC)- Еще с тех пор помню, что на более-менее нормальном софте, на западных компьютерах я эту кнопку вообще не трогал.
А особенный прикол несколько лет назад случился - я как-то в страшной спешке собрал компьютер, и там только кнопку питания присоединил "и полетел", и работал.
- И только через пол года руки дошли провода поприсоединять, когда захотелось чтобы был типа порядок - чтобы видеть когда активность диска, ЮСБ на переднюю панель подключить, итп ;)
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
Date: 2016-02-15 08:59 (UTC)Но при этом нужно понимать, что если general-purpose статическая оптимизация для VLIW невозможна (будем пока считать), то оптимизация под конкретные ситуации, где требуется выч. мощность, сравнительно тривиальна. BLAS, другие матбиблиотеки, компиляция кода с hint-тэгами вроде OpenMP и т.п. В том или ином виде это всё существует больше 30 лет. (Помнится, в середине 80-х сам поучаствовал в переделывании фортрановского кода под FPS-164/264 и чуточку под Convex -- это такой мини-крей был).
no subject
Date: 2016-02-15 11:40 (UTC)Да.
Просто 30 лет назад средний уровень программиста был намного выше чем сейчас - был сильнее отсев, была ниже потребность индустрии.
- Сейчас ввиду большой потребности в некритичном софтвере (всяческие вебсайты, всяческая бизнесовая логика), минимальный уровень среднего программиста сильно снизили - условные пэхэпэшники такой ужас пишут что оно не просто на голову не налазит, а на нем анализаторы падают :)
И эти нынешние 90% большинство уже неспособны не то что оптимизациями заниматься, а и вообще про железо ничего не знают - я уже встречал вполне успешных девелоперов, которые на Си писать не могут вообще - им просто тяжело мозг заставить работать на нужном уровне.
Кстати, я теперь понял, почему в нынешнем компьютер сайнс стали говорить, что "без тесных отношений с хардвером нынешний софтвер выхолащивается" - по всей видимости они как раз про это.
no subject
Date: 2016-02-15 12:54 (UTC)no subject
Date: 2016-02-15 13:43 (UTC)Но среднестатистический проект делается вот именно низкоквалифицированными, потому что надо быстро и дешево.
no subject
Date: 2016-02-15 14:13 (UTC)no subject
Date: 2016-02-15 14:31 (UTC)А вы можете обоснованно опровергнуть это утверждение?
- Я как раз могу обоснованно это утверждать.