![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Entry tags:
Скорость Эльбруса
Появились результаты измерения производительности Эльбруса, которым вроде бы можно доверять. Смотрите страницу 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
А вот это, между прочим, миф, который опровергнут авторами языка.
"""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
Подводный камень есть - дело в том что архитектура CISC/RISC довольно простая и хорошо изучена, то есть там относительно мало возможностей чтобы еще более ее улучшить, но и компиляторы делаются на мощном фундаменте.
В то же время технология VLIW в сравнении с CISC/RISC, имеет несколько дополнительных степеней свободы оптимизации (в комбинаторном смысле), и пока еще они не утоптаны опытным использованием так как CISC/RISC.
Ну другими словами, если сейчас свершится чудо и РФ таки действительно насильственно переведут на VLIW, и страна в нынешнем виде еще просуществует лет 20, то есть ненулевая вероятность, что они за это время сделают много итераций VLIW и компиляторов, и таки нащупают оптимум, который сделает VLIW лучше суперскалярных CISC.
no subject
Вообще опыт показал (я довольно плотно сталкивался с эмбеддед), что на частных случаях VLIW, когда есть возможность оптимизации кода вручную, себя показывают очень хорошо, за что и есть несколько эмбеддед VLIW (EPIC типа Итаниума, у которого компилятор вшивал в код подсказки для шедулера, я еще не встречал).
А с общим применением не сложилось, потому что производительность сильно уступает традиционным архитектурам.
Я считаю, проблема в том, что на общем применении подавляющее большинство софта, который вручную никто не оптимизирует и даже просто пишет явно неоптимально, но оптимизирующие компиляторы доводят до более-менее пригодного к использованию состояния.
Вобщем экономика рулит.
При этом я еще допускаю, что есть принципиальная проблема, что VLIW/EPIC нужно разработать принципиально новый алгоритм шедулера, то есть я допускаю что только принципиально новый шедулер даст большой качественный скачок.
no subject
Но при этом нужно понимать, что если general-purpose статическая оптимизация для VLIW невозможна (будем пока считать), то оптимизация под конкретные ситуации, где требуется выч. мощность, сравнительно тривиальна. BLAS, другие матбиблиотеки, компиляция кода с hint-тэгами вроде OpenMP и т.п. В том или ином виде это всё существует больше 30 лет. (Помнится, в середине 80-х сам поучаствовал в переделывании фортрановского кода под FPS-164/264 и чуточку под Convex -- это такой мини-крей был).
no subject
Да.
Просто 30 лет назад средний уровень программиста был намного выше чем сейчас - был сильнее отсев, была ниже потребность индустрии.
- Сейчас ввиду большой потребности в некритичном софтвере (всяческие вебсайты, всяческая бизнесовая логика), минимальный уровень среднего программиста сильно снизили - условные пэхэпэшники такой ужас пишут что оно не просто на голову не налазит, а на нем анализаторы падают :)
И эти нынешние 90% большинство уже неспособны не то что оптимизациями заниматься, а и вообще про железо ничего не знают - я уже встречал вполне успешных девелоперов, которые на Си писать не могут вообще - им просто тяжело мозг заставить работать на нужном уровне.
Кстати, я теперь понял, почему в нынешнем компьютер сайнс стали говорить, что "без тесных отношений с хардвером нынешний софтвер выхолащивается" - по всей видимости они как раз про это.
no subject
no subject
Но среднестатистический проект делается вот именно низкоквалифицированными, потому что надо быстро и дешево.
no subject
no subject
А вы можете обоснованно опровергнуть это утверждение?
- Я как раз могу обоснованно это утверждать.