Персональные компьютеры Эльбрус-401 готовы к серийному производству

Свои интересные штуки похоронили ещё до ЕС. Был УКНЦ, если верить педивикии, на проце своей архитектуры, но не поехал в массы.

Как и сказано выше, проц - DSP с функциями ЦП

Откуда ваще такие сведения, что это DSP? Можно пруф? Сайт МЦСТ говорит что Эльбрус-2С+ имеет ядра dsp и то не во всех реинкарнациях. Судя по всему 4c и 8c даже близко не dsp.

Откуда ваще такие сведения, что это DSP? Можно пруф?

Они любой VLIW называют DSP, что некорректно, но это на их совести. Просто VLIW позволяет делать дешёвые быстрые вычисление, в отличии от ООО, по-этому ему и отдают приоритет. Эта область не такая инертная как остальные, там можно эволюционировать хоть каждое поколение.

сами запилили, но vendorid - интела (как и ide, как и какой-то девайс ядра)...

http://paste.omsklug.com/1484/raw/ - интересный вывод lspci.

а тесты openssl - на гиктаймсе есть

ХЗ, там очередной наркоман какой-то упоротый. Производительность процессора на глаз по времени загрузки LO с SSD меряет. Там процессор вообще при чем? И видео, разве его там не AMD карточка декодирует? Бред какой-то. Понимаешь, когда люди упорно не хотят приводить результаты простейших тестов обычно причина одна - результаты настолько печальны, что показывать просто стыдно. Иначе почему опять ни одного теста, никаких цифр? В чем проблема взять в сети любой архив и распаковать на время чтобы все могли проверить? Вот поэтому, что цифры луше не показывать.

Пруфы? А то я тут прикупать собрался.

Он не стоит этих денег, соотношение производительность/цена очень плохое. Даже на хороших задачах, он будет хуже x86 из-за низкой частоты.

Но если ты его возмёшь, то при наличии свободного времени, организуй доступ заинтересованных. Вместе вы заполните информационный вакуум, который окутал его.

Так прослойка что такое, когда ты вместо GL функций используешь предоставляемые тебе SDL а он внутри их уже там переводит во что нужно.

Ничего он там внутри себя не переводит, там прямые вызовы OGL-функций из libGL. Разве что на уровне SDL_GL_SwapWindow() что-то делает, но не думаю что страшное что-то. SDL предоставляет лишь фичи по удобному созданию окна приложения с GL-контекстом.

Так вот оно OpenGL использует значит, что в вайне комфортнее играть гораздо.

А ты уверен, что Windows-версия Xonotic, которую ты пускаешь под Wine, использует OpenGL?

https://github.com/xonotic/darkplaces/search?utf8=✓&q=d3d9

Ну и не так он там везде сливает как ты тут кукарекаешь, особенно в частотозависимом 7z

D2500 	E2S-800
1'300 	2'144    7z сжатие, Мбайт/с
24'738 	38'894   7z распаковка, Мбайт/с


i7‑2600 	D2500    	E2S-800
81 / 351 	43 / 79 	32 / 128      AES-CBC 	
78 / 341 	20 / 40 	43 / 170      AES-IGE

частотозависимом 7z

Вообще-то нет, тут ILP большой, по-этому Эльбрус и опережает, со своими 800 МГц, 1.86 ГГц В2500.

В других тестах, где низкий ILP он проигрывает, из-за более низкой частоты.

D2500 хорошо подходит для демонстрации того, что на с высоким ILP Эльбрус работает лучше, на частоте в 2 раза ниже. Конечно до i7 ему далеко, т.к. тот и широкий, и работает на высокой тактовой частоте.

VLIW позволяет сделать 100500 мелких ядрышек, заточенных под определенный тип вычислений (скажем, преимущество дается double float - ок, накачаем double foat блоками), со скромным по сравнению с ОоО архитектурами потреблением. потому и прижился во всяких DSP и прочих специализированных числодробилках.

в то же время из-за большой ширины слова, при низком ILP эффективность вполне может оказаться (и оказывается) ниже чем cisc/risc - из-за более быстрого вымывания кеша (то, что для cisc займет 1-2 байта, для vliw займет целое слово - 8-16 байт, 99% которого будет nop'ами забито). да, в эльбрусе это пытались пофиксить костылем, чтобы все не было вообще уныло, но ценой усложнения кристалла.

и именно потому никому в голову не приходит юзатьтот же blackfin как ЦП. хотя линукс на нем работает...

ну да, не везде, всего лишь в 70% тестов сливается :) подумаешь :)

особенно умиляет бенч постгри с ссд, при том что на других машинах - hdd стоят...

А что, Vliw-процессоры не могут производить внеочередные операции?

VLIW позволяет сделать 100500 мелких ядрышек, заточенных под определенный тип вычислений (скажем, преимущество дается double float - ок, накачаем double foat блоками), со скромным по сравнению с ОоО архитектурами потреблением. потому и прижился во всяких DSP и прочих специализированных числодробилках.

Ты ничего не знаешь про VLIW и ООО.

VLIW позволяет вынести планировщик из ООО в компилятор точка. На этом разница заканчивается. А если планироващик не в аппаратуре, то тебе не надо за 200 пикосекунд планировать использование 16 устройств. Есть некоторые моменты, о которых я уже говорил выше, типо доступа в память, из-за того, что планирование статическое, это накладывает свой отпечаток на VLIW.

в то же время из-за большой ширины слова, при низком ILP эффективность вполне может оказаться (и оказывается) ниже чем cisc/risc - из-за более быстрого вымывания кеша (то, что для cisc займет 1-2 байта, для vliw займет целое слово - 8-16 байт, 99% которого будет nop'ами забито). да, в эльбрусе это пытались пофиксить костылем, чтобы все не было вообще уныло, но ценой усложнения кристалла.

Это не проблема VLIW, а проблема ISA. Могут быть явные nop, могут быть неявные как в Эльбрусе, может быть АД как в x86.

и именно потому никому в голову не приходит юзатьтот же blackfin как ЦП. хотя линукс на нем работает...

Там ещё MMU помнится нет. Но линукс да, работает, я это даже видел вживую.

А что, Vliw-процессоры не могут производить внеочередные операции?

VLIW может делать столько же операций как и ООО. Разница только когда это планирование происходит. В ООО последовательные инструкции раскидывает по устройствам во время работы, на каждом такте, с этим связаны свои проблемы. К примеру ограничение ООО, он не может быть широким. Вы это наблюдаете на примере Intel, производительно которого, в последние лет, этак, 6, растёт исключительно из-за расширения буферов, SIMD, новых инструкций. Он уже близко к своему пределу. В MIPS/SPARC/ARM ситуация лучше, из-за простой структуры ISA, и SPARC T5 уже показывает 8 оп/такт, в то время как Intel всего 4 оп/такт. Дальнейший рост в ширину приведёт к стремительному повышению тепловыделения и снижению тактовой частоты, что приведёт к падению производительности на задачах с низким ILP. По этой причине, и появились многоядерные процессоры, т. к. рост в ширину не возможен.

По этой причине, и появились многоядерные процессоры, т. к. рост в ширину не возможен.

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

доступ заинтересованных. Вместе вы

Я частное лицо, независимый разработчик и гик с нулевым влиянием на отрасль и Сообщество.

тут ILP большой

Да чет не очень большой (Core 2 Quad Q9650):

CPU Freq:  2817  2984  2982  2977  2986  2984  2984  2985  2985

RAM size:    8192 MB,  # CPU hardware threads:   4
RAM usage:    882 MB,  # Benchmark threads:      4

                       Compressing  |                  Decompressing
Dict     Speed Usage    R/U Rating  |      Speed Usage    R/U Rating
         KiB/s     %   MIPS   MIPS  |      KiB/s     %   MIPS   MIPS

22:      10265   343   2907   9986  |     140963   395   3045  12026
23:       9892   351   2870  10079  |     139157   396   3038  12041
24:       9810   361   2922  10548  |     133227   388   3017  11695
25:       9497   364   2981  10844  |     132744   394   2997  11814
----------------------------------  | ------------------------------
Avr:             355   2920  10364  |              393   3024  11894
Tot:             374   2972  11129 

        17'200                            211'282
                             18'781
----------------------------------  | ------------------------------
                      2'662

Судя по приведённым там (на CNEWS) значениям, автор запускал «7z b» и делил результат на количество ядер. Мы публикуем результаты в первозданном виде

И «в первозданном виде» привел какие то обрывки забыв указать у него это что за результат то - с турбобустом или гипертредингом

Откуда ваще такие сведения, что это DSP?

Это мнение двух участников этого топика.

Можно пруф?

Тебе нужно заявление МЦСТ «мы сделали навороченный DSP в духе Hexagon»? Такого заявление нет, конечно.

Сайт МЦСТ говорит что Эльбрус-2С+ имеет ядра dsp и то не во всех реинкарнациях

Хм. Насколько я помню, 2S+ - это именно модификация с 4 дополнительными ядрами DSP. Никакие другие продукты так не назывались. Можно ссылку на 2S+ без DSP-кластера?

Судя по всему 4c и 8c даже близко не dsp.

2S+ - это 2 ядра Э-3М1. Моя догадка состоит в том, что для некоторой задачи (связанной с Т-50) производительности этих ядер в DSP-задачах не хватило, поэтому пришлось добавить кластер из 4 DSP-ядер. Поскольку в 4С и 8С родных ядер больше и частоты выше, там производительности родных ядер хватает, и дополнительный кластер DSP убрали. Или (что, ИМХО, более вероятно) Эльбрусы перестали использовать для задач сигнальной обработки.

Но, повторяю, это мои личные догадки, основанные на сетевых слухах, здравом смысле и личном опыте.

Они любой VLIW называют DSP, что некорректно, но это на их совести.

Если брать зарубежные процессоры, то там VLIW остался только в DSP (ах да, еще в Itanium), так что моя совесть чиста. Ну и зная, для чего изначально разрабатывался Э-3М1, вполне очевидно, что DSP было одним из требований.

Просто VLIW позволяет делать дешёвые быстрые вычисление

Это почти определение DSP.

Core i7-2600 почти в два раза шире чем Quad, плюс разные улучшения микроархитектуры, выше частота. На SMT можешь не смотреть, он ограничивает ширину каждого потока до 2 оп/такт. Это видно на результатах, конечно ситуацию сглаживает работа с памятью.

Ещё лет 300 и выберется совсем. Может быть.

Надо больше молиться.

Хм. Насколько я помню, 2S+ - это именно модификация с 4 дополнительными ядрами DSP. Никакие другие продукты так не назывались. Можно ссылку на 2S+ без DSP-кластера?

Википедия, жеж! https://ru.wikipedia.org/wiki/Эльбрус-2С+

Позже появилась модификация Эльбрус-2СМ без блока DSP, адаптированная для производства на фабрике Микрон в Зеленограде.

Это почти определение DSP.

Так и что плохого в том, что мы вынесем планировщик в компилятор, сделаем ядро в 2 раза шире? Потом возьмём удачный цикл и программно-конвейеризируем его, и покажем в двое лучший результат, чем потенциальный ООО? В каждом подходе есть свои плюси и минусы. Эта отрасль требует огромных капиталовложений, Рынок монополизирован (все мы знаем, что люди думают об процессорах AMD), в такой ситуации сложно начинать с нуля, а тем более пошатнуть гигантов. VLIW не панацея, это иной взгляд на решение известных проблем. Нам предстоит огромный путь, от отказа от ООО, до dataflow подобных архитектур, но я не знаю сколько это займёт времени. А если учитывать движения в сторону специализации (SIMD, GPU, DSP, etc), а не в сторону универсальных вычислителей, то это будет не скоро.

VLIW позволяет вынести планировщик из ООО в компилятор точка.

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

Позже появилась модификация Эльбрус-2СМ без блока DSP

Ну то есть 2S+ - это именно модификация с DSP-кластером. Модификация без него называлась по-другому.

c64x с mmu - но тоже никто его не натягивает на глобус...

ставит крест на производительности в циклах/с условными переходами

man программная конвейеризация циклов
man условное исполнение

ООО может молотить итерацию цикла в 1 такте, только для небольших циклов (не больше ширины декодера), в остальных случаях будет как в VLIW.

ООО может молотить итерацию цикла в 1 такте, только для небольших циклов (не больше ширины декодера), в остальных случаях будет как в VLIW.

Хотя забыл про буфер декодированных инструкций, будет чуть лучше.

Если брать зарубежные процессоры, то там VLIW остался только в DSP (ах да, еще в Itanium)

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

Так и что плохого в том, что мы вынесем планировщик в компилятор, сделаем ядро в 2 раза шире?

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

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

Потому, что Tile это массово-параллельная архитектура, другие задачи, он специализирован для их решения. Ты представь себе, у них коммутация происходит по 2D mesh сети, из-за большого кол-ва ядер. В очередной раз ты демонстрировал своё невежество.

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

А как ты предлагаешь решить задачу роста в ширину? Клепать новые ядра? Или уже стоит переносить программы в аппаратуру?

Уже давно есть идеи, сделать очень простое ядро, но сделать их много, и параллелить задачу на потоки неявно. У нас (человечества) большие проблемы, мы упёрлись в ограничение ООО.

OOO может в предсказание переходов с подготовкой на выполнение команд, которые находятся перед текущим IP (при переходе назад на начало цикла). что для VLIW недостижимо в принципе.

а разворачивание цикла на этапе компиляции/на этапе исполнения - цикл гарантированно не попадает в л1 кеш, и каждое последующее слово выгребается из медленного л2, или даже из вообще тормозной памяти...

и да, почему тогда сейчас никто не использует in-order выполнение в производительных ядрах, если там все так прекрасно? :)

tile - точился под роутинг. и только в роутерах он и существует сейчас. и в роутинге я и сравнивал производительность. там все плохо...

А как ты предлагаешь решить задачу роста в ширину?

Я думаю, что более уместен вопрос «на решение каких задач ориентирован e2k?». Потому что для замены Эльбруса-2 «в московской ПРО» Эльбрус-8С, наверное, отлично подойдет.

Или уже стоит переносить программы в аппаратуру?

Нужно вернуться к старой идее - делать специализированные сопроцессоры. Как minion cores в lowRISC: http://www.lowrisc.org/downloads/lowRISC-memo-2014-001.pdf

И, если под «программы в аппаратуру» имеется в виду FPGA рядом с процессором - тоже вариант.

OOO может в предсказание переходов с подготовкой на выполнение команд, которые находятся перед текущим IP (при переходе назад на начало цикла). что для VLIW недостижимо в принципе.

Ты представь себе, VLIW тоже может в предсказатель. Он тоже может подготавливать конвейер на начало цикла. Это дело конкретной реализации. Вот в Эльбрусе, от этого отказались по началу, а зря. Там подготовленные переходы, что работает аналогично предсказателю. Эльбрус может щёлкать циклы любой длины без штрафа по переходу. Но потом они всё же решили добавить предсказатель, и правильно сделали.

а разворачивание цикла на этапе компиляции/на этапе исполнения - цикл гарантированно не попадает в л1 кеш, и каждое последующее слово выгребается из медленного л2, или даже из вообще тормозной памяти...

Знаешь, на цикле больше 32-64 Кб, уже не важно, есть у тебя предсказатель, или нет. А вообще два. Иди дальше читай, что такое программная конвейеризация, а не разворачивание циклов.

и да, почему тогда сейчас никто не использует in-order выполнение в производительных ядрах, если там все так прекрасно? :)

Потому, что нужна ШИРИНА. In-order такой же тупик, как и ООО. Раньше мы передвигались на телегах, но потом они устарели. Понимаешь аналогию?

Если брать зарубежные процессоры, то там VLIW остался только в DSP (ах да, еще в Itanium)

ну чего же, есть еще тайлера

Всегда считал, что Tilera - это просто сеть MIPS-процессоров. Если не так - значит, еще один живой VLIW, но тоже специализированный (хотя и не на DSP).

Дык я то чего смотри, ты на результат смотри:

MIPS      11129  /* 11129 / 4 : 2782 */
1CPU MIPS  2972

MIPS      18781  /* 18781 / 8 : 2347 */
1CPU MIPS  2662

Я думаю, что более уместен вопрос «на решение каких задач ориентирован e2k?». Потому что для замены Эльбруса-2 «в московской ПРО» Эльбрус-8С, наверное, отлично подойдет.

Тех, что не умещаются в ООО, которые не подходят для SIMD GPU, и тд. В первую очередь Эльбрус интересен, как VLIW, но я не уверен, что он встряхнёт эту область.

Нужно вернуться к старой идее - делать специализированные сопроцессоры. Как minion cores в lowRISC: http://www.lowrisc.org/downloads/lowRISC-memo-2014-001.pdf

Раньше так и делали, привело это к чрезмерному усложнению аппаратуры, а потом был предложен MIPS. Проблема такого подхода, заключается в том, что в итоге у нас будет такая ситуация. Хочешь музыку полушать, купи такой процессор, хочешь видео посмотреть, купи этот процессор. Обновлять такие процессоры вообще нельзя, их прийдёться выкидывать, т. к. они морально устареют. Это тоже тупик.

И, если под «программы в аппаратуру» имеется в виду FPGA рядом с процессором - тоже вариант.

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

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

Это сложные вопросы, но заниматься шапкозакидательством, явно не выход.

А почему нельзя сделать кеш настолько большим чтобы он полностью поглотил цикл или даже несколько образующих ядро функций?

Можно явно указывать, какие куски и куда надо кешировать?
Например слелать два кеша
1)Стабильный для часто вызываемых функуий
2)Мутабельный для остального.

А вот то что в 7z ILP большой - не похоже что то вообще

Хорошо. Как ты объяснишь ситуацию, что Эльбрус с 800 МГц, обгоняет D2500? Разница между ними 1 ГГц и ширина Эльбруса.

Подскажу, ILP.

Нужно вернуться к старой идее - делать специализированные сопроцессоры. Как minion cores в lowRISC: http://www.lowrisc.org/downloads/lowRISC-memo-2014-001.pdf

Раньше так и делали, привело это к чрезмерному усложнению аппаратуры, а потом был предложен MIPS

Эээ... ЩИТО? MIPS был предложен (на рубеже 70-80-х) как средство борьбы с проблемами CISC. А CISC ортогонален использованию периферийных процессоров (в IBM 3[67]0 были специализированные процессоры ввода-вывода, но на этом и всё).

Проблема такого подхода, заключается в том, что в итоге у нас будет такая ситуация. Хочешь музыку полушать, купи такой процессор, хочешь видео посмотреть, купи этот процессор.

Такой ситуации не будет. И для музыки, и для видео уже сейчас достаточно мощности ЦП.

Обновлять такие процессоры вообще нельзя

Зависит от того, как их сделать.

если его подпилить, накормить стероидами и выпустить на современном техпроцессе, тоже можно будет натянуть.

Эээ... ЩИТО? MIPS был предложен (на рубеже 70-80-х) как средство борьбы с проблемами CISC. А CISC ортогонален использованию периферийных процессоров (в IBM 3[67]0 были специализированные процессоры ввода-вывода, но на этом и всё).

MIPS был предложен для упрощения аппаратуры, я его привёл в контексте усложнения аппаратуры специализированными устройствами.

Такой ситуации не будет. И для музыки, и для видео уже сейчас достаточно мощности ЦП.

64 Кб хватит всем? (:

Зависит от того, как их сделать.

Если их делать code-driven то в чём разница между обычным процессором?

Просто атом тормозной, у всех рейтинг ядра (1CPU MIPS) соответствует их частоте, а у атома он при частоте 1600мгц 1000MIPS, у эльбруса просто 4 ядра а у атома 2 поэтому он его и обогнал. Будь там ILP обогнал бы как на шифровании

А вообще у меня есть еще C2D E4400, считается что Э4С примерно соответствует ему (2ггц Core 2 Duo) можно проверить насколько это соответствует действительности.

росто атом тормозной, у всех рейтинг ядра (1CPU MIPS) соответствует их частоте, а у атома он при частоте 1600мгц 1000MIPS, у эльбруса просто 4 ядра а у атома 2 поэтому он его и обогнал. Будь там ILP обогнал бы как на шифровании

А да ты прав, я уже запутался в этих спорах со всеми. Пора сделать перекур.

Просто VLIW позволяет делать дешёвые быстрые вычисление

Это почти определение DSP.

Я не специалист, но мне кажется, что это полная чушь. Любой спор превращается в спор о терминах.

DSP = Цифровой сигнальный процессор. По-вашему, если процессор может за один такт вычислить точку кривой безье, то его можно назвать DSP? Извините, но с какой стати?

А вот кстати вопрос чисто из любопытства: как будут чувствовать себя байткод с JIT на VLIW? как я по-нубски понимаю, им несколько проще в работе набивать маш.слово командами, поскольку есть известная статистика по вероятности ветвлений. Типа сначала долго греемся, набираем информацию для планировщика, потом более-менее полно можем набивать маш. слово командами.

Интерес умозрительный, я в детали архитектур и jit не лазил особо.

Линза в оптике, вообще выполняет фурье преобразование за константное время. Но пока DSP на оптических элементах не видел.