> будет больше шансов, что собранное на альте заработает под

OSL, т.к. альт собирается под _архитектуру_ (например, v4), а OSL -- под _процессор_ (например, e8c)

Фак мой мозг, это кто так решил делать? Наверняка не просто так в OSL сборка точится под процессор. Один и тот же процессор не может быть с разной архитектурой. Зато на одной и той же архитектуре могут быть разные процессоры. Если мы говорим про Эльбрус, который по мнению авторов является программно-аппаратным комплексом, у которого из-за VLIW производительность сильно зависит от учета аппаратных особенностей железяки, то какой смысл в AltLinux скрывать от компилятора информацию о процессоре, и давать только информацию об архитектуре?

Если собирать под определённый CPU, то в заголовке ELF это будет прописано и ядро откажется запускать такую программу на другом CPU. В e2k задержки операций специфичны для каждого CPU (хоть на практике это и редкость). В будущем могут выйти Эльбрусы на одной ISA (допустим e2kv7), но с разными задержками. ПО для одного CPU будет неэффективно исполнятся на CPU с другими задержками.

Вот это новость, я думал, величину задержек определяет версия архитектуры, а не конкретная модель процессора. Но, я так понимаю, сейчас такое ещё не появилось? Кстати, кто-то из МЦСТ говорил, что под 1С+ собирается отдельная версия ядра без поддержки многоядерности, на этом экономится 5-10% производительности. Не знаю, актуально ли что-то такое для прикладного ПО.

Я тоже так думал, до появления Э16С. Очевидно же, что с многопоточностью связаны накладные расходы на синхронизацию. Насколько это актуально для прикладного ПО с определением кол-ва ядер в runtime?

А что произошло, разве у 16С и 2С3 разные задержки есть?

У Э16С и Э2С3 задержка у load 5 (ПЯТЬ!) тактов! :)

Да, но она вроде как должна быть такой у всех v6

Это пока. Гарантий то нет никаких. Вот я и привёл e2kv7.

Хотя да, вдруг в 12С будет что-то необычное, ждём сюрпризов😜

Маловероятно. Тактовая частота такая же. Вот если в МЦСТ будут затачивать микроархитектуру для конкретного применения (мобильное/серверное), тогда возможно что-то.

эти оптимизации (условно под e8c вместо e2kv4) полезны не только в ядре, но на том же e8c их вклад невелик, по нашим замерам; при этом собранный для e2kv4 альт работает и на e2kv5 (или вот спасательная флэшка для v3 -- на всём от v3 до v5), что порой оказывается полезно см. тж. altlinux.org/эльбрус/архитектура#Совместимость

да, для e1cp разница примерно такая

Михаил, мы ждем ваших комментриев по поводу оптимизации рендеринга в Blender: https://t.me/e2k_chat/127624 . Справедливы ли замеры, которые вы показали?

это действительно Eevee (и мне это было понятно); а вот разницу в быстродействии конкретно между Eevee и Cycles я пока выяснить даже не пытался -- для этого стоит на каком-нить стендовом x86-ноуте прогнать 2.80/cycles и 2.92/eevee на той же картинке, думаю

Интересно, насколько патчи ускорили Cycles. Предыдущий замер был именно на нём

Там результаты будут зависеть не столько от x86, сколько от GPU, ибо Eevee - это GPU-шный рендер.

В общем, для честного сравнения достаточно сделать один замер на Cycles

забавно, тогда можно будет ещё поразвлекаться, переткнув из e8c туда RX 580 %) сейчас в 901-РС стоит R7 240 да, про Cycles принято -- осталось научиться то ли его собирать, то ли включать для рендеринга (в выбиралке были Eevee и Workbench)

У R7 240 заявлено 500 GFLOPS на его 320 ядрах (не знаю на какой точности). У Эльбрус-8СВ заявлено 512-570 GFLOPS одинарной точности. То есть пиковая скорость вычислений, по всей видимости, сравнима. Посмотрим, что получится в результате.

Eevee это растеризация, а не трассировка.