PreScriptum: спасибо за попытку конструктивного обсуждения!> Михаил, я Вам уже много раз писал, до сих пор нет ни
> одного перф-теста, даже выполненого самим производителем.
> Даже на 1 задаче максимально подходящей и оптимизированной.
Вы можете много раз писать что-либо, в чём не понимаете, разумеется.
Это не так.
Попробуйте исправить формулировку.
> Единственно Вы лично с кем-то тестировали производительность архиватора
> уже много лет назад, я бы назвал результаты посредственными.
Да.
> Т.е. да этим уже можно пользоваться
Собственно, мне это на практике и важно (пишу с 801-РС, если что).
> но говорить о производительности на уровне даже не топа, а серединки
> интеловых процов того времени речь не шла.
> Где-то ближе к концу тогдашней линейке.
Заметьте, речь шла про архиватор, который вылизывали для x86, но для e2k вся производительность обусловлена по сути только общим уровнем компилятора.
А случаи бывают разные. Например, если взять старый гостовский хэш и вылизать его под e2k, то между тем самым 300 МГц v2 зеленоградской выделки с пятой приёмкой и 1,5 ГГц core2duo будет даже не паритет, а pwnage последнего (и по оценке компиляторщиков -- интелу пришлось бы сделать конвейер тысячи в полторы команд, чтобы в том случае их машинерия реального времени на чипе смогла конвейеризовать тот цикл).
Ну а за оптимизацию p7zip (и тем более xz) я из своего кармана готов помочь толковому студенту, особенно если он уже учится в Бауманке и может податься в МЦСТ на базовую кафедру ;-) Чтоб ещё быстрее пуляло.
> В таких условиях Ваши заявления как там все хорошо, это как минимум
> не совсем правда.
Именно в таких условиях даже "Ваши заявления, что всё хорошо" -- это почти правда. Если понимать, что "хорошо" -- это "четвёрочка", а не "пять с плюсом".
И особенно если учесть, что _мои_ заявления -- это обычно "в целом хорошо, но хотелось бы javascript побыстрее в браузере" (раза в два для комфортного уровня, если говорить про fx52 на e2kv4). МЦСТ в курсе и говорит, что конкретно там есть ещё большое поле для оптимизации (которая продолжается и результаты видны). UniPro, так понимаю, тоже в курсе.
> А хвастаться битностью регистров и нанометрами, уж лучше хвастаться Ггц
ГГц удобнее всего хвастаться чистому RISC вроде Power, куда неудобнее CISC/RISC вроде x86 (и, сдаётся мне, ARM уже тоже RISC-ом назвать сложно), и уж совсем неудобно VLIW, который берёт как раз в перпендикулярном направлении -- не количеством шагов в минуту, а шириной шага.
VLIW удобно флопсами хвастаться ;-) Другое дело, какая их часть на какой архитектуре вообще типично может быть реализована (интел тут, например, любит себе на FMA или AVX циферки пиковые рисовать, деликатно молча о применимости).
> хотя и то, и другое попугаи, которые для разных архитектур
> ничего не говорят о соотношении производительности.
Не совсем попугаи -- скорее рамки и ориентиры, но действительно не дающие возможности сколь-нибудь надёжно даже "больше-меньше" спрогнозировать сами по себе.
> Я бы сказал, что рост частоты до 1,5Ггц это очень мало
А переход от VLIW25 к VLIW50?
> при улучшении техпроцесса до 28нм.
Техпроцесс у 8С и 8СВ один и тот же -- 28 нм. По сути 8СВ -- постепенное улучшение 8С в направлении суперкомпьютерных вычислений (в терминологии Intel это цикл "тик", насколько понимаю).
> У других при таких условиях увеличение Ггц мыло гораздо существеннее
> чем с 1,2(3) до 1,5.
При каких именно условиях? Так понимаю, что Вы предположили изменение нормы техпроцесса (что на v4->v5 не так). Для перехода v3->v4 оно было -- с 65 нм на те самые 28; при этом частоту подняли с 800 МГц до 1300 МГц. А сейчас её удалось поднять дальше не за счёт техпроцесса, а за счёт оптимизации раскладки регистрового файла -- насколько понимаю, это самое уязвимое к высоким частотам место в VLIW-архитектурах и его наконец вместо фабричных элементов развели руками (custom design). По идее, и разгонный потенциал от нынешних 1600 МГц подрастёт.
> Так что подозреваю, что отсутствие тестов реальных не только потому что им
> это не нужно, а потому как надувать щеки уже не получится.
Реальные тесты производятся с реальными заказчиками, а также в процессе работы над оптимизацией того же JS JIT или Postgres. То, что даже они не долетают на публику -- это в чистом виде недоработка МЦСТ (конкретно отдела маркетинга) и их добровольных помощников вроде меня. Всё, что у меня сейчас на публике есть -- это набросок странички http://altlinux.org/эльбрус/тесты и несколько замеров, приведённых по ссылкам оттуда. Что-то делают в яндекс-музее (в основном по 3D и сразу с апстримами). И им, и нам наверняка можно помочь, имея умение и желание.
> А когда щеки пытается надувать не манагер, который за это деньги получает,
> а технарь, то это уже позор.
Посмотрите вот этот рассказ "манагера, который за это деньги получает", и найдите отличия с самыми толковыми технарями, которых вообще найдёте в своей эпсилон-окрестности: http://0x1.tv/20181012BB (или http://youtu.be/_botdMGe2oY) :-)
У МЦСТ "проблема" не с технарями, а как раз с надуванием щёк -- некому, люди работу работают по надцать часов в сутки.
> Ну или перестаньте делать вид, что все еще технарь, многие с возрастом
> становятся манагерами, это надо просто честно признать.
Здрасьте, я двадцать лет как технароманагер, тоже мне секрет. "Но крашу, крашу я заборы, чтоб тунеядцем не прослыть" :-)
PS: по ТТХ см. вкладки "Характеристики" на страничках:
http://mcst.ru/elbrus-4c
http://mcst.ru/elbrus-8c
http://mcst.ru/elbrus-8cb
