В ответ на мою статью про тупиковость развития линейки процессоров Эльбрус в качестве базовой платформы для отечественных general-purpose CPU, пользователь @alexanius (Алексей Маркин) написал свою статью-ответ, где привёл возражения моим тезисам. Дабы не превращать дискуссию в формат форумной перепалки, я попытаюсь структурировать изложенные возражения, максимально опустив малозначимые на мой взляд детали и не относящиеся к делу реплики. Также мы оставим на совести Алексея некорректные высказывания и переходы на личности. Это мишура, которая не поможет нам глубже понять суть проблемы.
Итак, если суммировать, то в моей статьей были приведены следующие недостатки Эльбруса:
Слабость программной экосистемы в силу того, что архитектура очень узко используемая и нераспространённая.
-
Проблема принципиального проигрыша RISC/CISC системам по производительности ввиду:
Более низких тактовых частот дизайна VLIW процессоров
Более низкой производительности микроархитектуры из-за отсутствия динамического планирования операций
Дополнительного снижения производительности реальных приложений из-за сложности реализации компиляторных оптимизаций для Эльбрус
Трудоёмкость разработки под архитектуру Эльбрус, ввиду высокой сложности ассемблера широкой команды и необходимости постоянно проводить анализ кода и его изменение для достижения приемлемых цифр производительности (в Эльбрусе без этого никак, т.к. здесь если компилятор не справился, то аппаратура не подстрахует. А не справляться компилятор будет постоянно по вполне объективным причинам)
Также во второй статье я упомянул про проблемы лицензионной чистоты архитектуры Эльбрус. Но т.к. этого не было в первой статье, плюс ситуация до конца непонятна, то мы будем трактовать данный пункт в положительном для МЦСТ ключе и далее не рассматривать.
Итак, давайте пройдёмся по тексту от @alexanius и по каждому из данных пунктов посмотрим, действительно ли приведённые им аргументы меняют картину.
Слабость программной экосистемы
Какие возражения были приведены в по данному вопросу?
В момент продвижения архитектуры ARM все дружно двинулись переносить своё ПО на него, никто не говорил, что собственная архитектура — это плохо. Сейчас в Европе активно продвигается RISC-V, но никто не плачет о новой несовместимой архитектуре — все дружно берут и переносят своё ПО. Но почему-то как только речь заходит про архитектуру Эльбрус, сразу начинаются стоны о том что своё — это плохо и сложно
В этих рассуждениях мне видится два важных момента. Первый – это фундаментальное непонимание причин того, почему «все дружно берут и переносят своё ПО». Второй (как следствие первого) – это назначение в качестве виноватых разработчиков софта, которые не хотят портировать софт на Эльбрусы.
Алексей, дело в том, что в жизни всё устроено так, что если люди или предприятия заинтересованы в портировании софта, если аппаратная платформа удобна и удовлетворяет их требованиям, если им это выгодно – то они берут и портируют. А если предлагаемая платформа даже недоступна в свободной продаже, если система команд закрыта, если в свободном доступе нет нормальных отладчиков, симуляторов, профилировщиков и прочей базовой программной экосистемы, и всё вышеизложенное – это принципиальный подход компании-производителя процессора, то люди даже при всём желании не смогут эффективно заниматься процессом портирования. Поэтому, при возможности выбирать, портировать на Эльбрус или, допустим, на Arm или RISC-V, люди будут очевидно выбирать второй вариант. И одна из главнейших причин этого – политика компании МЦСТ.
На текущий момент в нём портировано более 14500 пакетов
Это прекрасно, но это мизер по сравнению с теми же ARM или RISC-V. Для RISC-V, которая фактически ещё находится в стадии своего зарождения, уже портированы популярные дистрибутивы Ubuntu, Debian, Fedora с десятками тысяч пакетов каждый, сделана поддержка в Qemu, gcc, lllvm, OpenJDK, v8 и т.д. и т.д. Т.е. уже создана экосистема, на порядок превосходящая Эльбрусовскую. В случае ARM разрыв ещё более драматичный.
А теперь вспомним что существует ПО без исходного кода, которое способно запускаться только на x86 машинах. Процессоры Эльбрус такое ПО запускать умеют. Могут ли другие не-x86 процессоры похвастаться этим же?
Простим автору его неинформированность. Система бинарной трансляции не является уникальной возможностью процессора Эльбрус. Для Arm существуют как минимум Rosetta 2 и ExaGear. Qemu имеет хоть и медленный, но зато поддерживающий широкий спектр host-архитектур движок бинарной трансляции.
Собственно видно, что высказанные Алексеем возражения не опровергают тезиса о слабости экосистемы Эльбрус и сложности её создания для новой архитектуры. Они по сути констатируют данный факт, но просто пытаются описать текущую ситуацию в чуть более розовых тонах и назначить за неё виновных в лице разработчиков софта.
Проблема принципиального проигрыша Эльбрусом по производительности RISC/CISC процессорам
Частота
Для начала кратко обговорим вопрос с частотой. На моё утверждение, что VLIW принципиально уступает по частотам RISC/CISC, Алексей заявляет следующее:
Не знаю на кого рассчитана эта фраза с учётом, того что в той таблице нет других процессоров с теми же нанометрами (только Эльбрус другой линейки). И нет, из этой таблицы нельзя сделать вообще никаких выводов — чистая манипуляция
Эта фраза рассчитана на тех, кто умеет внимательно читать. В таблице приведено сравнение различных VLIW архитектур (Итаниум и Эльбрус) с аналогами RISC/CISC, разработанных на таких же техпроцессах в одних и тех же компаниях. И везде видно, что VLIW решения всегда своим конкурентам уступают по частоте. И у этого есть вполне определённая причина – особенности архитектуры у VLIW-процессоров. А конкретно для Алексея вопрос можно переформулировать следующим образом – почему Эльбрус(e2k), который постоянно выставляется как главный процессор от МЦСТ и в который вкладываются основные разработческие ресурсы, уступает по частоте процессорам линейки Sparc от МЦСТ, в которые всегда вкладывались намного меньше? Т.е. дело не в деньгах и нанометрах, а в принципиальных ограничениях VLIW-архитектур.
В конце концов, в МЦСТ есть профильные специалисты, которые вполне профессионально могут ответить на вопрос, а какие предельные частоты достижимы на Эльбрусах семейства e2k? Я могу оценить эту цифру в диапазоне 2.5-3 ГГц. Но было бы здорово, если эксперты прокомментируют данный вопрос. Напомню, что топовые x86 процессоры преодолевают отметку в 5 Ггц.
Микроархитектурная скорость и снижение производительности на реальных задачах
Теме микроархитектурной скорости уделена большая часть статьи. И наверное, это главный предмет для обсуждения. Сначала, для опровержения утверждения о более низкой микроархитектурной скорости VLIW по сравнению с ОоО процессорами,оппонент приводит много академических рассуждений о способностях компилятора решать упомянутые мной проблемы:
В области разработки компиляторов существует целое направление, занимающееся решением именно этой проблемы — анализ указателей
Получается ли разрывать зависимости на практике? Да, получается, много где. Более того, в Эльбрусе разрыв зависимостей возможен не только во время компиляции, но и во время исполнения. Одним из таких механизмов является DAM, позволяющий аппаратно разрывать зависимости, которые не смог порвать компилятор
И снова неверное утверждение. Точнее, верное только отчасти. Подстановка вызовов (inline) действительно является одной из важнейших оптимизаций, и не только для VLIW архитектур, а вообще для всех. Только вот компилятор вполне способен определить горячие участки с неплохой вероятностью, и в дальнейшем их оптимизировать
Даже не знаю что тут сказать. Очень хотелось бы таких примеров из реальной жизни, а не из синтетического примера
И в итоге заключает:
только вот в реальной жизни как раз всё обычно весьма неплохо
В приведённых аргументах отсутствуют какие-либо цифры или примеры, поэтому стороннему читателю трудно понять, насколько всё вышесказанное действительно работает. И главное – тут опять-таки отсутствует опровержение того факта, что статическое планирование – это проблема. И все рассуждения лишь о том, как данную проблему уменьшить в каждом конкретном случае, но не решить её.
Как говорится, вместо тысячи слов – дайте код. Давайте воспользуемся любезно предоставленным Алексеем godbolt сервером и просто посмотрим, что происходит в реальности. Я зашёл в гугл, набрал в поиске «сортировка вставками github» и скопировал код с первой же ссылки в окно godbolt-сервера (только увеличил ARRAY_SIZE до 100000 для удобства запуска):
#include<stdlib.h>
#include<stdio.h>
#define ARRAY_SIZE 100000
void fill_random(int*a)
{
for(int i=0;i<ARRAY_SIZE;i++)
{
a[i]=rand();
}
}
void Sort(int*a)
{
int t, // временная переменная для хранения значения элемента сортируемого массива
p; // индекс предыдущего элемента
for (int c = 1; c < ARRAY_SIZE; c++)
{
t = a[c]; // инициализируем временную переменную текущим значением элемента массива
p = c-1; // запоминаем индекс предыдущего элемента массива
while(p >= 0 && a[p] > t) // пока индекс не равен 0 и предыдущий элемент массива больше текущего
{
a[p + 1] = a[p]; // перестановка элементов массива
a[p] = t;
p--;
}
}
}
void print_array(int*a)
{
for(int p=0;p<ARRAY_SIZE;p++)
{
printf("%d \n",a[p]);
}
}
int main()
{
int*array=(int*)malloc(ARRAY_SIZE*sizeof(int));
fill_random(array);
print_array(array);
Sort(array);
print_array(array);
system("pause");
return 0;
}Выставил в качестве компилятора e2k lcc 1.26.04, опции оптимизации -O4.
Итак, что же у нас получилось? Пытливый читатель может в качестве тренировки зайти на сервер и самостоятельно оценить легкость восприятия e2k-ассемблера. Я же приведу здесь выжимку. В данном примере основной код, определяющий производительность теста – это внутренний цикл while в алгоритме сортировки (функция Sort). Для Эльбруса он выглядит вот так:
.L619:
{
nop 2
disp %ctpr1, .L636
ldw,0 %dr10, %dr3, %r0
}
{
nop 2
cmplesb,0 %r0, %r5, %pred0
}
{
ct %ctpr1 ? %pred0
}
{
disp %ctpr1, .L619
subs,0 %r4, 0x1, %r4
stw,2 %dr10, %dr3, %r5
subd,3,sm %dr3, 0x4, %dr3
stw,5 %dr7, %dr3, %r0
}
{
nop 3
cmplsb,0 %r4, 0x0, %pred0
}
{
ct %ctpr1 ? ~%pred0
}Что мы видим? Одна итерация основного цикла занимает 13 тактов. В нём 9 семантически полезных инструкций (остальные – это специфика Эльбруса, не влияющая на реальное IPC). Т.е. IPC составляет 0.69 инструкций в такт. Эффективность использования широкой команды в данном случае очевидна – она крайне низкая. Никаких разрывов зависимостей не произошло, DAM не применился, но зато произошёл абсолютно бессмысленный инлайн функции Sort в функцию main.
Превентивно закрою здесь все дальнейшие рассуждения на тему «но здесь же есть пересечение между load и store, поэтому там что-то не применилось!». В любом минимально реалистичном коде возникают такого, и даже более сложного рода проблемы. Здесь мы имеем практически идеальный для Эльбруса случай – никаких сторонних модулей, 40 строчек кода, регулярный проход по массиву. И даже в таком простейшем по факту случае статический анализ не смог создать оптимальный код.
А что же происходит, например, на x86? Код основного цикла из под gcc 7.5.0 (на новых версиях gcc там вообще векторизация включается, поэтому я использовал для более равного сравнения немного более старую версию):
.L8:
mov edx, DWORD PTR [rax]
cmp edx, ecx
jle .L7
mov DWORD PTR [rax+4], edx
mov DWORD PTR [rax], ecx
sub rax, 4
cmp rsi, rax
jne .L8В основом цикле 8 инструкций, одна итерация занимает ~3 такта, IPC 2.67 (проверено на Intel(R) Core(TM) i5-7500 CPU @ 3.40GHz)
В итоге, микроархитектурная скорость исполнения данного кода на x86 превышает Эльбрус в 13/3 = 4.33 раза. Т.е. во столько бы раз проиграл Эльбрус, будь он по частоте сопоставим с топовыми RISC/CISC системами.
В общем, чего стоят все рассуждения об анализах на разрыв зависимостей, DAM’ах, способности определить горячие участки по эвристикам и сделать качественный инлайн, читатель может судить самостоятельно.
Пойдём далее.
Вообще, когда говорят о производительности ВК (вычислительных комплексов), существуют общепризнанные тесты, на результаты которых принято ссылаться. Например, ни один профессионал не сошлётся на результаты теста drystone или whetstone — его просто на смех поднимут. Если мы говорим про производительность на широком круге задач, то не существует набора тестов лучше чем SPEC CPU 2017 или его более старой версии 2006 года
Обсуждение проблемы профессионализма с сотрудниками компании МЦСТ можно начинать с вопроса публикации результатов всевозможных бенчмарков. Для примера, вот как это сделано у ваших коллег из Байкал Электроникс. А от МЦСТ для Spec CPU 2017 мы видим 2 цифры без указания каких-либо подробностей вообще, полуподпольно напечатанных в статье-ответе. Но т.к. нам не остаётся ничего другого, будем отталкиваться от тех значений, которые были приведены.
Из результатов следует что Эльбрус 2016 года выпуска с частотой 1300 МГц работает быстрее Байкала 2019 года выпуска с частотой 1500 МГц
Точнее, Spec CPU 2006 и Spec CPU 2017 работают быстрее на Эльбрусе, чем на Байкал-М. Но мы с вами давайте посмотрим на вопрос производительности чуть более широко. Я взял цифры из данной статьи за основу и поправил их исходя из уточнённых данных от Алексея и отчёта Байкал Электроникс. Там, где новых данных нет, всё оставил как есть:
Тест |
Байкал-М |
Эльбрус-8СВ |
Dhrystone [DMIPS] |
8759 |
9077 |
Whetstone [MWIPS] |
2055 |
2269 |
Whetstone MP [MWIPS] |
16477 |
16495 |
Linpack 100 [MFLOPS] |
1012 |
1723 |
Scimark 2 [Composite score] |
473 |
908 |
Coremark (1T;MT) |
8280; 66195 |
5500; 43008 |
MP MFLOPS |
49788 |
381326 |
HPL [GFLOPS] |
38 |
110 |
7zip (Comp; Decomp) (MT) |
9064; 11557 |
8461; 13638 |
STREAM (Copy; Scale; Add; Triad) [MB/s] |
12315; 12061; 11064; 11529 |
23097; 23137; 25578; 25643 |
SPEC 2006 INT |
56.7 |
102.55 |
SPEC 2006 FP |
55.7 |
122.25 |
SPEC 2017 INT |
7.92 |
10.68 |
SPEC 2017 FP |
8.01 |
16.55 |
Blender (RyzenGraphic_27) [min:sec] |
2:47 |
2:32 |
StockFish [nodes/sec] |
2750526 |
3123190 |
Octane 2 |
8253 |
2815 |
Sunspider 1.0.2 [ms] |
977 |
2394 |
Kraken 1.1 [ms] |
4669.3 |
8714.2 |
Что мы видим? Эльбрус существенно выигрывает у Байкал-М на тестах, на которых важна работа подсистемы памяти. Это вполне объяснимо, т.к. в Эльбрусе, чтобы нивелировать недостатки микроархитектуры ядра, приходится делать акцент на улучшении подсистемы памяти, увеличивая размеры кэшей, количество load/store операций исполняемых процессором за такт, количество каналов памяти. И не забываем, что в конце концов, Эльбрус – это изначально серверный процессор, с TDP в районе ~90 Вт, тогда как Байкал-М основан на ядре для мобильного рынка и его TDP составляет ~30Вт.
На тестах Javascript Эльбрус существенно проигрывает Байкал-М. Опять-таки, очевидно почему – разработать хороший JS компилятор для VLIW-архитектуры задача сложная и трудоёмкая. Результат тут, как говорится, налицо (и вдогонку к вопросе об экосистеме).
А вот со счётными бенчмарками интереснее. На простеньком Coremark Эльбрус умудрился существенно проиграть. Dhrystone/Whetstone/Blender/7zip показывают примерно одинаковые результаты. И только на Spec CPU 2006 / Spec CPU 2017 результаты Эльбруса в 1.5-2 раза выше. Но собственно, именно к этому факту мной было сказано, что цифры для Spec CPU 2006/2017 вылизывались на компиляторе многие годы. И в реальности они показывают ту пиковую производительность, которую можно на Эльбрусах достичь. Но проблема в том, что для бОльшей части остального кода такие показатели будут недостижимы, т.к. компиляторные эвристики и опции, заточенные на Spec CPU 2006/2017, там будут работать существенно хуже. В то время как для тех же RISC/CISC архитектур с ОоО разница между «наоптимизированными бенчмарками» и кодом из реальной жизни будет существенно ниже. Что мы, собственно, и видим в табличке.
Поэтому утверждение, что даже Эльбрус-8СВ работает быстрее, чем Байкал-М, надо воспринимать с оговорками.
Теперь давайте всё же разберёмся со Spec CPU 2017 и микроархитектурной скоростью, которую на ней показывают различные процессоры. Помним, что это – лучший бенчмарк для Эльбруса.
Ещё раз обращу внимание на эту хитрую манипуляцию: автор не привёл ни одного сравнения с российскими процессорами. Более того, даже с импортными процессорами сколько-нибудь адекватные сравнения отсутствуют
Во-первых, целью моей статьи не было сравнение российских процессоров. То, что сейчас Эльбрус-8СВ обыгрывает по сути единственного конкурента Байкал-М (и то далеко не всегда, как мы уже увидели) само по себе мало о чём говорит. МЦСТ почти уже 30 лет разрабатывает high-performance GP CPU и бОльшую часть времени было практически единственным российским разработчиком в данной нише. Но в итоге оказалось, что первый же конкурент - компания Байкал Электроникс, которая имела нулевой опыт создания процессоров, но зато имела сложности с лицензиями, финансированием, управлением из-за проблем владельца, набила кучу шишек первого продукта, за несколько лет выдала чип, который конкурентен чипам от МЦСТ. В данный момент тот же Байкал Электроникс готовит к выпуску процессор Байкал-S, как раз предназначенный для серверного рынка. Можно грубо прикинуть производительность будущего чипа. Если Байкал-М основан на ядре Cortex-A57, то Байкал-S будет основан на Cortex-A75. С учётом роста частоты и микроархитектурной производительности, одно ядро добавит где-то в 2-3 раза Spec Rate на Spec CPU 2017. А увеличение количества ядер до 48 увеличит суммарный Spec Rate ещё примерно в 6 раз. Т.е. итоговый Spec Rate для Байкал-S будет где-то около 100 (и для SpecINT, и для SpecFP), или даже выше. А конкурент от МЦСТ новый Эльбрус-16С от текущих цифр Эльбрус-8СВ прибавит лишь 2.67 в максимуме ( В 1.33 раза вырастет частота и в 2 раза количество ядер). Итоговый Spec Rate будет в районе 28 для SpecINT и 44 для SpecFP. Вот и вся история. И причина этого в том, о чём была написана моя первая статья.
Во-вторых, спрашивать сравнение с импортными процессорами достаточно странно, потому что ситуация там абсолютно катастрофична для Эльбруса. Но если кому-то хочется мазохизма - пожалуйста. Вот ссылка на официальные результаты бенчмарка Spec CPU 2017 для различных систем. Если мы говорим про максимальные цифры, то там есть системы со значениями больше 1000 (и для SpecINT, и для SpecFP). Для 8-ми ядерных систем (как Эльбрус-8СВ) средние значения колеблятся в районе 70-80 для SpecFP и 50-60 для SpecINT, для топовых систем подбираясь и переваливая за 100. Например, результат ASUS RS520A-E11(KMPA-U16) Server System 3.70 GHz, AMD EPYC 72F3 составляет 98 для SpecINT и 124 для SpecFP. Напомню, для Эльбрус-8СВ эти цифры 10.68 и 16.55 соответственно. Т.е. в 9 и 7.5 раз меньше на САМОМ лучшем для Эльбруса бенчмарке.
На основе имеющихся результатов Spec CPU 2017 можно, кстати, достаточно хорошо оценить микроархитектурную скорость современных RISC/CISC процессоров. Она колеблется в среднем в диапазоне 2-3 SpecRate на один гигагерц одного ядра, переваливая за 4 для SpecFP для топовых решений (как для приведенного выше решения на базе AMD EPYC 72F3). Для Эльбруса же эта микроархитектурная скорость равна 0.9 для SpecINT и 1.4 для SpecFP.
По итогу мы видим, что микроархитектурная скорость процессоров Эльбрус в 3-4 раза уступает современным серверным CISC-процессорам топового класса. Заметьте, эта оценка достаточно хорошо совпадает с той цифрой, которую мы получили на реальном коде с сортировкой вставками. И это ЛУЧШИЕ примеры для Эльбруса. А в реальной жизни будет множество кода, где эти значения будут ещё хуже. Т.е. даже если теоретически решить частотные проблемы Эльбруса, он будет всё равно в разы проигрывать RISC/CISC конкурентам.
Мне кажется, после приведённых цифр и примеров, вопрос о проблемах микроархитектурной скорости Эльбруса можно закрыть – она катастрофически уступает RISC/CISC аналогам.
Осталось только разобрать следующий пример:
Ну что ж, давайте посмотрим реальные проекты. Вот из свеженького: «По результатам тестов можно сделать вывод о том, что процессор «Эльбрус-8СВ» успешно решает задачу построения системы хранения данных и позволяет получать достойные результаты на HDD
Я сэкономлю время читателей и скажу кратко – приведённый тест FIO предназначен для измерения скорости работы с дисками. Производительность данного теста упирается в скорость работы самих дисков, их микроконтроллеров и подсистемы памяти процессора. Реальная вычислительная производительность процессорного ядра там неважна. Для специализированных решений для дата-центров разрабатывают системы на нишевых in-order процессорах, которые там отлично справляются. Ну и показательно, что нам сначала рассказывали про то, что Spec CPU 2006/2017 это самый показательный бенчмарк. Но когда дошло дело до сравнения, тут оказался почему-то не Spec CPU 2006/2017, а FIO.
Трудоёмкость разработки под архитектуру Эльбрус
Мне кажется, всё вышеизложенное достаточно ёмко описывает, какова трудоёмкость разработки под Эльбрус – она существенно выше, чем для RISC/CISC архитектур. И ввиду сложности кода ассемблера для понимания (godbolt в помощь), и ввиду сложности компилятора и необходимости постоянного анализа кода и настройки опций.
Что же касается данного высказывания:
Я бы мог много написать про то, что программистам неплохо бы разбираться в компьютерах
Я могу сказать, что можно считать что угодно. Но пользователи скорее оценят архитектуру с простым и понятным кодом, даже простив ей некоторый проигрыш по производительности, чем сложную и запутанную, для которой программистов будет не сыскать днём с огнём.
но пожалуй остановлюсь на том, что автор не в курсе вектора разработок МЦСТ, и одно из направлений — это как раз отчёт о применении оптимизаций для помощи пользователю
Это абсолютно бесполезная вещь для пользователя. Вы просто в очередной раз тратите своё время впустую.
В заключение, я бы хотел прокомментировать пару тезисов из статьи Алексея, не упомянутых выше, но мимо которых мне всё же сложно пройти.
На практике проблемы с подстановкой функций будут встречаться, если вызываемая в горячем коде функция располагается в другом модуле, и компилятор не видит её тело. Что ж, я за такой код бил бы линейкой по пальцам независимо от целевой платформы
Алексей, когда вы выйдете за стены МЦСТ и обнаружите за ними реальный мир, то вы поймёте, что делать такого рода заявления - это расписаться в собственном непрофесионализме. Потому что код пишут не только великие гении и победители ICPC, а множество людей, куда менее искушённых в программировании (и таких абсолютное большинство). Потому что в крупном проекте определить какой код при какой нагрузке становится горячим зачастую непросто и требует много усилий по анализу, на которые часто просто нет времени. И хороший процессор должен уметь исполнять с приемлемой производительностью и качественный код, и не очень.
И как же так получилось что у энтузиастов поднят godbolt сервер с компилятором, в музее Яндекса стоит машина со свободным доступом к ней, а получить удалённый доступ можно практически свободно, зайдя в эльбрусовский чатик? Я уже не говорю про такие шедевры как любительский ютуб канал с запуском игр на Эльбрусах
Люди спрашивают про свободный доступ к машинам. Про открытие системы команд. Про открытый качественный тулчейн для разработки. А в ответ получают предложение зайти в чатик и на любительский ютуб канал. И самое печальное, что сотрудники МЦСТ действительно считают такую ситуацию нормальной.
Думаю что на основе всего выше сказанного я поставлю под сомнение это утверждение
Вы пытаетесь поставить под сомнение не просто вышесказанное, а мнение, сложившееся у экспертов в индустрии. Например, Линуса Торвальдса, Хеннеси и Паттерсона, и даже отец Эльбруса Б. Бабаян соответствующе высказался по поводу VLIW:
Мы думали: ну, сделать 32 цуга – и будет у нас настоящий параллелизм! Но я допустил тогда ошибку. Я подумал, что это очень сложно, а ведь есть подход попроще – подход широкой команды. Ну мы и решили его попробовать. Ведь мы тогда минусов не знали этой широкой команды…
В итоге, мы сделали широкую команду. Но не такую, как в Itanium. Itanium – это тоже полное, так сказать, недоразумение. Потому что по ширине он такой же, как суперскаляр: 6 команд. И при этом использует статическое планирование. Почему он должен быть быстрее, чем суперскаляр? Не понимаю
Тупиковость развития VLIW-архитектур для general-purpose CPU стала понятна экспертам в индустрии ещё в середине 2000-х(а некоторым возможно и раньше). И много людей в самом же МЦСТ также прекрасно понимали (и понимают) проблему.
Резюмируя - техническая сторона вопроса в статье изложена, ссылки на мнение авторитетных людей приведены. Если у кого-то ещё оставались сомнения по поводу выводов, сделанных в моей первой статье, надеюсь, теперь они будут окончательно развеяны.
Комментарии (632)
Jetmanman
06.09.2021 08:16+8Да, не зря такие компании как Интел тратят каждый год миллиарды долларов на разработку процессоров. Видимо они пришли к тому, что имеют путем реального опыта при использовании интеллектуального труда лучших специалистов в мире так еще и затрачивая миллиарды. Думаю при возможности они также могли бы параллельно разработать лучшую архитектуру процессора, если бы это было возможно, что возможно и было сделано не однократно.
Вообще, вместо споров лучше просто приводить сравнения близких по нанометрам, тдп и транзисторам(и прочим основным параметрам) процессоров и сразу станет ясно кто прав и эти сравнения уже были на хабре не в пользу Эльбруса.
Pyhesty
06.09.2021 11:01+5интел тащит за собой весь багаж совместимости x86... что может в итоге его и утопить (остановить развитие архитектуры по производительности), но в то же время именно совместимость с предыдущим софтом и привело к доминированию x86 архитектуры в начале гонки и убрало всех конкурентов, напомню, что изначально х86 была открыта до 80486 (или даже до пентиума, не помню точно)...
Sheti
11.09.2021 19:55+1Со временем совместимость уменьшается. Некоторые редкие команды убирают. Но в общем случае совместимость конечно есть. Но не стоит забывать о целой пачке расширений.
Armmaster Автор
06.09.2021 11:45+7В контексте VLIW у Интела была показательная история - Итаниум. Туда были вложены огромные ресурсы, которые в итоге себя не оправдали. Так что опыт Интел подтверждает то, что написано в данной статье.
Coocos
06.09.2021 12:32+5У Интел также был x86, в который было вложено еще больше средств. А еще был у АМД мегакостыль пол названием amd64, который прижился.
bolk
06.09.2021 15:41+1Но ведь процессоры VLIW существуют (не знаю насколько коммерчески успешны). Получается у них есть какая-то ниша, просто Эльбрус лезет не в ту?
amartology
06.09.2021 16:21+6VLIW — это хорошая технология для видеокарт и DSP. И в этих нишах VLIW активно и с большим успехом применяется.
edo1h
06.09.2021 17:08+6я нашёл два применения в видеокартах — radeon и adreno. и там, и там от vliw ушли в итоге.
Arioch
07.09.2021 14:45на Радеоне ушли в том числе по причине всяких там шейдеров, OpenCL и прочего GPGPU - то есть ползучего многолетнего проникновения General Purpose Сomputing в видеокарты. Слегка любопытно, а что было "унутре" GeForce и Riva до появления CUDA.
Civil
06.09.2021 16:24Можете перечислить VLIW-процессоры общего назначения, которые вы знаете? А потом сможете перечислить все живые VLIWы какие знаете? Собственно в этих перечислениях и будет ответ на ваш вопрос.
unv_unv
09.09.2021 07:01Вы в статье приводите ссылку на Бабаяна. Так там Бабаян поясняет, почему Itanium не взлетел — потому что мог в параллель выполнять лишь 6 команд, как и суперскалярные процессоры Intel и AMD. Но, в отличие от них, требовал статического планирования. Соответственно, не мог с ними конкурировать. И дальше Бабаян поясняет, что потому в Эльбрус и была заложена потенциальная возможность исполнять по 20+ команд за такт.
Ну и вы ссылаетесь на то, что Бабаян был в курсе, что VLIW-архитектура не оптимальна. Но там он прежде всего рассуждает, что суперскаляр не оптимален, что достиг своего предела. Что поэтому они сделали VLIW, который тоже не оптимален. А оптимален явный параллелизм, который надо теоретически прорабатывать — причём это потребует не только другой архитектуры железа и других операционных систем, но и других языков программирования.
cepera_ang
09.09.2021 08:17+1причём это потребует не только другой архитектуры железа и других операционных систем, но и других языков программирования.
Которых у нас нет и не будет. Чтобы в это поверить достаточно посмотреть как люди цепляются за свой С(++) на "низком" уровне и чихать хотели на устройство компьютера, на верхнем. Явный параллелизм у нас и так есть — ГПУ есть в каждом компьютере, и что? Много у нас разработчиков под это дело?
VlK
09.09.2021 09:42Явный параллелизм у нас и так есть — ГПУ есть в каждом компьютере, и что? Много у нас разработчиков под это дело?
Вся индустрия больших игр? Специалисты по машинному обучению?
Как только выяснилось, что можно решать задачи линейной алгербы, так сразу специалисты и появились. С GPU вопрос только один: как данные запихать в матрицы. Шейдеры - тоже дело довольно известное.
Это не React/Javascript/Typescript, но всякий любопытный программист хотя бы пробовал соответствующие инструменты.cepera_ang
09.09.2021 10:51+1Индустрия больших игр и разработчики машинного обучения — это и есть "немного", может 1% от общего числа программистов. К тому же, даже в играх непосредственно в ГПУ код лезет лишь малая часть от всех разработчиков, большинство берут условную Юнити и вперед. А про машинное обучение и не говорю — миллионы используют готовый пайторч/тензорфлоу, а как он делает свою параллельную магию на ГПУ — знают и пишут дай бог тысяча человек.
И последний пример в качестве гвоздя в "принципиально новую архитектуру железа и языков, надо только найти программистов" — доминирование CUDA среди озвученных выше специалистов по машинному обучение — даже если какой-нибудь AMD ROCm в теории ничем не хуже, но зачем мне даже потенциальные проблемы (и куда идти за помощью если что?), если на куде работает всё и все? Что уж говорить про какой-нибудь совершенно новый процессор со своими языками и операционными системами — мертвый случай.
VlK
09.09.2021 11:27Индустрия больших игр и разработчики машинного обучения — это и есть "немного", может 1% от общего числа программистов.
Вы недооцениваете масштаб индустрии!
1% от всех программистов это уже достаточно много. 2% - крупная ниша. 3% полноценная ветвь индустрии. На хабре полно людей, которые имели дело с играми, машинным обучением или векторными инструкциями, в том числе ваш покорный слуга.
доминирование CUDA среди озвученных выше специалистов по машинному обучение
Ну так это и есть новый популярный язык программирования и парадигма.
Системные же программисты (на C, C++, Rust и даже Go), к примеру, регулярно пользуются если не ассемблером, то встроенными компиляторными функциями для оптимизизации своих библиотек при помощи векторных вычислительных устройств (simd). По определению системщиков не может быть много, конечно, но мы все пользуемся плодами их трудов (например, в рамках glibc или каких-нибудь roaring bitmaps).
Конечно, интерфейсов на js надо сделать больше, чем программок на си или cuda.
cepera_ang
09.09.2021 11:44Если вы хотите сделать принципиально новый процессор общего назначения (с новой архитектурой, языками программирования и подходом к параллелизму, как предлагается выше), то 1% — это очень маленькая ниша, особенно с учётом того, что она уже и так успешно занята существующими ускорителями.
VlK
09.09.2021 12:16+2Ну жизнь так устроена, что в любой заданный момент времени всем кажется, что все ниши заняты и никто уже ничего не сделает нового.
Количественные изменения накапливаются... а потом - бам! - и AMD снова на коне. Рр-р-р-р-раз! - и вычисления из CPU переезжает в GPU.
Впрочем это все скучная болтовня. На практике Эльбрус никакой не новый, а история его подхода уже лет 30 как с переменным успехом тянется, и успехов у МЦСТ хватает, что бы там не говорили сторонники глобализма в микроэлектронике.cepera_ang
09.09.2021 12:26+1Ага, я тут в соседнем посте про интернет 2008 вспомнил, что я в этом 2008 году как раз на хабре зарегистрировался и полез свои комментарии смотреть. И надо же, первые из них — про Эльбрус и его невероятные успехи. Думаю ещё на пенсию пойду, а Эльбрус (и VLIW с ним) всё будет побеждать :)
Civil
09.09.2021 11:28+2Так там Бабаян поясняет, почему Itanium не взлетел — потому что мог в параллель выполнять лишь 6 команд
Бабаян там явным образом говорит о несостоятельности VLIW подхода, фразой "Ну мы и решили его попробовать. Ведь мы тогда минусов не знали этой широкой команды…"
Дальше итаниум он приводит как ещё одно подтверждение, что даже у конкурентов не вышло. Не надо вырывать фразы из контекста, иначе смысл их теряется.
unv_unv
09.09.2021 19:33Вы говорите о том, что не стоит вырывать слова из контекста, но Бабаян там прежде говорит о несостоятельности суперскалярности — а автор статьи именно суперскалярность указывает как правильную альтернативу VLIW. Так что если не вырывать из контекста, то нужно все три полюса дать — и что суперскалярность плохо, поскольку лишь 6 команд в такт, и что VLIW плохо, потому что статическое планирование, а хорошо — полностью параллельный процессор с параллельным языком программирования.
Civil
09.09.2021 19:38но Бабаян там прежде говорит о несостоятельности суперскалярности
Только это уже не контекст (контекстом конкретной фразы является мнение про VLIW, суперскаляр выпадает из него, также как выпадают идеи куда двигаться дальше), но так да, он там рассказывает свое мнение. Конкретно важный в рамках всего спора вокруг МЦСТ момент в том, что Бабаян разочаровался в VLIW (как в реализации Эльбруса, так и в реализации Itanium).
OpenA
09.09.2021 22:16+1Бабаян там явным образом говорит о несостоятельности VLIW подхода,
фразой "Ну мы и решили его попробовать. Ведь мы тогда минусов не знали этой широкой команды…"Под несостоятельностью "VLIW подхода" он имеет в виду сугубо статичность аппаратуры, это даже не в плане in-order vs out-of-order, а в плане того что как сейчас в эльбрусе все шесть практически универсальных ALC вынуждены вставать на ожиданиях данных или чего то еще дружной командой, синхронно, потому что широкие команды подразумевают такую синхронизацию - вот это он называет под минусом широкой команды.
Но прошу обращаю внимание именно широкую команду он считает плохой а не эльбрус. Вот что он предлагает сейчас: динамические стрендыпо сути те же ALC и каждый стренд в своем кластере с дубликатом регистрового файла (привет эльбрус). Строгое in-order исполнение, никакого бранчпредиктора, код для стрендов готовит компилятор, контекстная безопасность (аkа "Безопасный режим"). Все по сути то же самое, все все что в каком то виде уже было в эльбрусах 1-2-3 - вот тебе развитие, никакого тупика в развитии родных идей Бабаян не видит.
Civil
09.09.2021 22:22+2Но прошу обращаю внимание именно широкую команду он считает плохой а не эльбрус
Вы так говорите как будто Эльбрус не широкая команда. Перечитайте еще раз что конкретно написано, там банально исходя из правил русского языка негативно высказано и про Эльбрус в частности и про VLIW в целом. Если хотите с этим поспорить - говорите об этом с Бабаяном.
edo1h
10.09.2021 18:40Но прошу обращаю внимание именно широкую команду он считает плохой а не эльбрус. Вот что он предлагает сейчас
убил почти два часа, послушал лекцию. ни одного слова в поддержку vliw там не нашёл.
Все по сути то же самое, все все что в каком то виде уже было в эльбрусах 1-2-3 — вот тебе развитие, никакого тупика в развитии родных идей Бабаян не видит.
и какое это имеет отношение к сегодняшнему эльбрусу?
N-Cube
06.09.2021 08:18+22Статьи любопытные пишете, вот еще бы убрать переходы на личности…
Дабы не превращать дискуссию в формат форумной перепалки, я попытаюсь структурировать изложенные возражения, максимально опустив малозначимые на мой взляд детали и не относящиеся к делу реплики. Также мы оставим на совести Алексея некорректные высказывания и переходы на личности. Это мишура, которая не поможет нам глубже понять суть проблемы.
Зачем тут все это? Речь о процессорах или задача натыкать оппонента носом? А смысл? Даже если написать, что Земля круглая, найдутся несогласные - проверено :) - только какой смысл с ними спорить.
LuggerMan
06.09.2021 10:46+37Здесь цимус в том, что личность — работник МЦСТ, а автор — бывший работник МЦСТ. К примеру я запас попкорн
trak
06.09.2021 12:31+1"вот это поворот .jpeg" :)
Автору спасибо за статью! Я тоже немного грыз Эльбрус по работе, и сломал зубы :( А хотели портироваться для полезного государевого дела.
Armmaster Автор
06.09.2021 11:48+16Я не смог удержаться в паре мест от шпилек, виноват. Но с другой стороны, Алексей местами такое пишет, что волосы немного дыбом становятся.
N-Cube
06.09.2021 15:14+2Может, человек просто зарплату отрабатывает, как он это понимает и умеет, а вам-то зачем…
charypopper
06.09.2021 15:33+7Тогда ведь, кроме хорошей статьи, мы получаем контекст - что другой автор (который тоже пишет статьи и разбирается в вопросе) компетентен в технической части, но не силен в сравнении с RISC/CISC. И при этом, действительно, уколы в новой статье лишь в паре мест - а 99% статьи - техническая.
Zhuravell
06.09.2021 08:19+6На мой взгляд, тактовая частота процессора в последние годы превращается в такую же уловку маркетологов, как мегапиксели и 50-кратный зум в цифровых фотоаппаратах. Производительность процессора определяется тем, сколько команд он может выполнить за один так. Если МЦСТ удастся разработать более производительную архитектуру, то она может сгладить или вовсе нивелировать отставание в тактовой частоте. За примерами далеко ходить не надо - Apple выпустила свой процессор A1, который при более низкой частоте, чем у Интел, достиг сравнимой и даже местами большей производительностью, по крайней мере, в синтетических тестах.
SergeKh
06.09.2021 09:47+17Почитайте внимательно статью. В том-то и дело, что Эльбрусу не удается даже выполнить больше инструкций за такт, по сравнению с CISC процессорами.
Armmaster Автор
06.09.2021 11:49+6Так главный вывод данной статьи как раз в том, что архитектура Эльбрус проигрывает по производительности в 3-4 раза своим RISC/CISC конкурентам.
exec77
06.09.2021 11:58+8Слежу за дискуссией с вашей первой статьи, но вынужден обратить ваше внимание, на то, что вы делаете суждение без описания условий. Метод научного спора так не работает.
Я скажу, что Мерседес быстрее УАЗ, а мне предложат продемонстрировать это в болотах под Нижним, где Мерседес даже с дороги не сможет съехать.
Еще пример: Маск о том, что давление в камере сгорания двигателя Рэптор выше, чем у РД-180, т.е. они превзошли РДшки. Но Лавочки уточнил, что Маск сравниваем давление в совершенно разных по типу топлива двигателях и сравнение не корректно. Еще пример: нет никакого смысла говорить что дизельный двигатель лучше, только потому что там компрессия выше.
Описанное вами может быть правдой применительно к конкретным условиям. Нельзя заявлять, что "Эльбрус проигрывает в 3-4 раза" не указав названия конкурентов с идентичным тех процессом, схожей сферой применения (т.е. какие задачи должно решать устройство) и набор тестов, в котором вы сравниваете.
Ваши заявления носят именно такой характер, это не самый продуктивный спор.
amartology
06.09.2021 12:01+22Нельзя заявлять, что «Эльбрус проигрывает в 3-4 раза» не указав названия конкурентов с идентичным тех процессом, схожей сферой применения (т.е. какие задачи должно решать устройство) и набор тестов, в котором вы сравниваете.
Так вот же в статье, от слов «Как говорится, вместо тысячи слов – дайте код» идет подробное описание условий тестов.exec77
07.09.2021 14:19+1А в ответной статье идет опровержение, причем на более прикладном (привязанном к целевой задаче уровне). Это называется диалог, понимаете? Нельзя вбрасывать фразу без контекста - это теряет смысл. "Водород лучше кислорода!" - эта фраза не имеет смысла, т.к. в дыхательном процессе именно кислород выступает окислителем (забирает электрон с митохондрий) и без него никак, а самый распространенный элемент во вселенной - это водород. Я обращаю ваше внимание на то, что приводя любую гипотезу - нужно давать контекст. Иначе с равным успехом можно заявить, что Apple m1 полная ерунда по сравнению с Эльбрусом, т.к. плохо считает математику.
Kenya-West
06.09.2021 16:09+8Без проблем! Эльбрус
намногомедленнее во всех условиях, с которыми сталкиваются обычные корпоративные и индивидуальные потребители. Вот и всё.Потенциально (всего лишь теоретически) Эльбрус лучше в некоторых математических вычислениях, то есть в очень нишевой зоне, которую, я уверен, никогда коммерчески не монетизируешь. Госзаказ, конечно, спасёт, но обычным клиентам Эльбрус не нужен и даже вреден, потому что - опять же - у него другая архитектура. Точка
Civil
06.09.2021 16:33+4Эльбрус лучше в некоторых математических вычислениях, то есть в очень нишевой зоне
Даже в таких зонах будет напрашиваться сравнение с различными ускорителями и другими системами, рассчитанными на эти задачи.
amartology
06.09.2021 16:36+1в некоторых математических вычислениях, то есть в очень нишевой зоне, которую, я уверен, никогда коммерчески не монетизируешь.
Оно прекрасно монетизируется, DSP процессоров пруд пруди. Но душа требует свершений, а не скучной обработки видео.
mikhanoid
06.09.2021 18:05+17Только фишка в том, что Эльбрус - это не процессор для корпоративных и индивидуальных потребителей. Его пробуют протащить в эту нишу, но Эльбрус, в первую очередь нужен военным, чтобы ставить в умное оружие. А там основные задачи как раз математические, да ещё и такие под которые Эльбрус специально проектировался.
Статья, конечно, интересная, но Эльбрусы проектировались не для того, чтобы пузырьком сортировать, а для рассчётов траекторий, обработки сигналов радаров и для всякого такого. И они с этим задачами прекрасно справляются.
Да, наверное, на широкий рынок Эльбрусы тащить не особо разумно. Но с другой стороны, у многих организаций просто нет выбора. Да, Эльбрус будет считать в несколько раз медленней x86, но это, всё равно, в миллион раз быстрее человека, и всё равно, это нужно в производстве. Ну, будем ждать рассчёта движения фрезы для станка с ЧПУ не минуту, а 10 минут, и что?
Байкалы нельзя считать конкурентами Эльбрусам, потому что там лицензионные ядра, и условия лицензий могут ограничивать применение в военной сфере или обработке гостайны.
Можно, наверное, запустить программу разработки своего ooo-ядра. Но ooo-процессоры очень (прям ОЧЕНЬ-ОЧЕНЬ) сложные. Их дебажить сложно. Стоимость разработки будет астрономическая. Они небезопасны (meltdown-ы всякие). Есть у них свои недостатки.
Как-то так... Сырая производительность не всегда является основным критерием при принятии решений. Автомобильный рынок, кстати, хорошая метафора. На нём востребованы не только Порше да Лэнд Крузеры, на Ниву тоже есть большой спрос. Не, конечно, в Ниве можно найти уйму недостатков, но машина позволяет решать людям их задачи. Так чего ещё надо?
К процессорам тоже, мне кажется, надо как-то проще относиться. Если Эльбрус решает задачи заказчиков, так и прекрасно, пусть решает. На этом всём спросе от заказчиков растут специалисты, устанавливаются кооперационные связи (не ядром единым же жив процессор), накапливаются компетенции и опыт. Это всё нужно и полезно.
Vedomir
06.09.2021 18:25+10Вот только речь идет не о спросе от заказчиков, а о принудительном внедрении в госструктуры без которого заказчиков на Эльбрус нет по признанию самих разработчиков (они прямо говорят о смерти в случае отказа государства от принуждения).
mikhanoid
07.09.2021 07:36+8Я не очень понимаю, в чём тут проблема? Государство хочет снизить свою зависимость от иностранных компаний. И это одно из тех немногих начинаний правительства РФ, которые народ горячо поддерживает. Собственно, на текущий момент ничего, кроме Эльбруса, не может решить эту задачу. Да, архитектура не самая лучшая, да, производительность не на всех задачах выдающаяся, но задачи решать можно, и это главное в текущий момент.
Стратегически верным решением было бы не лишение МЦСТ финансирования, а финансирование разработчиков альтернативных архитектур, потому что они без госзаказа тоже не конкурентоспособны на рынке. Ну, и за это финансирование требовать открытости и публичности.
У нас же наблюдается, и не только в государстве, а вообще в умах обывателей, странное желание сложить все яйца исключительно в одну корзину. Либо Эльбрус, либо не Эльбрус (вместо Эльбруса можно поставить любую другую архитектуру процессора, модель смартфона, операционную систему или язык программирования), третьего не дано. В итоге, вместо того, чтобы выступать перед государством единым фронтом, разработчики тратят силы на грызню друг с другом. Это путь в никуда и постоянную зависимость от внешнего рефери: раз сами не можем договориться, то придётся брать чужое решение. Возможно, именно это произошло в СССР, когда было принято решение клонировать западную микроэлектронику и отказаться от собственных разработок.
alex6999
07.09.2021 08:45Простите, какой народ это поддерживает? Есть польза для страны, а польза для народа и к сожалению то что делается для пользы страны как правило оказывается во вред народу. Увы, я ставлю личное выше общественного.
Насчет пользы для страны тут тоже можно спорить.
mikhanoid
07.09.2021 09:16+4И чем вредит народу разработка Эльбрусов? Тем, что создаёт площадку для образования и развития соответствующих компетенций у инженеров? Процессор - это, ведь, не только собственно микроархитектура ядра, это ещё и дофига производственных, образовательных и исследовательских процессов, которые имеет смысл поддерживать, если мы хотим давать каждой конкретной личности из народа больше вариантов развития.
amartology
07.09.2021 09:39+5В России, по самым скромным подсчётам, больше сотни компаний, занимающих разработкой и/или производством микросхем. Среди них есть такие, продукция которых конкурентоспособна на мировом рынке или потенциально конкурентоспособна на мировом рынке. Но господдержки не хватает на всех, и давая деньги МЦСТ вместо, скажем, разработчиков навигационных чипов, автоэлектроники или силовых транзисторов на сложных полупроводниках, Минпромторг приносит больше вреда, чем пользы.
Процессор — это, ведь, не только собственно микроархитектура ядра, это ещё и дофига производственных, образовательных и исследовательских процессов
В России в активной разработке находится больше десяти линеек микропроцессоров и микроконтроллеров. Чем МЦСТ лучше других? Только более хайповой задачей?MZjr
08.09.2021 01:05+2Но господдержки не хватает на всех, и давая деньги МЦСТ вместо, скажем, разработчиков навигационных чипов, автоэлектроники или силовых транзисторов на сложных полупроводниках, Минпромторг приносит больше вреда, чем пользы.
Вообще-то МЦСТ как раз и обвиняет Минпромторг в закапывании Эльбрусов и ориентации на лоббистов от крупного капитала.
Эльбрусы или другие процессоры, производимые в стране и, желательно, на основе контролируемой архитектуры и микроархитектуры нужны не для повсеместного внедрения а только в критически важных областях, где информационная безопасность и гарантированная работоспособность важнее, чем некоторый проигрыш в производительности.
Однако, новое постановление правительства, подготовленное Минпромторгом вводит весьма слабые критерии (т.н. балльную систему) того, что считать российским - и вот уже компы Аквариус на Intel 10-го поколения волне себе российские. При прочих равных (соответствие ограничениям и ТЗ на закупку), контракт на госзакупки получает тот, кто предложит меньшую цену. Ну а поскольку сборочное и перемаркировочное производство существенно дешевле, оно и получает преимущество.
Кстати, по поводу постановления есть вопрос: кто знает - теперь простой ноутбук/монитор в школу по госзакупкам будет не купить? Если это так, то получаем дополнительный рынок для пересборки.
amartology
07.09.2021 08:50+2Собственно, на текущий момент ничего, кроме Эльбруса, не может решить эту задачу
Это не так. Прямо сегодня для персоналок есть Байкалы. Прямо сегодня в больших количествах используются для обработки видео чипы Элвиса. Прямо сейчас есть промышленные приборы на чипах Миландра, НИИЭТ, НИИМА, НИИСИ.У нас же наблюдается, и не только в государстве, а вообще в умах обывателей, странное желание сложить все яйца исключительно в одну корзину.
Оно наблюдается в основном в умах фанатов Эльбруса, поминутно, как вы выше, объявляющих МЦСТ единственными спасителями отечества и игнорирующих при этом всю остальную российскую микроэлектронику. А самые сильные конкурентные стороны российской микроэлектроники — вовсе не микропроцессоры.В итоге, вместо того, чтобы выступать перед государством единым фронтом, разработчики тратят силы на грызню друг с другом
Потому что государственных денег на всех не хватает.mikhanoid
07.09.2021 09:32+5Это не так. Прямо сегодня для персоналок есть Байкалы. Прямо сегодня в больших количествах используются для обработки видео чипы Элвиса. Прямо сейчас есть промышленные приборы на чипах Миландра, НИИЭТ, НИИМА, НИИСИ.
Прямо сейчас оборонке и некоторым госкорпорациям нужны процессоры для проведения инженерных и физических рассчётов. Эльбрусы им нужны, в первую очередь, именно для этого. Можно из чипов Элвиса собрать кластер для расчётов методом конечных элементов? Из процессоров Миландра можно? Я не знаю ответа, я спрашиваю. Я знаю, что из E2K кластеры собирают и успешно на них считают. Из Байаклов, наверное, теоретически, можно их собирать, но я не видел таких решений. А на Эльбрусах они есть.
Потому что государственных денег на всех не хватает.
Так поэтому надо объединяться и трясти больше денег, потому что деньги у государства есть и много (посмотрите на статистику по неиспользуемым остаткам бюджета), желания вкладывать их в дело - нет. А от грызни за те крохи, что предлагаются сейчас, никакой пользы не будет. Во всём мире именно так корпорации пилят бюджеты, почему мы должны быть святее Папы Римского?
amartology
07.09.2021 09:52+1Прямо сейчас оборонке и некоторым госкорпорациям нужны процессоры для проведения инженерных и физических рассчётов
И им на самом деле прекрасно подходят чипы Intel и IBM, а Эльбрусы им навязывают. Не то, чтобы это было плохо, но не надо путать причину и следствие.Я не знаю ответа, я спрашиваю
Так может быть, перед тем, как утверждать, что Эльбрусу в России нет альтернатив, стоит уточнить актуальный статус этих альтернатив? А то в реальности получится, что главное преимущество Эльбруса — хороший пиар.Так поэтому надо объединяться и трясти больше денег
Все очень хорошо знают ответ на вопрос «что делать?», мало кто готов говорить о том, «кто виноват?»
Приходите работать в любую из сотни российских микроэлектронных компаний менеджером по GR и начинайте трясти у государства больше денег. Я пробовал, получается обычно не очень)mikhanoid
08.09.2021 13:24+4Да никто им ничего не навязывает. Они просто купить не могут чипы IBM и Intel. Санкции США работают. Нужны очень хитрые схемы, чтобы добыть это оборудование. При чём США постоянно обрубает каналы поставки и выписывает огромные штрафы и тюремные сроки посредникам. Вспомните недавний скандал с Т-Платформой. Эти процессоры IBM и Intel достаются по высокой цене, не только денежной. Выгоднее, безопаснее и надёжнее иметь собственное решение.
Навязывают другим госструктурам.
jetexe
07.09.2021 09:00+4Государство хочет снизить свою зависимость от иностранных компаний
Завязывая производство на тайваньскую TSMC?
mikhanoid
07.09.2021 09:19А есть другие варианты? Вы рассуждаете как-то идеалистически. У государства есть конкретная возможность часть бюджета на информационные технологии отдать местным разработчикам, тем самым поддержать развитие микроэлектроники в стране. Это лучше, чем ничего.
jetexe
07.09.2021 09:30+4- аргумент
- опровержение
- ну и что?
не конструктивно получается.
тем самым поддержать развитие микроэлектроники в стране
А разве у нас только МЦСТ делает микроэлектронику?
На самом деле я не вижу ничего плохого в производстве чего-либо на мощностях любых компаний, но меня печалит, что это:
- называют импортозамещением (тем самым снижением зависимости)
- тратят мои налоги на бесполезную дорогую игрушку
Vedomir
07.09.2021 18:47Так я как раз за развитие других архитектур и не против траты госденег на Эльбрусы. Если у них есть ниши где они хороши — будь то числодробилки или военные применения, то пусть они туда и идут. Но как процессор общего, гражданского назначения — это тупик и по железным причинам и по софтовым (причем последние останутся даже в случае гипотетического решения железных) и его принудительное внедрение в гражданский сектор это только много головной боли подневольным людям и никаких стратегических выигрышей для нашей микроэлектроники.
DisM
06.09.2021 18:38+14а для рассчётов траекторий, обработки сигналов радаров и для всякого такого
Но это совершенно не означает что он в этом хорош :) Более того, Тогда, когда он для этого проектировался, возможно это так и было, но уж точно не сейчас.
Да, Эльбрус будет считать в несколько раз медленней x86, но это, всё равно, в миллион раз быстрее человека
У нас сейчас стоит выбор или Эльбрус или на счетах ?
Байкалы нельзя считать конкурентами Эльбрусам, потому что там лицензионные ядра, и условия лицензий могут ограничивать применение в военной сфере или обработке гостайны.
Интересная конструкция - строить Утверждение, на предположении.
на Ниву тоже есть большой спрос. Не, конечно, в Ниве можно найти уйму недостатков, но машина позволяет решать людям их задачи. Так чего ещё надо?
Только вот за Ниву не просят как за Лендкрузер 300, только по этому он имеет покупателя. Давайте, продайте Ниву за 12 лямов, я на вас посмотрю.....
Хотя постойте, можно же принять закон и запретить продавать внедорожники кроме Нивы, и тогда можно будет из за 12 продать....
Не это ли нам предлагают на рынке процессоров ?
mikhanoid
07.09.2021 07:47-2Но это совершенно не означает что он в этом хорош :) Более того, Тогда, когда он для этого проектировался, возможно это так и было, но уж точно не сейчас.
Он достаточно для этого хорош. Он решает боевые задачи. Можно ли решать боевые задачи лучше? Лично я не знаю. Я не знаю, какие требования к ним предъявляют. Может быть, там нужна абсолютная предсказуемость времени обработки сигнала, жёсткое реальное время, тогда все out-of-order решения автоматически отпадают.
У нас сейчас стоит выбор или Эльбрус или на счетах ?
Перед некоторыми организациями стоит именно такой выбор. Или все уже забыли историю с Иранской ядерной программой и Stuxnet?
Только вот за Ниву не просят как за Лендкрузер 300 ...
Я имел в виду, что требования у заказчиков к продуктам могут быть совершенно разные. Кроме того, не известно, сколько будет стоить OoOE-процессор отечественной разработки. Это очень дорогое удовольствие по транзисторному бюджету.
N-Cube
06.09.2021 19:28На логарифмической линейке перечисленные вами задачи тоже решаются - раз вам все равно, что считать долго, почему же вы с компьютера в интернете сидите, а не траектории на линейке сейчас считаете? А я лучше на нормальном интеле или амд интерферограммы спутниковые посчитаю, это терабайты и десятки терабайт данных обработать требует, вы с линейкой или эльбрусом можете и не начинать… Военным, кстати, интерферограммы тоже нужны - это и рельеф, и устойчивость территорий, и всякие скрытые сооружения найти можно.
mikhanoid
07.09.2021 08:02+5Надеюсь, Вы просто передёрнули по привычке, а не всерьёз считаете, что задачи, которые можно решать на Эльбрусе, можно решать и на логарифмической линейке. Как нам в статье показывают, разница в производительности между Эльбрусом и процессором от Intel не на десятки порядков, а всего лишь в разы. И это терпимая разница для многих приложений. Кроме того, я думаю, что как раз на задачах обработки сигналов Эльбрус будет выигрывать у Intel. Во-первых, Эльбрус именно под такие задачи и проектировался, и для него написаны вручную оптимизированные библиотеки математических функций, выполняющиеся с полной загрузкой ФУ. Да и есть мировой опыт, самые быстрые DSP - это именно VLIW-процессоры.
N-Cube
07.09.2021 11:23+2Это вы передергиваете - пока вам не напишут интерферометрический пакет, вам будет все едино, что эльбрус, что счеты. Вы код хоть одного продукта для разворачивания интерферометрической фазы видели? Вот попробуйте для них написать под эльбрус «вручную оптимизированные библиотеки математических функций, выполняющиеся с полной загрузкой ФУ», прежде чем утверждать, что это плевое дело. Там итерационные растровые алгоритмы, это вам не быстрое преобразование фурье написать. А я, знаете, ни одного подобного пакета с поддержкой эльбрусов не видел.
Hlad
07.09.2021 11:40+3Как раз в военных задачах (например, в ПВО) разница в несколько раз в производительности — это разница между перехваченной вражеской ракетой и её попаданием в цель.
JerleShannara
07.09.2021 12:20Окей, вот и давайте пихать Эльбрус-е2к туда, куда пихают DSP процессоры, там он будет вполне себе работать(хотя насчёт радарной техники около меня шептались слова типа Arria, Spartan и Virtex ещё много лет назад). А вот роль GP CPU оставим какому-нибудь другому процессору, Байкал-М например, или тому, что там Yadro через несколько лет родит.
flx0
07.09.2021 16:39Кроме того, я думаю, что как раз на задачах обработки сигналов Эльбрус будет выигрывать у Intel.
У Интела-то выиграет, а у вот у других DSP — интересно было бы посмотреть на сравнение.
N-Cube
08.09.2021 05:18-1Интеловские компиляторы и библиотеки для физмат вычислений десятилетиями разрабатываются, в том числе, в России большой вклад сделан. Если уж на 7zip эльбрус по тестам на уровне интела 10-15 летней давности, то все эти обещания про вычислительную мощь выглядят только обещаниями.
amartology
06.09.2021 19:46+7го пробуют протащить в эту нишу, но Эльбрус, в первую очередь нужен военным, чтобы ставить в умное оружие. А там основные задачи как раз математические, да ещё и такие под которые Эльбрус специально проектировался.
Для этих математических задач у военных есть комдив-128, элкор и нейроматрикс. Все они, что характерно, сопроцессоры в гетерогенных СнК с «обычным» управляющим ядром. А вот с подтвержденными случаями использования процессоров «Эльбрус» в ВПК, кажется, напряженка. SPARC от МЦСТ — да, но то SPARC.Байкалы нельзя считать конкурентами Эльбрусам, потому что там лицензионные ядра, и условия лицензий могут ограничивать применение в военной сфере или обработке гостайны.
У Байкалов и Эльбрусов примерно одни и те же покупные периферийные блоки с одинаковыми лицензиями. Наверняка, кстати, ограничивающими применение в военной сфере. Так что тут никакой разницы нет.mikhanoid
07.09.2021 08:15Можно ли на Комдив-128, Элкор или НейроМатрикс запустить Linux или Windows? Насколько я понимаю, это всё системы типа микроконтроллеров. Наверное, их можно поставить на "изделие" для выполнения полётной программы, но для подготовки полётных заданий нужны совсем другие вычислительные мощности.
Я не очень понимаю, какое подтверждение Вам нужно. Но могу посоветовать посетить НСКФ, там показывают технику, в которой стоят Эльбрусы 2k.У Байкалов и Эльбрусов примерно одни и те же покупные периферийные блоки с одинаковыми лицензиями. Наверняка, кстати, ограничивающими применение в военной сфере. Так что тут никакой разницы нет.
А можно об этом подробнее? Про Байкалы я знаю, что таков стратегический план развития: лицензировать всё и по максимуму, чтобы как можно скорее выйти на рынок потребительского оборудования, вроде информационных киосков, терминалов оплаты или планшетов для школьников. С Эльбрусами, вроде, стратегия противоположная, и, насколько я понял (могу ошибаться) из докладов и разговоров, контроллеры памяти они сами разрабатывали.
amartology
07.09.2021 09:08+7Можно ли на Комдив-128, Элкор или НейроМатрикс запустить Linux
Да, на всех трёх. А также ОС реального времени.Насколько я понимаю, это всё системы типа микроконтроллеров.
Вы неправильно понимаете. Это системы типа мощных многоядерных процессоров для обработки больших массивов информации.для подготовки полётных заданий нужны совсем другие вычислительные мощности
Вы просто не понимаете, о чем говорите, и на каких процессорах на самом деле «готовятся полётные задания».А можно об этом подробнее? Про Байкалы я знаю,
Можно. Цитирую статью «Реализация каналов оперативной памяти DDR4 микропроцессора „Эльбрус-8С2“ за авторством Юрлина С В., опубликованную на конференции МЭС в 2016 году:В кристалле микропроцессора „Эльбрус-8С2“ используется физический уровень DDR4 multiPHY фирмы Synopsys.
Файл статьи доступен в proceedings конференции, все желающие могут проверить самостоятельно. Поэтому, повторюсь, с точки зрения защиты от санкций преимуществ у Эльбруса ровно ноль. Просто в МЦСТ не очень любят говорить на эту тему, потому что она ломает их импортозаместительную риторику, а в Байкале к этому относятся спокойно, потому что это часть их стратегии.VySh
07.09.2021 11:53+1Извините что вмешиваюсь, но физический уровень это по сути аналоговая часть контроллера памяти, он очень специфичен для конкретного тех. процесса и фабрики. Разрабатывать его самим было бы совершенно безумной идеей, по сложности и стоимости сопоставимой с разработкой самого процессора. Тем более что МЦСТ никогда не занимались аналоговым дизайном. Цифровая часть контороллера памяти это собственная разработка. И в целом когда говорится о том что в эльбрусе стоят иностранные IP блоки это чаще всего относится к именно к физ. уровню. Если мне не изменяет память, то в первом КПИ было покупные PCIE, USB и SATA, но вроде бы их потом заменили на блоки собственной разработки (исключая физ. уровень естественно).
amartology
07.09.2021 12:02+9Разрабатывать его самим было бы совершенно безумной идеей
А тогда нечего говорить про безопасность, отсутствие закладок и преимущества над пользователями лицензионных архитектур, если все общение с памятью идет через американский хардмакро, о внутренностях которого МЦСТ не имеет ни малейшего понятия.Разрабатывать его самим было бы совершенно безумной идеей, по сложности и стоимости сопоставимой с разработкой самого процессора.
Другие российские разработчики делают физуровень DDR. Я например его делал десять лет назад. Не DDR4 конечно, но и не вчера.
Можно было бы заказать дизайн физуровней в России, а не купить у Синопсиса. А так получается, что на словах все Лев Толстой, а когда за эти слова надо отвечать, получается «было бы совершенно безумной идеей».VySh
07.09.2021 12:08Какие российские разработчики микропроцессоров сами делают физуровень DDR4? Подозреваю что никакие. Может они еще и компиляторы памяти для своих микропроцессоров пишут? Эльбрус в плане иностранного IP содержит разумный минимум. Была бы фабрика на Микроне - и этого бы не было. Если сравнивать с Байкалом - кроме тех же памятей и физуровня будет ещё и ядро. И если физ. уровень ещё теоретически можно проверить на безопасность, то ядро - увы.
amartology
07.09.2021 17:43+2Какие российские разработчики микропроцессоров сами делают физуровень DDR4?
DDR3 делают. Будет задача сделать DDR4 и деньги на ее решение — можно будет сделать DDR4.Может они еще и компиляторы памяти для своих микропроцессоров пишут?
Компиляторы памяти пишут сами и продают другим российским компаниям как минимум НИИСИ и Альфачип. Причем при необходимости — существенно более сложные компиляторы радстойкой памяти. Российские разработчики вооьзе очень много всякого интересного умеют.. И если физ. уровень ещё теоретически можно проверить на безопасность, то ядро — увы.
Проверить физуровень DDR4 на безопасность ничуть не проще, чем процессорное ядро. А может даже и сложнее, потому что он, в отличие от процессора, умеет взаимодействовать с аналоговым сигналами.
VySh
07.09.2021 18:40-2Это совершенно разные компетенции - аналоговый дизайн и разработка микропроцессоров. За много денег можно что угодно сделать, это я понимаю, можно и в МЦСТ отдел аналогового дизайна оганизовать, но зачем? Кстати кто делает DDR3 вы так и не сказали.
Альфа-Чип это Моторола, потом Фрискейл, потом ON Semi, так что российский он с большой натяжкой. А НИИСИ для TSMC-шного техпроцесса компиляторы делает 7nm? И как там с плотностью?
В физуровне сильно меньше транзисторов и они больше по размерам. Хотя признаюсь что в поиске закладок в физуровнях я не специалист. Физ. уровни всё равно все покупают.
amartology
07.09.2021 22:03+2Повторю свой тезис: или вы делаете ВСЁ самостоятельно и заявляете о безопасности и независимости, или делаете, как все, но тогда и не говорите, что у вас есть какие-то преимущества в безопасности перед другими чипами, точно так же собранными с использованием американских хардмакро.
Физ. уровни всё равно все покупают.
«Все так делают» и «сложно и дорого» — не ответ.
Всем сложно и дорого, однако у других российских компаний (например, у НИИСИ и Элвиса) хватает денег и желания делать все части чипа самостоятельно в тех проектах, где это нужно.
А одновременно покупать хардмакро в США и говорить про безопасность от закладок — это ничем не прикрытое лицемерие.
VySh
07.09.2021 22:19-1Вы так и не привели ни одного конкретного примера продукта, сопоставимого по производительности и проектным нормам с Эльбрусом, разработанного без иностранных IP. Только общие слова про НИИСИ и Элвис. Ну типа у нас есть такие приборы, вот это всё. Причём, заметьте, я нисколько не умаляю заслуг этих уважаемых компаний, но при текущем положении дел с точки зрения замещения импортных IP Эльбрус смотрится довольно достойно. Его проблема уж точно не в этом.
amartology
07.09.2021 23:57+3Я не говорил, что уже есть готовые продукты, сходные с Эльбрусом, но без иностранных IP. Если бы они были, никакой дискуссии вокруг Эльбруса просто не было бы, потому что он был бы вообще никому не нужен. Сделанные НИИСИ и Элвисом чипы решают другие задачи и работают в других продуктовых нишах, потому что, вот сюрприз, микроэлектроника не ограничивается процессорами для ПК. При этом нахождение этих чипов в других нишах никак не делает их хуже или проще.
Я говорил о том, что Эльбус с phy от Synopsys ничуть не безопаснее Байкалов и что если в чипе есть хотя бы один американский хардмакро, все остальное его содержимое уже не важно — безопасности от закладок нет.
А вы на это отвечаете «все так делают». Но во-первых, не все так делают, во-вторых, другие, кто так делает, не трубят на всех перекрестках про защищённость от закладок, а в-третьих, безотносительно того, что делают другие, Эльбрус с американскими хардмакро небезопасен. Ваше «смотрится достойно» — это как сорта свежести рыбы или «немножко беременна». Тут абсолютно бинарная ситуация: иностранные IP у вас в чипе или есть, или нет. В Эльбусе они есть.
А в России есть компетенции по разработке недостающих блоков, и если кому-то нужно реальное, а не дутое импортозамещение, то деньги, потраченные на покупку блоков у Synopsys, стоило бы потратить на аналогичную разработку в России. И тогда уже говорить какие-то слова про безопасность и доверенность.
VySh
08.09.2021 00:16+1Ну вот смотрите, зайдём с другой стороны. Чисто формально, с точки зрения текущего законодательства, Эльбрус отечественный. Не вижу причин не использовать это в маркетинге. И как бы никто не запрещает тому же Ядру к примеру тоже назвать себя отечественным.
Вашу пуританскую позицию можно доводить до абсурда. Давайте тогда считать отечественным только то, что произведено на отечественном оборудовании, с использованием отечественных компонентов и материалов и т.п. Тут не сорта свежести рыбы, а Ахиллес и черепаха. Можно за ней гоняться бесконечно или в какой-то момент сказать что мы достаточно близко. И меряться кто ближе, кто дальше и в каких случаях что использовать.
amartology
08.09.2021 09:25+4Ну да, когда нечего ответить по сути, давайте зайдём с другой стороны.
Нет, не давайте.Чисто формально, с точки зрения текущего законодательства, Эльбрус отечественный. Не вижу причин не использовать это в маркетинге
С этим не вижу ни единой проблемы. Поддержка отечественного разработчика — это хорошо и правильно. Проблема — в заявлениях о безопасности и защищённости от закладок, которые, мягко скажем, не соответствуют действительности.И меряться кто ближе, кто дальше и в каких случаях что использовать.
Вполне нормальный подход, даже Минпромторг различает отечественные чипы первого и второго класса (произведенные в РФ и за границей). И я, кстати, полностью поддерживаю фаблесс дизайн чипов второго класса и их последующее производство на лучших мировых фабриках — только так можно сохранять и развивать компетенции в разработке.
Но надо адекватно оценивать недостатки такого подхода и таких чипов, не врать о них своим пользователям и уж тем более не озвучивать как преимущества над конкурентами то, что на самом деле преимуществом не является.
VySh
08.09.2021 11:11Давайте наверное закругляться с этим спором. Ваша позиция касаемо закладок:
Эльбрус ничем не лучше Байкала так как тоже содержит иностранные IP блоки (PHY и памяти).
Моя позиция:
Риски при использовании Эльбруса значительно ниже т.к. ядро самописное и можно провести аудит исходного кода. В случае Байкала очевидно нет. Остальные позиции по IP одинаковые.
Интересный вопрос, искать ответ на который мне лень. Есть подозрение что МЦСТ говорит об отсутствии закладок в ядре, а не в микропроцессоре. В ядре как раз иностранных IP нет.
amartology
08.09.2021 11:28+2Вам опять нечего ответить по сути, поэтому действительно давайте закругляться.
Есть подозрение что МЦСТ говорит об отсутствии закладок в ядре, а не в микропроцессоре.
О нет, МЦСТ говорит именно о том, что в других процессорах закладки могут быть, а у них — не могут. И эта позиция, озвученная, например в недавнем интервью господина Кима, является сознательным обманом, не больше и не меньше. Или, что еще хуже, сознательным самообманом.
Можно сколько угодно говорить про защищенные режимы, разделение памятей и много уровней стеков безопасности, но зачем они все, если вся информация, попадающая во внешнюю память или приходящая из внешней памяти, по пути проходит через черный ящик, о внутреннем устройстве которого вы не имеете никакого представления?При использовании Эльбруса можно провести аудит исходного кода. В случае Байкала очевидно нет.
В случае Байкала вполне можно получить исходный код ядра и провести его аудит. Это исключительно вопрос денег.В ядре как раз иностранных IP нет
У нашей крепости три стены, которые мы построили сами, поэтому риски проникновения врагов через четвертую стену, которую мы купили прямо у них, значительно ниже, чем у наших соседей, которые купили у врагов две стены, а не одну. Так как мы купили только одну стену, мы чувствуем себя в полной безопасности.
VySh
08.09.2021 11:51В случае Байкала вполне можно получить исходный код ядра и провести его аудит. Это исключительно вопрос денег.
Нет, нельзя. Если только вы не планируете выкупить Арм со всеми потрохами, но даже в этом случае см. export control. Давайте будем реалистами.
У нашей крепости три стены, которые мы построили сами, поэтому риски проникновения врагов через четвертую стену, которую мы купили прямо у них, значительно ниже, чем у наших соседей, которые купили у врагов две стены, а не одну. Так как мы купили только одну стену, мы чувствуем себя в полной безопасности.
Соседи живут в крепости, построенной врагами. А так да, мы будем чувствовать себя в большей безопасности, а у купленной стены поставим сторожа. Если этот самый PHY умеет подменять данные так чтобы конторольные суммы сходились, тогда лучше сразу сдаться.
Civil
08.09.2021 12:12Нет, нельзя. Если только вы не планируете выкупить Арм со всеми потрохами
Можете доказать, что нельзя без покупки ARM?
Соседи живут в крепости, построенной врагами. А так да, мы будем чувствовать себя в большей безопасности, а у купленной стены поставим сторожа.
Продолжая такую аналогию - вы всего лишь проектируете помещение, используя уже предоставленный список материалов, притом строят стены тоже внешние подрядчики, да и САПР импортный (делается чип на TSMC, используя их библиотеки и иностранный САПР). Поставленный сторож тоже будет импортным, к слову (как и его будка и ружжо). Можно разве что разобрать здание по кирпичикам и раскрошить кирпичики, но потом надо будет все изучать под микроскопом, чтобы точно убедится что ни на каком этапе не было включено в проект чего-то странного (а то поди докажи что это арматура в стенах, а не хитроумное устройство для ослабления конструкции или подрыва всего здания или что арматура не будет выполнять роль антенны).
Если этот самый PHY умеет подменять данные так чтобы конторольные суммы сходились, тогда лучше сразу сдаться.
Технически что ему помешает так делать?
amartology
08.09.2021 12:23+1Нет, нельзя. Если только вы не планируете выкупить Арм со всеми потрохами, но даже в этом случае см. export control. Давайте будем реалистами.
Давайте вы будете реалистом и узнаете от меня, что покупка исходного кода ядра — вполне обычная практика, и это стоит разумных денег. В частности, «Миландр» в 2008 назад купил несколько ядер ARM в исходных кодах — ровно для того, чтобы провести его аудит и поставить в продукты двойного назначения.Соседи живут в крепости, построенной врагами.
Нууу, с этой точки зрения Эльбрус тоже на Тайване произведен. А соседи из Байкала просто купили у врагов больше стенок, но собрали их тоже сами.Если этот самый PHY умеет подменять данные так чтобы конторольные суммы сходились, тогда лучше сразу сдаться.
Зачем так? Можно например полностью отключаться навсегда при поступлении определенной комбинации данных.
VySh
08.09.2021 12:44Давайте вы будете реалистом и узнаете от меня, что покупка исходного кода ядра — вполне обычная практика, и это стоит разумных денег. В частности, «Миландр» в 2008 назад купил несколько ядер ARM в исходных кодах — ровно для того, чтобы провести его аудит и поставить в продукты двойного назначения.
Попробуйте купить что-нибудь более производительное, например большое ядро А класса в исходниках и будете неприятно удивлены. Есть разные уровни экспортного контроля. Да и правила с 2008 года поменялись, сами знаете из-за чего.
Нууу, с этой точки зрения Эльбрус тоже на Тайване произведен. А соседи из Байкала просто купили у врагов больше стенок, но собрали их тоже сами.
Не, они купили сам замок и стены вокруг него и ров. Ну собрали сами, это да. А насчёт производства - если враги имеют такой технический уровень что могут вставить закладку в GDS, да ещё и так чтобы скан-тесты не попортить, да ещё и быстро, то опять же лучше сразу сдаться в связи подавляющим техническим превосходством противника.
Зачем так? Можно например полностью отключаться навсегда при поступлении определенной комбинации данных.
Ну можно, но только это сразу заметят. Можно ЭМ волной весь Эльбрус сжечь, это тоже закладка? Незаметно воровать планы мобилизации из военкомата в Архангельской области и прочую секретную информацию не получится.
amartology
08.09.2021 13:00+1Попробуйте купить что-нибудь более производительное, например большое ядро А класса в исходниках и будете неприятно удивлены. Есть разные уровни экспортного контроля. Да и правила с 2008 года поменялись, сами знаете из-за чего.
В покупке/продаже больших ядер вы, судя по профилю, понимаете несколько больше меня, так что спорить не буду. Но на ARM мир не заканчивается. Собственно, все разговоры про перспективность RISC-V ведутся ровно для того, чтобы самостоятельно сделать подходящие исходники, совместимые со всем разрабатываемым большим всемирным коммьюнити софтом.враги имеют такой технический уровень что могут вставить закладку в GDS
Давайте так: я вообще не верю в то, что закладки реальны и в частности также, как и вы, не верю в то, что их можно вставить в GDS в процессе приемки оного GDS фабрикой. Но мы сейчас обсуждаем не то, что мы с вами думаем, а патриотическую риторику и лежащие под ней объективные основания или их отсутствие.Ну можно, но только это сразу заметят.
Так это один из самых часто упоминаемых сценариев — «в случае войны американцы просто отключат все импортные чипы в российской военной технике».
VySh
08.09.2021 13:40+3Я весьма положительно отношусь к RISC-V в России в контексте последних событий. Но. Надо быть осторожными в своих ожиданиях. Почему-то у многих здесь в комментариях такая мысль проскакивает, что как только мы похороним Эльбрус и сменим его на RISC-V так сразу всё наладится, все магазины будут завалены дешёвыми отечественными процессорами, Интел подвинется и вот это всё. Здесь у меня есть большие сомнения. Я подозреваю что конкурировать Ядро сможет только в нашем российском междусобойчике. Да и Ядро это тоже понимает судя по тёркам с МЦСТ. Кроме того я не вижу причин по которым их продукция могла бы стоить сильно дешевле МЦСТ-шной. Объёмы будут примерно те же т.к. рынок мал. Выход на мировой рынок с конечной продукцией очень сомнителен (впомним как Т-Платформы в свое время попали под санкции, да и репутация у нашей страны так себе). Стоимость разработки будет сравнима с Эльбрусом скорее всего при похожем тех процессе и производительности. Возможно лет через 5-7 отечественный RISC-V обгонит Эльбрус по параметрам, но на такой долгий срок сложно предсказывать. По цене - скорее всего будет стоить слегка дешевле, по доступности - скорее всего будет более доступен. Хотя у Э. конечно есть фора.
В целом касаемо Ядра - история до боли напоминает Байкал. В какой-то момент компания производитель оборудования решает войти на рынок разработки своих собственных микропроцессоров. Добываются деньги - много денег, от роснано ли или от кого ещё. Сманиваются люди из более зрелых компаний, большими зарплатами или обещаниями преспектив. Даётся много обещаний. Дальше начинаются проблемы т.к. микроэлектроника это дорогое удовольствие, сроки постоянно двигаются, контракты срываются, часть инженеров уходит. В результате обещаного прорыва нет. И мы получаем еще одного разработчика российских микропроцессоров. Или не получаем - если денег не хватило.
Я прекрасно знаю ребят которые работают в Байкале (в свое время я отказался от их щедрого предложения, ещё в те времена когда они обитали в районе Юго-Западной кажется). Я прекрасно знаю ребят которые перешли в Ядро сейчас из того же МЦСТ. Я пересекался с бывшими сотрудниками Синтакора. Все отличные инженеры и всё у них получится, но факт в том что у МЦСТ уже есть большой задел в разработке (как бы тут не утверждали обратное) и чтобы конкурировать с ними потребуется два-три поколения микропроцессоров от Ядра т.е. 5-7 лет. И хорошо бы если бы на это хватило денег.
Vedomir
08.09.2021 16:07Как минимум их будет намного проще внедрять за счет большой экосистемы. То же самое в гораздо большей степени касается Байкалов с их ARM. Ну и экспорт возможен хотя бы в теории в отличие от Эльбрусов.
Civil
06.09.2021 21:13+2Только фишка в том, что Эльбрус - это не процессор для корпоративных и индивидуальных потребителей.
Это расходится с заявлениями мцст, его изначально позиционировали как убийцу интела.
Эльбрус, в первую очередь нужен военным, чтобы ставить в умное оружие
Есть доказательства? А то в соседних темах жаловались что радстойкий на российских фабриках был сделан один раз и все. Тут ключевой вопрос будет что там с защитой от ЭМИ. Ну и в общем вопрос в каких установках у военных Эльбрус, который не sparc.
Плюс военные получают весь тот же набор проблем что и гражданские. А там возникнет вопрос, а не лучше ли взять решение от Элвиса.
amartology
06.09.2021 21:35+3то в соседних темах жаловались что радстойкий на российских фабриках был сделан один раз и все.
Он не радстойкий. Радстойких чипов МЦСТ вообще не бывает.
RTFM13
07.09.2021 01:45-1его изначально позиционировали как убийцу интела.
В области импортозащемления он вполне себе убийца интела. Правда, он не всегда может занять место убитого, но это нюансы.
mistergrim
07.09.2021 07:15+4В области импортозамещения и сырный продукт с дырками убийца пармезана. Сравнение не имеет смысла.
Civil
07.09.2021 10:42+1В области импортозащемления он вполне себе убийца интела
Беда в том, что его позиционировали как убийцу интела еще до того, как импортозамещение стало модным. А в той области, уж извините, и комдив на 800 мгц - убийца, так уж она сформирована.
vanxant
07.09.2021 17:30Ну, будем ждать рассчёта движения фрезы для станка с ЧПУ не минуту, а 10 минут
Опять же, это расчёты и матан, здесь вполне может быть и 30 секунд у Эльбруса. Именно в этом случае статический анализ может дать преимущества над динамикой. Простые, хорошо прогнозируемые условия цикла и при этом тело цикла нагружено операциями. А в другом углу ринга — типичные «бизнес-задачи». В той же сортировке вставками нет никаких особых вычислений, по сути всего одна операция сравнения, зато есть много не предсказуемых на этапе компиляции переходов.
exec77
07.09.2021 14:09+1Вот и противоречите сами себе: "Эльбрус медленнее во всех" и "Эльбрус лучше".
Давайте рассуждать логически: при разработке архитектуры Эльбрус и построенного на ней одноименного решения Эльбрус были использованы определенные ФТ. ФТ определяют профиль устройства и его целевые показатели. По соответствию ФТ разрабатывается ПИМИ и проходят приемо-сдаточные мероприятия. Именно так (с поправкой на регион рождения) создаются любые устройства, и даже в Intel или nVidia.
Если мы хотим сказать, что Эльбрус не соответствует поставленным изначально ФТ - то давайте так и говорить. И приведем соответствующие тесты, в которых это докажем.
Но если мы хотим сказать, что на Эльбрусе плохо работает мобильный PUBG - то это вопрос либо к тому, кто это портировал, либо к самой идее "Зачем это делать?".
А далее мы приходим к вопросу: "Что для вас - обычный клиент?" Это человек/организация покупающая процессор для какой цели? Ходить в интернет? - Эльбрус вполне потянет браузер на Астра-Линукс. Открыть офисный пакет? Потянет. Запустить 1с? Потянет. Так где же та критичность для "Обычного клиента" о которой вы говорите?
sshikov
06.09.2021 17:39+1>давление в совершенно разных по типу топлива двигателях и сравнение не корректно.
Видите ли, давление это показатель, который непосредственно определяет тягу. При прочих равных, само собой. А тяга это не вторичный показатель, как компрессия у дизеля, а один из основных. Так что само по себе сравнение по этому показателю очень даже корректно, если мы понимаем, что он нам дает, и понимаем, что это не единственный показатель (как это бывает в большинстве случаев сравнения сложных систем).exec77
07.09.2021 14:25Вы дали мотивированное возражение - именно это я имел ввиду! Тогда контр-аргумент: а почему товарищ Маск сравнивает тягу Рэптора (новейший двигатель, еще не видевший пусков) с устаревшим РД-180, а не с новым РД-181? Ведь у РД-181 тяга выше Рэптора и РД-181 летает уже 5 лет. Видите? Снова не совсем честное сравнение выходит. Также и в полемике про Эльбрус - сравнивают не по целевым показателям. Это как сравнивать производительность супер-компьютера с RTX3090 в игре Киберпанк, а потом заявить что раз СК проиграл RTX, то СК не нужен.
Civil
07.09.2021 15:17+1с устаревшим РД-180, а не с новым РД-181?
Я в двигателях конечно ничего не понимаю, но кажется Вы перепутали РД-180 с чем-то еще. Он слишком отличается и от РД-181 и от Раптора чтобы их напрямую сравнивать (у РД-180 тяга выше в несколько раз, но тяга к массе намного хуже).
Касательно цифр - у РД-181 тяга 2090 кН, у Раптора в тестах 2200 кН.
Про давление в камере - опять же посмотрев на характеристики - скорее всего раптор сравнивают с рд-180 потому что у рд-180 оно выше чем у рд-181, чисто интересный показатель с точки зрения прочности материалов.
Буду признателен если Вы расширите мой кругозор и поясните где ошибка.
Эльбрус - сравнивают не по целевым показателям. Это как сравнивать производительность супер-компьютера с RTX3090 в игре Киберпанк, а потом заявить что раз СК проиграл RTX, то СК не нужен.
Дело в том что Эльбрус рекламируют как убийцу интела и процессор общего назначения еще с момента как его начали проектировать. Это автоматически делает любые прикладные задачи его целевыми задачами. И на практике выясняется что там он себя показывает не очень здорово.
На вопросы о каких-то более целевых задачах - ответов тоже не очень много звучит (полистайте эту тему, вопрос задавался многократно тут, а вот внятных ответов как не было, так и нет)
exec77
07.09.2021 16:38Из Вики на английском:
Raptor / Performance Thrust ~185 tf (1.81 MN; 410,000 lbf) for Raptor 1
RD-181 / PerformanceThrust (vac.)2.09 MN (470,000 lbf) at 100% throttle
1.81MN против 2.09MN у РД-181
Вы прекрасно проиллюстрировали мой довод, что Эльбрус сравнивали с чем-то совершенно не сопоставимым по задачам или целевым показателям.
И я не разу не слышал рекламу Эльбруса, как "убийцу Интел". Возможно вы путаете с Байкалами? Процессоры Байкал-М действительно сопоставляли с Интел.
P.S. Нашел запись с "Эльбрус Тех Дэй" 2021, где демонстрировали 10х - кратное превосходство над Интел.
https://www.youtube.com/watch?v=19N7QSQ9aE0&ab_channel=MaximGorshenin
Civil
07.09.2021 16:46Performance Thrust ~185 tf (1.81 MN; 410,000 lbf) for Raptor 1
Вы читайте внимательнее, там есть во первых ссылочки, на твитты заверявшие 225 tf, а также есть внизу табличка где 2200 кН против 2090 кН у РД-181.
Так что читайте пожалуйста внимательнее то, на что ссылаетесь. Ну то есть да, вы кажется нашли опечатку в википедии, это конечно хорошо, но вы можете ее же цифры и проверить, благо для большинства из них указан источник.
Вы прекрасно проиллюстрировали мой довод, что Эльбрус сравнивали с чем-то совершенно не сопоставимым по задачам или целевым показателям.
В каком месте?
exec77
07.09.2021 17:30+2Меряться Твитами мистера Маска - это Вы конечно "здорово" (читать - не научно) придумали.
Если позволите, то введу Вас в контекст. У двигателя семейства Raptor (на данный момент не-летавшие прототипы, если не считать "подскока" Стархупер) есть несколько серий.
Серия 1, она же просто Raptor, имеет официальные ТТХ по тяге в 185 тон. Именно эти данные и указаны в Вики в описании устройства. Это не опечатка.
Серия 2, она же Raptor v2.0 - это прототип перспективной версии, которая на стенде показала параметры от 90т до 225т.
В чем отличия? В том, что для двигателя важна тяга выдаваемая на промежутке времени, а не на пиковом значении. В момент отжига двигателя (обязательный процесс поверки каждого двигателя) фиксируется именно этот параметр.
Вы же ссылаетесь на пиковое значение стендового прототипа, которое зафиксировано Твитом мистера Маска.
Со всем уважением к мистеру Маску, но для меня это аргументы уровне "на заборе мелом написано".
Что же касается того, что вы подтвердили мой тезис - это как раз о том, что давление в камере сгорания позволяет судить о прочности камеры, а не тяги двигателя.
На этом дискуссию предлагаю завершить - не хочется обсуждать серьезные вещи на основе Твитов.
Civil
07.09.2021 18:19Меряться Твитами мистера Маска - это Вы конечно "здорово" (читать - не научно) придумали.
Тут какое дело - SpaceX - публичная компания, мистер Маск отвечает головой перед инвесторами за то что пишет касательно SpaceX и их продуктов. То есть если он соврал в твитте - это может грозить ему лично большим штрафом или уголовкой (вы в соседнем треде правильно упоминали Theranos, там собственно текущие суды над основателями идут, упрощенно, за введение инвесторов в заблуждение). Поэтому не понимаю почему это не может являться надежным источником информации.
Серия 1, она же просто Raptor, имеет официальные ТТХ по тяге в 185 тон. Именно эти данные и указаны в Вики в описании устройства. Это не опечатка.
Вы сослались на википедию. Википедия пишет про 185 тс ссылаясь на твитт маска, заявляющий "225 тс".
Если есть более официальное место - можете просто на него дать ссылку и поправить википедию (указав корректный источник и/или исправив цифру).
Вы же ссылаетесь на пиковое значение стендового прототипа, которое зафиксировано Твитом мистера Маска.
А где в его твитте это написано?
Более того - как понять на какое значение ссылается табличка про РД-181? (вопрос совсем серьезный, потому что на википедии пруф-линки дохлые)
exec77
07.09.2021 18:28Ну вот, вы снова подменяете понятия. Мистер Маск не отвечает головой. Фактически за публичную ложь он отвечает только своим постом в компании и вероятными штрафом. Именно так было в истории, когда он спровоцировал рост акций Теслы заявлением "Tesla Go-Private". Капиталисты врали, врут и будут врать. В капиталистической системе продаются "обещания", а не реальность. Так устроена система.
Я сослался на Википедию, а на Твит сослались вы. Я вам уточнил контекст, в котором нужно читать Твиты, исключительно в целях вашего информирования.
На что ссылается табличка РД-181(193) я вам обязательно найду. Но не сейчас.
Civil
07.09.2021 19:00Фактически за публичную ложь он отвечает только своим постом в компании и вероятными штрафом
Зависит от масштаба лжи, вплоть до уголовного преследования.
Я сослался на Википедию, а на Твит сослались вы.
Вы сослались на табличку на вики, которая ссылается на твитт, я лишь прошёл по ссылке проверить правильность данных.
Более того, я уже указал ранее ссылкой, что на той же странице есть вторая табличка где значения другие. Вы её проигнорировали.
Я вам уточнил контекст, в котором нужно читать Твиты, исключительно в целях вашего информирования.
Извините, но я не вижу причин доверять вашим заявлениям, так как я уже указал вам на несоответствия в вашем же источнике информации.
exec77
07.09.2021 22:43+1Вы точно умеете работать с источниками?
Ловите выдержку из цитируемого научного источника о ТТХ РД181:
https://www.elibrary.ru/download/elibrary_26239199_97622506.pdf
Искренне надеюсь на обретение вами адекватности в ведении диалога. Всех благ.
Civil
07.09.2021 23:00Ловите выдержку из цитируемого научного источника о ТТХ РД181:
Спасибо. Тут тоже интересное - разница тяги в вакууме и на уровне моря и для английской википедии указывается только одно значение.
И вот разница - в вики 209 тс, в документе 212.2 (или 196), опять же к вопросу о данных в википедии.
Civil
07.09.2021 20:37-1Я почему-то думал что торгуется. В общем принципиально картины не меняет - есть инвестеры кроме Маска, за распространение ложных сведений будет ответственность как перед инвестерами, так и вплоть до уголовной.
VlK
08.09.2021 09:31+1за распространение ложных сведений будет ответственность как перед инвестерами
А какая связь между твиттером и инвесторами? В частных компаниях владельцы информацию не из Интернета получают, а, к примеру, через отчеты назначенных директоров.
И раз уж мы об этом говорим, то проведу небольшой ликбез. К торгуемым на биржах компаниям применяются свои правила. Такие компании обязаны периодическои публиковать определенного формата отчеты, которые и должны соответствовать каким-то требованиям. В твиты эти отчеты, очевидно, не поместятся.
Civil
08.09.2021 10:43А какая связь между твиттером и инвесторами? В частных компаниях владельцы информацию не из Интернета получают, а, к примеру, через отчеты назначенных директоров.
Небольшой ликбез - когда C-level пишет или говорит что-то публично это считается авторитетным заявлением и за ложь в них он несет такую же ответственность как за ложь в официальной отчетности. На самом деле не только про C-level речь, но чем ниже должность и вовлеченность человека в бизнес, тем больше свободы в высказываниях позволяется. У Маска, как основателя, свободы в высказывании таких вещей самый минимум, иначе есть неиллюзорный шанс повторить судьбу Теранос в будущем, если вдруг на практике это не реализуется.
И раз уж мы об этом говорим, то проведу небольшой ликбез. К торгуемым на биржах компаниям применяются свои правила.
И опять же за определенные публичные высказывания торгуемой на бирже компании тоже могут настучать по шапке, там это чуть проще, так как показать связь с манипуляцией ценой на акции чуть проще, чем доказать введение инвесторов в заблуждение. Но разница не принципиальная.
VlK
08.09.2021 11:02+1когда C-level пишет или говорит что-то публично это считается авторитетным заявлением и за ложь в них он несет такую же ответственность как за ложь в официальной отчетности
Я просто хочу указать, что в публичных компаниях есть документы, к которым выдвигаются жесткие требования. Например, как здесь https://ir.bumble.com/. Это прогнозы, status quo, ретроспектива и так далее. Аналогичные сайты есть у других компаний. Конечно же, директор в такой компании должен вести себя соответственным образом.
Это нужно, чтобы информировать потенциальных держателей акций о ситуации в компании.
А вот закрытые компании таких документов не публикуют, а их владельцы делают в определенных рамках что хотят. Можно, конечно, подать на CEO в суд (а в Штатах вообще можно подавать в суд по поводу и без), но вероятность последствий тут небольшая - и у Маска их особо не было.
Civil
08.09.2021 11:20Я просто хочу указать, что в публичных компаниях есть документы, к которым выдвигаются жесткие требования.
Само собой, это достаточно очевидная вещь.
Конечно же, директор в такой компании должен вести себя соответственным образом.
А вот тут уже не совсем очевидный момент - директор должен вести себя соответствующим образом даже не в публичной компании. Я повторюсь уже в который раз - даже если компания закрытая, но директор соврал в публичном заявлении - он может понести ответственность за это, вплоть до уголовной. Это будет сложнее доказать, чем манипуляцию цен на акции, но вполне возможно, особенно если события повторяются периодически. Собственно когда CEO публикует такие цифры у себя в твиттере, скорее всего он видел бумажку где эти цифры были продемонстрированы, это достаточно разумное предположение, если конечно человек не мазохист и не хочет в будущем слегка присесть.
vaslobas
06.09.2021 13:43+1А почему только в последние годы?
Интел сами это уже проходили во времена пентиума 4 и особенно прескотта. Там частоты уже вплотную подбирались к 4 ГГц. Потом был сильный откат по частоте, когда перешли к архитектуре кор. Кор была и быстрее и куда холоднее.
У амд тоже всегда в те времена частоты были очень маленькие, поэтому они ввели рейтинг процессора. Какой нибудь амд атлон 64 с частотой 1800 МГц имел индекс атлон 64 3000 и был на уровне или быстрее пентиума 4 с реальной частотой 3000.
MTyrz
06.09.2021 15:04+2В последние годы?
Архитектура NetBurst с лозунгом «покупают мегагерцы» смотрит на этот коммент назидательно!
UPD. Надо обновлять комменты перед написанием. Особенно если отходил на полдня…
SlyFoxMan
06.09.2021 09:06+1Производительность данного теста упирается в скорость работы самих дисков, их микроконтроллеров и подсистемы памяти процессора. Реальная вычислительная производительность процессорного ядра там неважна
Это не совсем так, производительность процессорного ядра имеет значение, т.к. тестируются синдромные рэйды (в данном случае 6й рэйд) и производительность процессорного ядра влияет на расчет синдромов.
На мой взгляд, использование производительности SDS в качестве примера производительности эльбруса несколько нерелевантно, хотя бы тем, что в случае sds код вручную векторизован и оптмизирован под этот самый эльбрус.
creker
06.09.2021 16:31Да оно было бы релевантно, возьми они нормальное SDS на nvme дисках хотя бы. А еще лучше что-то вроде сефа. Сразу было бы видно, на что этот эльбрус годен.
GerrAlt
06.09.2021 09:17-8И везде видно, что VLIW решения всегда своим конкурентам уступают по частоте. И у этого есть вполне определённая причина – особенности архитектуры у VLIW-процессоров. А конкретно для Алексея вопрос можно переформулировать следующим образом – почему Эльбрус(e2k), который постоянно выставляется как главный процессор от МЦСТ и в который вкладываются основные разработческие ресурсы, уступает по частоте процессорам линейки Sparc от МЦСТ, в которые всегда вкладывались намного меньше? Т.е. дело не деньгах и нанометрах, а в принципиальных ограничениях VLIW-архитектур.
А если спидометр у одной машины размечен в милях в час, а у другой в км/ч, это значит что первая машина впринципе не может ехать так же быстро как вторая? Вы говорите о принципиальной разнице в архитектурах процессоров, но при этом предлагаете сравнивать тактовые частоты - как-то странно выглядит.
newpavlov
06.09.2021 10:24+14Нет, это сравнение одних и тех же км/ч, но в одном случае это речное судно, а во втором автомобиль. Сделать автомобиль ездящий на скорости 100 км/ч значительно проще чем аналогичное судно. Да, на судно можно загрузить больше груза тем самым скомпенсировав его меньшую скорость (числодробительные задачи по типу БПФ), но большую часть времени пользователям достаточно багажника (код с сильными внутренними зависимостями), либо они заказывают перевозку ж/д транспортом (массивный параллелизм на GPU).
Civil
06.09.2021 10:42+5Продолжая аналогию:
Только на практике выяснится что производитель разместил слишком много кресел, которые не получается забить даже на половину, но из-за этого места для грузов тоже не осталось. А с машиной напротив - к ней цепляют прицеп и тот же объем пассажиров и груза все равно перевозят быстрее.
kmeaw
07.09.2021 07:27+2Но при этом у нас остаётся потенциальная возможность перепаковать груз (новым lcc) таким образом, чтобы он размещался на креслах. И тогда его можно будет перевозить на уже купленном речном судне быстрее, чем на машине с прицепом.
Civil
07.09.2021 10:40Проблема только в том, что возможность очень теоретическая и потенциальная и не любой груз вообще влезет на кресла.
И продолжая аналогию - если река немного сезонно пересохла то с речным судном все по-прежнему будет плохо. А автомобиль в случае заборов на одной дороге достаточно легко найдёт альтернативный маршрут и все равно окажется быстрее.
GerrAlt
06.09.2021 21:15Но нет же, разная архитектура команд дает разницу в реальных вычислениях за такт, впрямую сравнивать циферки некорректно, вы в своем примере сравниваете как раз производительность в задаче (перемещение определенного груза на определенное расстояние за определенное время). Вы сравниваете с какой скоростью может перемещать определенный груз определенный механизм, а не на каких оборотах работает у этого механизма двигатель.
Tarakanator
06.09.2021 11:18+18Ну если совсем грубо качество архитектуры = частота*ipc
И то и то в статье у эльбруса рассмотрено. И то и то хреновое. Что вам не нравится?GerrAlt
06.09.2021 21:06Ровно то что я и написал, мне не нравится аппеляция к цифрам в показателях тактовых частот
Есть ощущение что меня не правильно поняли: я не защищаю ни чью позицию, я только указываю что прямое сравнение циферок выглядит плохо. Можно сравнивать производительность на задачах. Не понял пчм если, допустим, у человека отличная статья, но где-то написано что 2+2=5 (без развернутых пояснений к этому тезису) то указать автору на странность ситуации вызывает такую бурную реакцию.
farafonoff
06.09.2021 22:46+4Автор же прямо написал, что 2*2 меньше, чем 4*4. Сравнил по отдельности двойки и четверки, и убедил нас, что из 2*2 не получится сделать 4*4.
kmeaw
07.09.2021 07:32IPC у VLIW сильнее зависит от компилятора. На оптимизирующие компиляторы C для x86 было потрачено огромное количество ресурсов, чего нельзя сказать про Эльбрусы. Чтобы скомпенсировать это неравенство, имеет смысл приложить максимум усилий разработчика теста для увеличения IPC путём подсказок компилятору и переписыванию некоторых кусочков кода вручную.
Civil
07.09.2021 11:13На оптимизирующие компиляторы C для x86 было потрачено огромное количество ресурсов, чего нельзя сказать про Эльбрусы.
Не факт. LLVM относительно новый, с фокусом на множество языков и архитектур, 4сли смотреть на его развитие, то можно заметить что огдостаточно быстро достиг 90% скорости gcc (да, остальные 10% были трудными и заняли годы), в то же время llc делают лет 20 на практике (не тратя много сил на фронтэнд, он же там покупной), а если считать теоретические изыскания то лет 30. Притом это была команда full time разработчиков.
Чтобы скомпенсировать это неравенство, имеет смысл приложить максимум усилий разработчика теста для увеличения IPC путём подсказок компилятору и переписыванию некоторых кусочков кода вручную.
Только в реальной жизни разработчики крайне редко хотят таким заниматься (это будут буквально единицы людей). Так что для создания ситуации из реальной жизни ничего как раз компенсировать не нужно.
VlK
07.09.2021 11:35+3LLVM относительно новый, с фокусом на множество языков и архитектур, 4сли смотреть на его развитие, то можно заметить что огдостаточно быстро достиг 90% скорости gcc (да, остальные 10% были трудными и заняли годы), в то же время llc делают лет 20 на практике (не тратя много сил на фронтэнд, он же там покупной), а если считать теоретические изыскания то лет 30. Притом это была команда full time разработчиков.
Если вы знакомы с историей компиляторов, то знаете, что 80% производительности от LLVM/GCC для ограниченного набора архитектур может сделать единственный увлеченный энтузиаст за год-два. Пример - qbe. Или изолированная команда исследователей (libfirm).
Реальная же борьба в компиляторах уже давно идет за последние 1-3%. Более того, LLVM только в последние 3-4 года стал сравним с GCC, и это при том, что в LLVM вкладывают средства такие гиганты как Apple и Google. Сотни людей делали научные карьеры на исследованиях в этом фреймворке.
И все равно GCC поддерживает больше архитектур и во многих бенчмарках опережает LLVM.
Команда же llc никогда даже рядом не стояла ни с LLVM, ни с GCC по вложенным человеко-годам.Civil
07.09.2021 12:04+1Если вы знакомы с историей компиляторов, то знаете, что 80% производительности от LLVM/GCC для ограниченного набора архитектур может сделать единственный увлеченный энтузиаст за год-два.
Но дело в том, что в случаи с llc мы не видим хорошей работы даже в 80% случаев.
Более того, LLVM только в последние 3-4 года стал сравним с GCC, и это при том, что в LLVM вкладывают средства такие гиганты как Apple и Google.
А это уже немного подмена понятий начинается, к сожалению. Потому что компаний конечно много вкладывает деньги и силы, но каждая компания заинтересована в узком круге задач, который некорректно обобщать на C + оптимизации под x86, о которых сейчас речь.
Сотни людей делали научные карьеры на исследованиях в этом фреймворке.
Я вот затрудняюсь сказать что именно сотни, но десятки точно делали (опять же если мы выделяем общие оптимизаторы в бэкэнде). Вопрос только в другом - сколько из этих исследований реально были воплощены в жизнь (многие исследовательные работы так и остаются исследовательскими работами, к сожалению).
Команда же llc никогда даже рядом не стояла ни с LLVM, ни с GCC по вложенным человеко-годам.
Если сравнивать весь llc со всем llvm - не буду спорить, но речь идет о том чтобы выделить только оптимизатор под 1 архитектуру (e2k и x86 соответственно) и попытаться сравнить времязатраты на тот и другой в человекогодах.
RetroStyle
06.09.2021 09:23+9Во-первых, хочу заметить, что полемические приемы автора мягко говоря сомнительны. Все эти заходы вроде "Алексей, дело в том, что жизни всё устроено так...". И далее следует довольно наивный нарратив на тему о том, как же жизнь устроена по мнению автора. Причем, в таком тоне, как будто тут вещает если не Сократ, то как минимум Мишель Фуко. Автор даже не профессор философии и не доктор экономических наук. Так не слишком ли много он на себя берет, начиная рассуждать в таком тоне на подобные темы?
Теперь, по сути вопроса. Все претензии сводятся к банальному батлу VLIW vs RISC. Уже столько копьев сломано на этой теме, причем, экспертами такого уровня, что надо обладать немалой смелостью (или глупостью), чтобы после всех мудрецов высказавшихся за и против, начать на голубом глазу безапелляционным тоном тут "учить" про превосходство RISC перед VLIW. Причем все аргументы давно уже высказаны, разобраны и изучены - ничего нового автор в эту полемику не привносит. Поневоле вспоминается классическое: "Солдаты! Вы знаете, что я вам могу сказать, и я знаю, что вы мне можете ответить."
На мой взгляд, рассудить этот спор может только практика. Пока у МЦСТ получилось выкатить на рынок рабочие сервера на архитектуре Эльбрус и провести ряд реальных внедрений. Это аргумент гораздо более сильный, чем все гипотетические рассуждения, который дает объективный повод для осторожного оптимизма касательно будущего VLIW вообще и Эльбруса в частности.
Civil
06.09.2021 09:59+22На мой взгляд, рассудить этот спор может только практика. Пока у МЦСТ получилось выкатить на рынок рабочие сервера на архитектуре Эльбрус и провести ряд реальных внедрений. Это аргумент гораздо более сильный, чем все гипотетические рассуждения, который дает объективный повод для осторожного оптимизма касательно будущего VLIW вообще и Эльбруса в частности
А где логическая связь между первой частью (выкаткой рабочих решений) и оптимизмом? Факт наличия продаж и внедрений ознает только то, что был факт продаж и внедрений (плюс в копилку маркетолог) и это никоим образом не говорит о качестве архитектуры или ее будущем. Посмотрите на пример Itanium'а, который продавался, но при этом является эталонным примером того что VLIW нечего ловить в GP CPU (и по заявлениям alexanius'а Эльбрус не во всем бы обогнал итаниум при равных частотах).
RetroStyle
06.09.2021 10:10-5Логическая связь между "выкаткой рабочих решений" и осторожным оптимизмом по поводу "будущего" Эльбрусов на мой взгляд очевидна. Если процессоры производятся, поставляются и эксплуатируются, то есть обоснованная надежда, что эта тенденция продолжиться. У Итаниума не получилось. Да, это тоже довод. Но не фатальный, IMHO.
Я не готов ввязываться в холивар VLIW vs RISC. Скажу только, что я в курсе кто и как высказался - об это много писали даже и здесь на хабре. Я свое отношение уже высказал выше: повторять все аргументы с обеих сторон не вижу смысла.
Civil
06.09.2021 10:33+16Логическая связь между "выкаткой рабочих решений" и осторожным оптимизмом по поводу "будущего" Эльбрусов на мой взгляд очевидна. Если процессоры производятся, поставляются и эксплуатируются, то есть обоснованная надежда, что эта тенденция продолжиться.
На тему очевидности я не согласен. Также как не согласен что корректно распространять "процессор производится" на "повод для осторожного оптимизма касательно будущего VLIW вообще и Эльбруса в частности."
Для оптимизма, как мне кажется, нужно наличие объективных преимуществ, а иначе это легко может оказаться просто безысходностью со стороны заказчика (обязан покупать то, что не нравится). Более того хотите немного переиначу ваш аргумент, как пример недопустимости аналогии?
Пессимизма касательно будущего Эльбруса и VLIW в частности добавляет то, что МЦСТ до сих пор производит SPARCи (r2000) и то что известные военные комплексы с Эльбрусами основаны на SPARCах. Это очевидно означает неуверенность разработчика и заказчика в будущем VLIW процессоров.
Надеюсь такая аналогия покажет объясняет, почему Ваш вывод не очевиден?
RetroStyle
06.09.2021 10:54Нет, не покажет и не объясняет. То, что МЦСТ производит что-то еще никак не отменяет того факта что им удалось вывести на ранок и внедрить продукты на архитектуре Эльбрус. В любом случае, вы имеете право на свое мнение. Я останусь при своем. А время покажет, загнутся ли эльбрусы или же их производство будет нарастать. Я бы скажем купил акции МЦСТ сейчас.
Civil
06.09.2021 11:15+11им удалось вывести на ранок
Даже к этому есть вопросы. Потому что свободной продажи по сути нет, а количество заказов процессоров (и соответственно очереди за ними) остаются огромными.
Я останусь при своем.
Да, само собой. Просто решил указать что у вас в логической цепочке есть ошибка и такой переход недопустим.
RetroStyle
06.09.2021 14:51-2Нет, вы не нашли ошибки в моей логике, а лишь рассказали о том, что "вам кажется".
На ошибку в вашей логике я указал как раз вам. И это действительно логическая ошибка, а не "так кажется".
Civil
06.09.2021 15:00+3Нет, вы не нашли ошибки в моей логике
Не соглашусь. Ваша логическая ошибка в том что вы приравниваете наличие каких-то продаж к шансу на светлое будущие, полностью игнорируя техническую составляющую и то что даже у плохих товаров случаются продажи.
а лишь рассказали о том, что "вам кажется".
Можно цитату, это доказывающую?
На ошибку в вашей логике я указал как раз вам
И на это, можно, пожалуйста, цитату? Не помню чтобы вы указывали на какую-либо ошибку в логике.
exec77
07.09.2021 17:05+1Позвольте заметить, что используя метод от обратного к вашему утверждению: "у плохих товаров случаются продажи" можно ли утверждать, что: "у хороших товаров продажи не случаются"? Буду признателен, если вы придете пример отличного товара, который не имел продаж.
Считаю, что наличие продаж (неважно каким методом обеспеченных) - это позитивный знак для любого начинания в целом, нежели "классные технические перспективы" и полное отсутствие продаж. Вспомним историю Theranos? За технику отвечал целый лауреат премии Шао в области молекулярной биологии. Супер перспективно и технически обоснованно (на допустимом в тот момент уровне).
Civil
07.09.2021 17:50Позвольте заметить, что используя метод от обратного к вашему утверждению: "у плохих товаров случаются продажи" можно ли утверждать, что: "у хороших товаров продажи не случаются"?
Метод "от обратного" обычно применяется в математике. Укажите пожалуйста что позволило вам сделать выводы, что я говорю в математическом поле?
Я, например, не считаю что спор выше можно к таковому отнести, а значит "от обратного" не применимо напрямую к фразам (и более того, это тоже будет примером подмены совпадения на следствие, как делал человек, с которым я дискутировал).
Считаю, что наличие продаж (неважно каким методом обеспеченных) - это позитивный знак для любого начинания в целом, нежели "классные технические перспективы" и полное отсутствие продаж. Вспомним историю Theranos? За технику отвечал целый лауреат премии Шао в области молекулярной биологии. Супер перспективно и технически обоснованно (на допустимом в тот момент уровне).
Theranos хороший пример того, что продажи и перспективы - вещи не связанные друг с другом (потому что у них как раз продажи были, а вот технология отсутствовала даже в теории, на момент продаж).
exec77
07.09.2021 18:19Вы запутались. Вернее перепутали математику и логику.
Метод Доказательство «от противного» (contradictio in contrarium), или апагогическое косвенное доказательство, — вид доказательства, при котором «доказывание» некоторого суждения (тезиса доказательства) осуществляется через опровержение отрицания этого суждения — антитезиса. Этот способ доказательства основывается на истинности закона двойного отрицания в классической логике.
Метод применяется в математике, но никоим образом не является следствием математики.
Софистика здесь ни к чему, т.к. я прекрасно понимаю о чем речь и вам меня не запутать.
Theranos - я вам привел в пример о том, что не всегда серьезные технологические обоснования (как в случае обоснование автора заметки о тупиковости VLIW архитектуры в сравнении с RISC) приводят к успешности проекта. Современный капиталистический рынок живет по принципу "fake it till you make it", а факт продаж является главным мерилом потенциала проекта. Капитализация компании на любых раундах венчура строится на продажах или ожидании продаж. Поэтому для меня очень странным является факт отрицания значимости продаж Эльбруса в признании перспектив этой платформы.
dem0crypt
06.09.2021 16:39Скажите пожалуйста, какие из военных комплексов используют SPARC?
Civil
06.09.2021 16:55Поищите где используется Эльбрус-90Микро, на эту тему информации не очень много, но есть в том числе в видео с которых начался цикл статей (да и почти каждое видео с историей МЦСТ упоминает про них и их использование в вооруженных силах).
Qetzlcoatl
06.09.2021 10:46+9Я скажу даже больше. "У Итаниума не получилось" в первую очередь не по техническим, а по, кхм, "маркетинговым" причинам что-ли. Когда эпичный переход HP (а Itanium по большому счёту только HP и двигало) на Itanium только начался, я работал в компании, которая эксплуатировала сервера на ВСЕХ более менее распространённых в то время процессорных архитектурах, и в которую HP сами подогнали свои новенькие сервера "для портирования решения". А чуть позже работал в самой HP. И после неё в Sun. Так что я знаком с восприятием решений на Itanium со всех сторон - и производителя, и конкурента производителя, и пользователей, и своим внутренним, и ближайших коллег, и широкого круга IT-профессионалов. Я не помню, что бы я испытывал проблемы в производительности решения на Itanium или мне кто-то со стороны указал на явный провал "в цифрах". Стоящие рядом 2 сервера HP, один на PA-RISC, второй на Itanium, одного класса и поколения в практичекси идентичной конфигурации, давали идентичные цифры, что в чистой производительности БД, что в терминах конечной производительности приложения. Ключевым было недоверие пользователей, активно подогреваемое ВСЕМИ конкурентами, к тому, что HP (и Intel) имеет силы и главное желание/волю, поддерживать и развивать архитектуру Itanium на каком-то вменяемом уровне в какой-то вменяемой перспективе.
Civil
06.09.2021 11:18+1один на PA-RISC
Не очень удачный пример. Отношение к PA-RISC даже в то время было не очень и люди не особо его любили (и видели мало перспектив у платформы).
Qetzlcoatl
06.09.2021 11:45+4Во-первых, не сталкивался с таким мнением. Ни у коллег, ни сам так не считал. Единственная "лёгкая неприязнь" к PA-RISC была только у тех, кто был фанатом Alpha и считал, что выбирая из Alpha и PA-RISC выбор нужно было делать в пользу Alpha.
Во-вторых, как это опровергает тот факт, что между PA-RISC и Itanium в серверах одного поколения и класса не было принципиального отрыва/отставания в производительности "конечного приложения"? Хорошо, давайте возьмём более широко - в сопоставимых конфигурациях поздние Alpha, ранние Itanium и современные им PA-RISC, Power и SPARC давали сходные цифры в терминах производительности конечного приложения. Из стройного ряда не выпадал никто. Даже x86 можно было довести до сопоставимых цифр тюнингом ядра и правильным выбором файловой системы для БД. Классы приложений, которые я имел счастье "сравнивать" своими руками - банковские системы и биллинговые системы сотовых операторов.Civil
06.09.2021 13:34+2Во-первых, не сталкивался с таким мнением.
Я не слышал о PA-RISC ничего хорошего от людей, которые писали этот самый софт. Его ругали за странность архитектуры и то что это делало написание производительного кода крайне затруднительной.
Даже x86 можно было довести до сопоставимых цифр тюнингом ядра и правильным выбором файловой системы для БД.
Вот это кстати куда ближе к причине провала Itanium'а, PA-RISC'а и прочих. Зачем брать дорогое специализированное и очень закрытое железо (привязывая по сути себя к его производителю), когда есть дешевый и относительно открытый x86? Тем более не забывайте что Итаниум должен был выйти в 1998 году изначально, а вышел по факту в середине 2001.
Qetzlcoatl
06.09.2021 14:04+4Я не слышал о PA-RISC ничего хорошего от людей, которые писали этот самый софт.
Не знаю, у меня противоположный экспириенс, ни каких специфических жалоб. 5 лет работы в разработчике банковского софта.
Зачем брать дорогое специализированное и очень закрытое железо (привязывая по сути себя к его производителю), когда есть дешевый и относительно открытый x86?
В те времена, когда был "рассвет" "дорогого, специализированного закрытого железа" x86 мог предложить только работу с entry level нагрузкой. Максимум 4 процессора в системе, как следствие ограничение на объёмы оперативной памяти, детские болезни ядра Linux - слабые диспетчеры задач, ввода/вывода, убогие ФС и менеджеры томов, отсутствие или зачаточное состояние асинхронного и прямого дискового io и т.п..
Скажу больше, если бы не провал Itanium (повторюсь, больше "ментальный", чем технический), после которого HP вынужден (!) был дрейфовать в сторону x86 и тянуть x86 за уши в enterprise, x86 так и остался бы в entry level - mid range, тогда как в high end до сих пор рулили бы разные RISC-и. Хотя, как побочный эффект, Linux, может быть, был бы более "вылизан" для entry level.
Civil
06.09.2021 14:55+1Максимум 4 процессора в системе, как следствие ограничение на объёмы оперативной памяти, детские болезни ядра Linux - слабые диспетчеры задач, ввода/вывода, убогие ФС и менеджеры томов, отсутствие или зачаточное состояние асинхронного и прямого дискового io и т.п..
Смотрите, если мы говорим о timeline'е, то Merced вышел в 2001 году, через год вышел Itanium 2, но уже в 2003 году AMD представила x86-64 и Opteron'ы которые умели в 8-и процессорные системы и умели в много памяти. Таймлайн сам по себе был очень жесткий и не в пользу Итаниума.
Еще не стоит забывать что начало 2000-х как раз момент становления FAANG'а и им сопутствующих как IT компаний, которые изначально избрали подход в покупке commodity железа за дешево и делать ПО с учетом особенностей таких решений. Как раз эти моменты очень сильно перекроили рынок, потому что крупный Enterprise может и хотел себе привычное большое железо, но появилось много мелких игроков, которые умели использовать дешевое железо для достижения результата. И по объему продаж и прибыльности вскоре "много мелких" оказалось лучше чем "мало огромных".
А в какой момент, можно сказать, HP сдались и опустили руки? По косвенным признакам они еще в 2008 году платили интелу за разработку и выпуск новых моделей, то есть явно до 2008 года (включительно) считали что шансы есть.
В общем не знаю, кажется что это все таки технический провал в первую очередь, и связанный с тем что x86 оказался неплох и доступен (дешевое TCO), в то время как для специализированных процессоров практически не осталось места (сейчас те же банки постепенно уходят спокойно в облака на x86 со своих дорогих железок).
Qetzlcoatl
08.09.2021 12:03Вы противоречите сам себе. С одной стороны утверждая что с выходом Opteron в 03 году Iyanium-у "настал капец", а с другой стороны подтверждая. что запрос клиентов на Itanium в 08 у HP был таков, что бы склонить их к целесообразности разработки нового поколения Itanium.
В 03 году Opteron, конечно, вышел, и, спасибо плотному сотрудничеству с Sun, умел в 8-сокетные сервера, но ещё несколько лет не было нормальных программных решений (ОС, СУБД и т.д.), которые позволяли бы эффективно такие системы использовать. Да и стоимость таких серверов ничем не уступала стоимости Itanium/PA-RISC/Power/SPARC серверов. Всё "бодание" x86 vs не-x86 шло в плоскости 2-сокетных машин и "умения в горизонтальное масштабирование".
Победа x86 в итоге свершилась не по технологическим, не по экономическим, а по, скорее, "политическим" причинам. Например, "смерть" SPARC в "борьбе" с x86 является следствием подковёрных игр представителей высшего менеджмента Oracle борьбе за "трон" (пост CEO) при грядущем "отходе от дел" Ларри Эллисона.
Про "банки уходят в облака" отдельно улыбнуло. Прям "табор уходит в небо". :) Не пересказывайте эту байку представителям российских и немецких финансовых структур, что бы не попасть в неловкую ситуацию.Civil
08.09.2021 13:20Вы противоречите сам себе. С одной стороны утверждая что с выходом Opteron в 03 году Iyanium-у "настал капец",
Во первых я не говорил что настал капец, а я говорил что это был жесткий тайминг и весомый кусок преимуществ испарился.
а с другой стороны подтверждая. что запрос клиентов на Itanium в 08 у HP был таков, что бы склонить их к целесообразности разработки нового поколения Itanium.
Во вторых я ничего не говорил про запрос клиентов у HP. Более того, насколько я знаю, публично количество клиентов на Итаниумы у HP в 2008 году неизвестно. Так что это можно использовать как подтверждение веры HP в платформу, но не более того.
В 03 году Opteron, конечно, вышел, и, спасибо плотному сотрудничеству с Sun, умел в 8-сокетные сервера, но ещё несколько лет не было нормальных программных решений (ОС, СУБД и т.д.), которые позволяли бы эффективно такие системы использовать.
Windows Server 2003 x64 вышел примерно в том же году, Linux в amd64 научился практически сразу (с софтом да, где-то год-полтора еще надо было потерпеть). Тем более это открывало простор для горизонтального масштабирования в рамках виртуальных машин на одном сервере, если уж очень хотелось "здесь и сейчас"
Да и стоимость таких серверов ничем не уступала стоимости Itanium/PA-RISC/Power/SPARC серверов
К сожалению я недостаточно хорошо помню цены на 8-и сокетные сервера в те времена, а также довольно плохо помню цены и на итаниумы со спарками. Поэтому с одной стороны не готов Вам верить на слово (как минимум потому что на рынке commodity серверов всегда были игроки второго и третьего эшелона, которые продавали железо качеством похуже, но и значально дешевле чем HP и прочие крупные товарищи).
Например, "смерть" SPARC в "борьбе" с x86 является следствием подковёрных игр представителей высшего менеджмента Oracle борьбе за "трон" (пост CEO) при грядущем "отходе от дел" Ларри Эллисона.
Извините, но смерть SPARC случилась по факту раньше чем Oracle купил SUN. Посмотрите на доли на рынке и на revenue в период до января 2010 года (момент окончания покупки SUN'а).
Если вкратце, то начиная с 2004 года SUN выпускает x86 сервера, потому что доля на рынке начинает падать (хотя выручка все еще растет). В 2007 году SUN уже не первые на рынке, а всего лишь третьи по выручке и 6-ые по доле.
То есть к моменту покупки их Oracle'ом там никакого доминирования не было уже годы. На тот момент (если посмотреть) x86 владел уже половиной рынка серверов, а доля SPARCов из года в год только падала. (если что я понимаю что по хорошему надо еще отдельно смотреть на доли SPARC-решений от Fujitsu, но они в целом вели себя также как SUN, а прям полноценный таймлайн делать это очень много кропотливой работы)
В общем и целом у SUNа было все плохо еще когда он был SUN'ом. Так что не вижу как борьба за власть в Oracle могла повлиять.
Про "банки уходят в облака" отдельно улыбнуло. Прям "табор уходит в небо". :) Не пересказывайте эту байку представителям российских и немецких финансовых структур, что бы не попасть в неловкую ситуацию.
Так а где байка то? Вбейте в поиск:
Deutsche Bank signs cloud deal
HSBC Cloud Strategy
Goldman Sachs Cloud
JPMorgan Chase cloud
Это только про крупные, которые заявили о заключении контрактов предполагающих миграцию критичных для банка систем в облака. В целом почитайте тот же forbs с их аналитикой или аналитику от accenture (прошу прощения что не оригинальный язык, искал информацию про российские банки).
SerjV
06.09.2021 14:17+5Если выкатить на рынок по принципу "а ежели кто не купит - тому
отключим газвообще больше ничего не дадим купить" - то да, это воистину гениальный маркетинговый ход. Гениальнее только анекдотичное(ли?) изображение Северной Кореи, когда за спиной у покупателя стоят пара автоматиков, чтобы покупатель не передумал.И это не говоря уж о том, что они продают серверы с официальным пиратским софтом на нём! Это что ж получается, отечественное импортозамещение зиждется на банальной краже чужой интеллектуальной собственности?
N-Cube
07.09.2021 07:13+1А чему вы удивлены? В СССР целые институты сидели и препарировали под микроскопами зарубежные микросхемы, чтобы потом сделать отечественные аналоги . Из-за неизбежных ошибок нужны были годы, чтобы эти аналоги приемлемого качества изготовить и все равно по размеру и характеристикам они уступали оригиналам. А с копированием ПО и Китай втянулся в ту же игру и Россия.
SerjV
07.09.2021 13:53Угу, советские микросхемы - самые мобильные микросхемы в мире: 6 ножек и 4 ручки для удобства переноски!
Но в советское время, во-первых, не всё скопитыренное было спирачено - кое-что просто не защищалось на тот момент, а во-вторых - местами напоминает нынешний тыринг из опенсорса, что символично. Ну ладно, каперство - это пиратство, поощряемое государством, в некоторым смысле тырят друг у друга все.
Но пиратить то, что и так отдают бесплатно - это уже перебор.
N-Cube
07.09.2021 14:57Да я вовсе не про законность или мораль, а про то, что такое пиратство заставляет безнадежно отставать. Даже с пиратством опен сорс кода - чем сильнее кодовая база отличается от оригинала, тем дороже и сложнее все это поддерживать и обновлять из основной ветки, что приводит ко все большему отставанию от апстрима. Вот, скажем, китайцы с их (еще недавно) безграничными трудовыми ресурсами копию Amazon AWS запустили - алибаба клауд, так там сортировка файлов в юникодной американской локали оказалась ну дико странная, так что все операции с сортировкой файлов возвращают непредсказуемый результат. Может, уже починили, но суть копирования с доработкой и поддержки получившегося франкенштейна понятна.
SerjV
07.09.2021 15:32Даже с пиратством опен сорс кода - чем сильнее кодовая база отличается от оригинала, тем дороже и сложнее все это поддерживать и обновлять из основной ветки, что приводит ко все большему отставанию от апстрима.
Почему иногда проще и дешевле отдать что-то в апстрим, чем иметь секс с поддержкой этого самостоятельно...
В этом смысле да, согласен.
N-Cube
06.09.2021 15:25+12Пока у МЦСТ получилось выкатить на рынок рабочие сервера на архитектуре Эльбрус…
На моей памяти полемике про Эльбрусы уже больше 20 лет. И вы знаете, за все это время я не видел ни одного эльбруса. Вот и с интел и амд и армами и микроконтроллерами всякими - пожалуйста, работал и работаю, а эльбрусов как не было, так и не видно даже на горизонте. Так что про рынок здесь говорить не приходится вовсе, какое-то очень нишевое решение и автор пытается как раз показать, почему. Ах да, в новостях недавно снова видел, что десктоп «для всех» на эльбрусе вышел - так на сайте заявленного в новости производителя написано, это они госконтракт на его разработку получили, скоро начнут делать. И так все 20+ лет.
PetrEEEfim
06.09.2021 16:08+3и еще лет 20 будут так же говорить, если, конечно, ничего кардинально
не поменяется
cepera_ang
06.09.2021 16:14+5Воистину. Читал всё те же споры про эльбрусы ещё в школе, году в 2004 и уже тогда он был в состоянии "вот-вот спустится с горы и захватит весь рынок".
bipiem
06.09.2021 18:00+4Помню смотрел теледачу в 90-х на центральном канале (долгую). Ведущий, два академика и Бабаян. Обсуждали развитие микропроцессоров.
Как сейчас помню заявление Бабаяна на всю страну: пройдет каких-то 5 лет и наш Эльбрус появится в каждой семье (не дословно).
Периодически похожие заявления от новых "Эльбрусовцев" я слышу каждые пять лет. И 15 лет назад были заявления, что "вот-вот" появятся в магазинах. Смешно … Хотя конечно же, грустно. Веры в него давно уже нет, хотя в некоторых военных НИИ на них какие-то поделки демонстрируют.
JerleShannara
06.09.2021 21:46+4Если хочется просто поржать (как конь, именно так), то можно синхронно читать анонсы Интела и заявления Бабаяна тех лет. Будет что-то типа «Интел планирует использовать двухканальный контроллер RDRAM для своих новых платформ [некоторое время спустя] Бабаян заявил, что в новом Эльбрус-2000 будет четырехканальный контроллер RDRAM»
Arbane
07.09.2021 13:36+1На рынке ничего не присутствует. Не читая Хабр узнать об Эльбрусе почти невозможно. Платить деньги за рабочую станцию на Эльбрусе некуда и незачем.
Очень это похоже на "Вы не понимаете, это другое". После нескольких адекватных коментариев очень разочарован нахлынувшими "солдатами отечественного", которые статью похоже не поняли от слова совсем.
Страну любите, но глупость порицайте.
belav
06.09.2021 09:26+3Как Вы насчитали 13 тактов? Это же VLIW, там несколько конвейеров и несколько команд делаются за такт. В этом их фишка.
Про неоптимальность VLIW и сложность компилятора, Вы спросите у тех, кто работал с dsp серии c6000 от ti. Конечно, есть нюансы, но вполне не плохие молотилки для обработки данных.
Также не понял, почему тактовая частота для VLIW ниже, чем для RISC. Но это вопрос, скорее, не автору статьи. Надо будет почитать.
Соглашусь, что такая архитектура хорошо работает под определённые задачи. Тот же диспетчер задач в ОС будет постоянно сбрасывать конвейер или дожидаться опустошения. Здесь не хватает host процессора, который будет подготавливать и распределять данные для VLIW блоков.
a1batross
06.09.2021 10:04+11Компилятор кстати помогает считать такты. Если убрать галочку в Filter->Comments, то между ШК будет комментарий с тактами.
Armmaster Автор
06.09.2021 11:57+10Несколько конвейеров тут значения не имеют.
Вам верно подсказали - можете включить разметку тактов, там всё указано.
belav
06.09.2021 12:11-3Ну так привели бы в статье такты и как их считали.
Вы просто не работали с такой архитектурой, если просто суммируете такты.
Armmaster Автор
06.09.2021 12:42+21Вы просто очередной неуч, который пишет непойми что. Я 10 лет разрабатывал бинарку под Эльбрус и считаю производительность и такты для него с закрытыми глазами. Если бы я тут ещё и такие нюансы разбирал, как считать такты, статья бы в монографию превратилась. В конце концов можете обратиться к сотрудникам Мцст, которым доверяете. Они подтвердят, что цифры абсолютно верные
belav
06.09.2021 12:53+3Ну тогда помогите неучу найти истину: как в VLIW цикл может выполняться за 13 тактов, если там 6 блоков с командами? Или там конвейер на 2 такта?
Armmaster Автор
06.09.2021 13:09+12Нет, там в некоторых ШК стоят операции nop с циферкой, означающей сколько тактов после исполнения данной ШК процессор должен побулькать в ожидании результатов. Если вы все суммируете, то получите 13 тактов
belav
06.09.2021 13:23+1Тогда тут уже проблема компилятора, что он не смог развернуть код, чтобы уложить в конвейер.
Armmaster Автор
06.09.2021 13:38+13Всегда пожалуйста. Что касается проблем компилятора - так в этом и вся сол - не справляется он. Нельзя только статическим анализом адекватно разрешить все зависимости, возникающие в коде
belav
06.09.2021 13:45Ну, ti много сил вложил в компилятор. Получился не плохой. Но все равно приходилось подсказывает с помощью pragma.
Тут вопрос в развитии компилятора. Сама архитектура процессора вполне достойная.
А рисовать самому графы и оптимизировать конвейер на ассемблере дело неблагодарное.
hhba
06.09.2021 15:57+2Ну, ti много сил вложил в компилятор. Получился не плохой.
Вот вот. Сил вложено много, и все равно приходится местами что-то делать ручками. И все равно разные бенчмарки последних лет говорят о том, что где-то С66х проигрывают SIMD GPCPU, где-то они проигрывают спецускорителям, где-то FPGA, где-то GPU, причем это все речь идет о достаточно удобных приложениях, не то что "вместо мучений с DSP будем мучиться с FPGA". Это конечно не означает смерть DSP, наоборот, они цветут и пахнут, но речь о том, что широкая команда еще не синоним успеха во всем. В чем-то конкретном - да.
amartology
06.09.2021 16:47+7Тут вопрос в развитии компилятора. Сама архитектура процессора вполне достойная.
Ненененене, в случае VLIW эти вещи предельно плотно взаимосвязаны, и разделять ни в коем случае нельзя, а то получится классическое «к пуговицам претензии есть?»
Пользователю не важно, по какой именно причине его софт работает медленно, и продукт на рынке — это не железка, а железка с софтовой экосистемой.kmeaw
07.09.2021 07:44+3Пользователю не важно
Железку пользователь уже купил, а вот компилятор он может новый (когда-нибудь) скачать и пересобрать свои исходники. Вот если бы было доказательство, что некоторая оптимизация невозможна на e2k, то можно было бы утверждать, что с архитектурой точно есть проблема.
edo1h
06.09.2021 20:33а руками получится? я не думаю, что много времени уйдёт на такой простой пример.
JerleShannara
06.09.2021 21:50+2Руками вы либо под конкретную задачу будете постоянно допиливать компилятор, либо постоянно переписывать код (чтобы он нравился компилятору), либо вечно писать ассемблерные вставки, чтобы «уж наверняка правильно всё нагрузило».
edo1h
06.09.2021 21:56вопрос был это плохой компилятор или такая неудачная для эльбруса задача.
первое хотя бы теоретически имеет перспективы быть исправленным, с вторым, очевидно, грустнее.
Armmaster Автор
07.09.2021 16:37Я там сделал в тексте ремарку по данному поводу - там проблема в том, что есть зависимость между load и store, похоже из-за этого там в компиляторе весь анализ отвалился. Ну и плюс в реальности без понимания, какой код реально горячий, очень сложно хорошо код оптимизировать (это к рассказам Алексея про чудесные эвристики).
В общем, навскидку, этот цикл можно соптимизировать где-то до 7-8 циклов. Наверное, можно даже подумать о большем (у меня есть идеи, но их надо проверять), но это точно в реальной жизни фиг применишь. Только ручная оптимизация по факту. Как в Spec2006/2017 для Эльбруса ))
Armmaster Автор
07.09.2021 17:34+1В общем там ниже написали, что если вместо -O4 подать -O2 (не спрашивайте меня в чём логика), то цикл соптимизируется намного лучше (как раз таким он навскидку должен был быть на мой взгляд). Это уже ближе к теор максимуму. Там 6 тактов получилось.
edo1h
07.09.2021 22:43лучшее, что у меня получилось на x86 — 2 такта на цикл на epyc'е 7453 и xeon'е 4214.
i5-3570 ≈2.6, как и в статье, ryzen 5950x ≈4.5 (!?!)
Armmaster Автор
07.09.2021 23:352 это норм, где-то тут мы уже должны упираться на современных серсверных процах. Но красота ОоО в том, что можно ещё добавить транзисторов и можно сделать, например, 1.5. Или даже ещё лучше. Просто тут уже начинаются трейдофы, насколько в реальной жизни это будет полезно с учётом затраченных транзисторов и пауэра. Поэтому там польза от уменьшения нанометров есть - можно добавить транзисторов и ещё улучшить микроархитектуру. А во VLIW от этого толку никакого. Т.е. дальше разрыв по микроархитектурной скорости будет только расти
OpenA
07.09.2021 17:50+1считаю производительность и такты для него с закрытыми глазами
Ты молодец, но ты забываешь что это именно эльбрусовская система команд тебе это позволила сделать. Для интела ты свой навык применять не можешь, ты не видишь микрокод и не знаешь что внутри происходит: https://godbolt.org/z/qaxdEeGo6 10~13 тактов интел тратит, никакие не три. Хватит людям в уши лить.
Armmaster Автор
07.09.2021 18:05+3Мне для этого не нужен никакой микрокод. Я просто запустил и перфом снял все метрики. Там получается ровно 3 такта. Возьмите и проверьте.
Dim0v
07.09.2021 22:13+2А теперь включи оптимизации как в статье (-O2 или выше), выбери компилятор как в статье (gcc 7.5, а не кланг) и внезапно получишь во-первых ассемблерный листинг как в статье (а не колбасу на 30+ инструкций), а во-вторых - не поверишь, 2-4 такта на итерацию. Ну ты понял наверное. Прям как в статье.
https://godbolt.org/z/KE5hqjsqP
Ну и плавающие 2-4 такта - это на godbolt. На реальном железе с +/- стабильной нагрузкой у меня 1.7-1.8 тактов. Zen 2
OpenA
08.09.2021 18:14+1А теперь включи оптимизации как в статье (-O2 или выше), выбери компилятор как в статье (gcc 7.5, а не кланг) и внезапно получишь во-первых ассемблерный листинг как в статье (а не колбасу на 30+ инструкций), а во-вторых - не поверишь, 2-4 такта на итерацию.
Он же ОоО суперскаляр, у него все есть в железе и ему не нужно полагаться на компиляторы как какой нибудь там тупиковый VLIW. Они вон все ненадежные: https://godbolt.org/z/8qe454f4z компиляешь с максимальными оптимизациями -O3 а результат хуже чем с -O2 в два раза - 3.3 такта против 1.75
Гораздо проще и лучше транзисторов еще там сям приляпывать и вообще выкинуть компиляторы как класс на свалку истории. Пользователь только спасибо скажет, раньше одним и тем же процессором приходилось обходится по несколько лет, а теперь скажет с предвкушением откладываю на осенний сезон аппаратных обновлений.
Dim0v
08.09.2021 22:26Не уверен, что в этом есть смысл, но все же отвечу на это ёрничанье по существу, насколько это возможно.
https://godbolt.org/z/8qe454f4z компиляешь с максимальными оптимизациями -O3 а результат хуже чем с -O2 в два раза - 3.3 такта против 1.75
Если внимательно посмотреть, то можно заметить, что ассемблерный код сортировки для -О2 и -О3 одинаковый. Отличается только код
print_array, выполнение которого не замеряется. Так что разброс значений объясняется не ненадежностью чего бы то ни было, а банально плавающей нагрузкой на сервера godbolt и и/или выполнением кода разными машинами. Да, такое бывает. Поэтому мерять производительность чего угодно на shared хостинге (и даже на VPS) - изначально глупая затея. Приводить результаты этих измерений в качестве аргумента, когда они отличаются даже не на порядок, а всего на 1,5 такта - затея еще более глупая.Он же ОоО суперскаляр, у него все есть в железе и ему не нужно полагаться на компиляторы как какой нибудь там тупиковый VLIW.
Соломенное чучело уничтожено! Поздравляю!
Paskin
06.09.2021 15:01такая архитектура хорошо работает под определённые задачи
С этим вообще никто не спорит - например ISP (процессоры ввода с сенсора изображений) умеют делать довольно сложные вычисления с большой скоростью и параллельно - разные стадии алгоритма над последовательными кадрами. Но как GP CPU они никуда не годятся.
RTFM13
07.09.2021 10:06разные стадии алгоритма над последовательными кадрами.
Только по какому-то очень жесткому алгоритму, они же друг к другу прибиты намертво на этапе компиляции. Синхронизация разных потоков - очень нетривиальная задача для программиста, компилятор тут не поможет. Скорее VLIW подойдет для синхронной обработки каналов многоканального DSP.
По этому на видеокартах это не прижилось.
Но даже на DSP это просится как сопроцессор.
Paskin
07.09.2021 21:50Только по какому-то очень жесткому алгоритму
Да, сканирование сенсора же идет постоянно - и кадры "образуются" один за другим. Ко всем применяется одна и та же последовательность преобразований, для изменения "значительных" параметров вроде разрешения или частоты кадров - большинство систем сенсор-ISP надо "остановить" и перезапустить с новыми настройками.
ruomserg
06.09.2021 09:35+14Я думаю, что уже надо остать от Эльбруса. Когда-нибудь в мемуарах выяснится, что ноги его растут из военных разработок, где не было разговора про GP computation, а надо было бесконечно крутить заранее известный алгоритм (а-ля FFT), но много раз и для многих целей. И алгоритм этот заранее бы на бумаге оптимизировали, на чистом ассемблере написали, приняли на вооружение, и потом бы 30 лет к нему не подходили. В этом случае гораздо надежнее иметь VLIW, где ты можешь сам руками распределить ресурсы и обеспечить гарантированное время обработки критичного потока данных. Да, это нежизнеспособно в мирной жизни — от слова «совсем». Да, если это не кормить грантами и гос.заказом — оно склеит ласты. С другой стороны — на этом продолжает существовать тонкий слой инженеров, которые умеют делать архитектуру, организовывать выпуск, добиваться какого-то выхода годного и т.д. Если часть этих инженеров рано или поздно осознает ущербность подхода эльбруса на ниве GP computation, и организуют свой стартап (с блекджеком и шлюхами, но без VLIW) — и убъют породивший их эльбрус, то последний — по моему мнению — выполнит свою историческию миссию полностью…
newpavlov
06.09.2021 10:12+14>Когда-нибудь в мемуарах выяснится
Так вроде это особым секретом и не является, не?
>Я думаю, что уже надо остать от Эльбруса
Напомню с чего начался нынешний сыр-бор: в Минпромторге решили внимательно подумать над целесообразностью дальнейшего финансирования разработки Эльбруса, после чего МЦСТ начало публично жаловаться на "подрыв доверия" и захотело введения госплана. Разумеется, конкуренты делающие ставку на ARM/RISC-V начали активно суетиться в надежде отъесть кусок бюджетного пирога выделяемого на МЦСТ.
Теперь вопрос: кто на ваш взгляд имеет больше перспектив на хоть какой-то рыночный успех Эльбрус или разработки на основе ARM/RISC-V, особенно учитывая культуру тотальной закрытости первого? Иначе говоря, к Эльбрусу никто бы не приставал если бы МЦСТ разрабатывало его за собственный, а не государственный счёт.
Благо не Эльбрусом единым и в России есть компании обладающие компетенцией в разработке ARM и RISC-V процессоров.
ruomserg
06.09.2021 10:54+4Это их аппаратные игры, я в них не понимаю. Поддерживать конкурентов МЦСТ нужно совершенно точно — монополизм зло. Обрезать в ноль финансирование МЦСТ тоже не следует. С одной стороны, их компетенции с VLIW могут где-то пригодиться. Во-вторых, если их совсем убрать с гражданского рынка, они останутся только на военных заказах — и будут там в закрытой части рожать еще более ужасных кремниевых монстров. Потому что там с обратной связью будет еще хуже чем сейчас: "… использовать процессоры! — Есть использовать процессоры!". С моей (дилетантской) точки зрения — под угрозой сокращения финансирования, заставить МЦСТ сделать pivot и делать для процессоров более традиционной архитектуры (ARM/RISC-V) блоки/сопроцессоры с VLIW для решения специфичных задач. Ну потому что 100% существует ниша, где VLIW будет справляться лучше чем GPCPU. Вылизали же они отдельные тесты — ну так эту бы энергию, да в мирных целях… :-)
newpavlov
06.09.2021 11:05+1>Обрезать в ноль финансирование МЦСТ тоже не следует.
Так никто вроде и не говорит что нужно МЦСТ банкротить прям завтра. Но вот касательно того что на него стоит делать основную ставку (как было до сих пор), тут возникают большие вопросы.
>Ну потому что 100% существует ниша, где VLIW будет справляться лучше чем GPCPU.
Проблема в том, что эта ниша (в моём понимании) чрезвычайно мала. VLIW тут с одной стороны сильно зажат SIMD инструкциями и GPU, а с другой технологией внеочередного исполнения, которое в некотором смысле является "автоматическим" VLIW реализуемым самим железом, а не компилятором.
ruomserg
06.09.2021 11:18У внеочередного выполнения тоже есть свои проблемы. От проблем с безопасностью (потому что как не крути — оно изменяет состояние CPU, и это очень трудно скрыть не потеряв плюшек в виде скорости исполнения программы), и до того, что программисту на уровне прикладного софта очень сложно контролировать загрузку отдельных элементов процессора. Я сейчас фантазирую, конечно — но это может быть неким аналогом «интеллектуальной DMA», или современным вариантом канальных процессоров времен System 370. Традиционный CPU задает источник, приемник, и расположение программы VLIW для канального сопроцессора. А дальше оно само… Причем, тут наличие VLIW может быть даже на руку. Если у вас канальные программы относительно простые — то вы выделяете один набор ресурсов под один канал, другой набор ресурсов под другой. А если оба канала используются одновременно, то их программы объединяются, грубо говоря, логическим «ИЛИ» над индивидуальными программами каналов… И пока программы для VLIW остаются достаточно простыми, у вас все хорошо: нет сложного в разработке и отладке микрокода, не нужен слишком умный компилятор, есть предсказуемое время обработки данных, и т.д. Возможно, VLIW должно сидеть где-то выше ПЛИС, но ниже OpenCL/GPU. Время покажет…
Paskin
06.09.2021 15:06+2VLIW должно сидеть в виде сопроцессора, а загрузкой в него программ должен заниматься ЦП.
Arioch
07.09.2021 15:50Что-то мне кажется, вы сейчас изобрели Cell Broadbane Engine Architecture
Этакую ромашку, с центральным процессором-диспетчером, и (ЕМНИП) 6 "периферийными процессорами". Вот только в реале он умер ещё раньше Итаниума.
https://en.wikipedia.org/wiki/Cell_microprocessor_implementations#Prospects_beyond_45_nm
И думаю, по той же причина общая, у Cell и у VLIW: "протечка абстракции" микроархитектуры в архитектуру, и в результате программирование становится привязано к данному конкретному железу и бесполезно для остальных процессоров, сегодняшних и будущих. В век, когда борются за loose coupling даже программных блоков внутри одной программы, такая жёсткая привязка к железу становится "ядром каторжанина", за исключением специальных ниш - таких как драйверов и firmware, которые по определению привязаны к железу.
Sony/IBM попытались стандартизировать эти "лепестки", но... их просто слишком мало. В отличие от Intel Xe/Knights или как их там, где счёт шёл на десятки, и видеокарт - где на сотни, на Cell даже одного десятка не было. А для какой-нибудь программы на Erlang с несколькими тысячями потоков быстрее основной процессор переключать по наборам переменных, чем бесконечно перезагружать сторонние, которых всего-то пол-десятка. А сделать хоть Cell хоть VLIW на сотни физически одновременных параллельных потоков исполнения - нереально.
А ещё, пожалуй, до них можно вспомнить ARM, а точнее концепцию Transputer. Тоже красивая в теории идея, элегантная до боли, и "не взлетает".
Собственно, "канальныe процессоры" IBM 360 такими и были, интерфейсом подключения железа и не более того. Также можно вспомнить, что в IBM PC AT был отдельный процессор для клавиатуры, но никто туда не пытался вкрячить DOS и программы же. Внутри видеокарт, сетевых карт, винчестеров - там тоже процессоры есть, но никто их как GP не рассматривает (разве что всякие спецслужбы/вирусописатели).
Paskin
07.09.2021 22:10+1Подобная архитектура не только не умерла - но и активно развивается. В современных SoC - есть несколько "обычных" ядер (часто разных), ISP для обработки изображения с камер, GPU, NNPU, baseband и так далее.
В Raspberry Pi GPU даже "главнее" и именно он занимается инициализацией и управлением всей системой - но это исключение, только подтверждающее правило - никто специализированные сопроцессоры как GP не рассматривает, их внутренняя архитектура "заточена" под какие-то узкоспециальные вычисления. А GP, в том числе управление всем этим зоопарком - удел "обычных" ядер.Arioch
08.09.2021 19:01Это другая архитектура, не Cell. Это как архитектура 8086 - с дополнительным сопроцессором 8087 для конкретной узкой функции и ни для чего другого. Кстати, в оригинальном предложении Интел были и другие сопроцессоры (8089), просто IBM не стала их покупать.
никто специализированные сопроцессоры как GP не рассматривает, их внутренняя архитектура "заточена" под какие-то узкоспециальные вычисления
Вот именно поэтому эта архитектура, которую вы описываете, подобна 8086, и а вовсе не Cell, где "периферийные" процессоры были одинаковые и должны были выполнять основную работу.
Для типового же заточенного на конкретную функцию сопроцессора типа 8087 или звукового AC'97 DSP - VLIW просто напросто избыточен. Не нужны там его возможности GP, независимо от эффективности. Сопроцессор должен быть максимально эффективен в своей конкретной функции, а "неэффективную гибкость" оставить центральному процессору.
Elbrus же - это VLIW общего назначения. Не заточенный на, например, трансформацию 3D-каркасов, или сжатие MPEG4. Поэтому идея "Эльбрусы как сопроцессоры" - это будет повторение именно Cell. Не взлетит. А сделать на основе ядра e2k узкофункциональный и маленький блок типа какого-нибудь AES-NI/Padlock тоже не получится.
Vedomir
06.09.2021 13:27+1Да пусть даже за государственный, не такие уж и большие деньги в масштабах страны, но только не надо принудительно внедрять его ко всем государственным организациям.
Civil
06.09.2021 10:13+10С другой стороны — на этом продолжает существовать тонкий слой инженеров, которые умеют делать архитектуру, организовывать выпуск, добиваться какого-то выхода годного и т.д.
Вы понимаете, что это утверждение основано скорее на пропаганде МЦСТ?
В России есть несколько успешных разработчиков железа: НИИСИ с КОМДИВами, Синтакор с Risc-v, Миландр с кучей разных чипов, Байкал Электроникс с Байкал-Т и Байкал-М, Элвис с их процессорами... Вы правда считаете что экспертиза существует и культивируется только в МЦСТ?
Когда-нибудь в мемуарах выяснится, что ноги его растут из военных разработок, где не было разговора про GP computation, а надо было бесконечно крутить заранее известный алгоритм
Для начала хочется выяснить где вообще в ВПК применяется Эльбрус для вычислений. А то известно про Эльбрус-90Микро который SPARC - что он стоит в ракетных комплексах и прочих интересных местах.
Xambey
06.09.2021 11:01Ну он применяется не только в ВПК, пк на Эльбрусах используются в РЖД, и из личного опыта, на НИИ Восход, которая разрабатывает и содержит ЦОД с Государственной системой паспортно-визовых документов нового поколения (ПВДНП) — это той самой, на которой будут крутиться новые паспорта. Еще есть несколько гос. компаний и вроде то ли вузов, то ли школ, где их используют. Эльбрусы там показывают себя весьма достойно.
Civil
06.09.2021 11:29+4Ну он применяется не только в ВПК
В комменте выше речь, как я понял, про "изначально делалось для ВПК". Отсюда и вопрос к автору - где именно они в ВПК?
пк на Эльбрусах используются в РЖД
А их точно закупили?
Эльбрусы там показывают себя весьма достойно.
Мне кажется, "весьма достойно" должно сопровождаться цифрами. Например сколько удалось сэкономить на TCO по сравнению с x86?
belonesox
07.09.2021 14:05должно сопровождаться цифрами
В этом докладе были некоторые цифры http://0x1.tv/20181012BC , но в целом - сильно сэкономили, потому что до альтернатива была в сверхдорогих решениях от IBM, и чтобы сползти с них, использовалось "импортозамещение".
Разумеется, с рыночным небрендовым x86 по TCO вряд ли реально сравниваться, я не видел таких сравнений.
Civil
07.09.2021 14:50+1В этом докладе были некоторые цифры http://0x1.tv/20181012BC , но в целом - сильно сэкономили, потому что до альтернатива была в сверхдорогих решениях от IBM, и чтобы сползти с них, использовалось "импортозамещение".
Это смотрел, очень сильно удивлялся (в плохом смысле) качеству анализа. Если прям по пунктам:
Сами нагрузки достаточно смешные (я про 20 ТБ данных и 4 ТБ базы, как и 40 тысяч запросов в сутки)
Из цифр только "год обслуживания менйфрейма стоит как 130 серверов на Эльбрусах". Они не учитывают стоимость эксплуатации (электричество не бесплатное, адаптация кода под новую архитектуру не бесплатная и т.п.). Про это был слайд, но автор доклада его к сожалению пропустил.
Непонятно почему рассматривались только Эльбрусы, а не, например, сервера на x86 (притом даже брендовые). Как раз при таком редизайне системы напрашивается сравнение Эльбрус vs x86
Отсутствует какой либо анализ системы с точки зрения надежности данных. Но тут авторам benefit of a doubt дается и допустим их все устраивает. Но в рамках таких докладов интересно было бы услышать проводились ли сравнения касательно гарантий доставки сообщений, поведения системы в рамках нештатных ситуаций и т.п., потому что естественным образом IBMовский софт и аналоги обеспечивают немного разные гарантии для разных ситуаций и самое интересное в редизайне архитектуры приложения - как с этими несоответствиями поступили авторы. Точнее есть только про PostgreSQL и то что отказались от двухфазных транзакций, что намекает что консистентность данных стала в итоге хуже, но этому уделено слишком мало внимания.
p.s. собственно автор сказал что x86 лучше в рамках ответов на вопросы ("если взять современный процессор, то там 16 ядер на борту и 3 ГГц, естественно чудес не бывает"), то есть получится что цифрами не подтверждается, а мнением докладчика - опровергается.
belonesox
07.09.2021 15:21+1Все так. Ну тогда было время такое, «мода на импортозамещение», что даже вот этот доклад пришлось сильно заманивать выступить, и мягко дорабатывать. Ну и даже затащить стек ява+постгрес, и чтобы на этом что-то шевелилось (проблемы с нативными хешами на яве, спинлоки в пг) — было как бы ну если не подвиг, то саксесс-стори.
Теперь же, если мне в на ревью попадутся рассказы о реализованных на Э. инфосистемах, то, конечно, буду требовать раскрытия этих вопросов.
mikhanoid
06.09.2021 18:23На НСКФ (год не помню) показывали цифровой тактический командный пункт на Эльбрусах. Такой грузовик, в который собирается информация со всего поля боя.
Hlad
07.09.2021 14:29+2Я по секрету скажу, что их намного больше. Есть довольно много российских контор, которые занимаются разработками специализированных микроконтроллеров под заказ, и при этом стараются не отсвечивать на официальном уровне.
mentin
06.09.2021 10:09+2А для Эльбруса нет profile guided optimization? Это могло бы частично исправить беды статической оптимизации. Кончено, ценой заметного усложнения процесса разработки, но кому нужна производительность осилили бы.
a1batross
06.09.2021 10:10+2Есть.
mentin
06.09.2021 10:27Если он ещё и работает :), то часть жалоб эту статьи не в тему. По крайней мере ассемблер стоило попробовать получить с PGO.
Armmaster Автор
06.09.2021 12:04+3Это каким образом, если никакой возможности получить код и запустить его на Эльбрусе у меня нет?
Что касается PGO - так только на это и расчёт, профиль сильно помогает Эльбрусу. Но во-первых, цифры Spec CPU 2006/2017 Алексей наверняка привёл с профилем (он же не написал точно, но зная, как в МЦСТ всё меряют, подозреваю, что это именно так). А во-вторых, в реальных проектах почти никто с профилем не собирает. Это большая дополнительная нагрузка по сбору профиля и перекомпиляции, и поддержке всего этого хозяйства. Да и часто профиль мало помогает, но это уже тема для отдельных статей.
vibornoff
06.09.2021 13:19Интереса ради, не могли бы вы пересобрать код с pgo? Всё-таки она в мейнстрим хоть и медленно, но входит.
UPD. Пардон, вопрос конечно же адресуется @alexanius
mikhanoid
06.09.2021 18:25Это вы загнули. В реальных проектах очень много кто собирает с профилем даже для x86. Когда нужна производительность, затраты окупаются.
Civil
07.09.2021 10:44В реальных проектах очень много кто собирает с профилем даже для x86.
Есть статистика, показывающая процент таких проектов?
a1batross
07.09.2021 15:33Не статистика, но как-то я из интереса разбирал код одной ААА игрушки. Под консоли, в которых всё-таки x86, там собирали с заранее собранным из плейтестов профилем.
Это не статистика, но меня очень порадовало, что люди все-таки пользуются PGO, пытаясь выжать из устаревшей железки всё что возможно.
belonesox
07.09.2021 15:41Есть, но с некоторыми тонкостями. Недавно был доклад альтов → http://0x1.tv/20210617J
Coocos
06.09.2021 10:10-6Статья хорошо читается для непосвященных, но не объясняет почему у Эльбруса нет перспектив. Не понятно откуда автор взял предельную частоту в 2.5-3.0 ГГц. Каким образом VLIW препятствует наращиванию частоты? Возможность работы Интела на 5ГГц - это прежде всего многолетний опыт и деньги, а не формат команд.
Приведенные в начале статьи проблемы - это текущие проблемы, которые решаются.
На счет сложностей с динамическими языками согласен, тут проявляются преимущества OoO.
P.S. До выхода Apple M1 на форумах многие "кричали" что ARM не может быть высокопроизводительным, но M1 на 3.2 ГГц превзошел x86 на 4.5ГГц.
Tarakanator
06.09.2021 11:36-2я конечно не эксперт, но:
1)архитектура влияет на частоты. Я уже не помню конкретные примеры, но разные процессоры на одном техпроцессе показывают разные частоты. И дело не в напряжении\ТДП. Даже статью про это читал но почему так уже не помню.
2)
а)не видел выкриков о том, что ARM не может быть высокопроизводительным. Видел сообщения о том, что хз можно ли ARM сделать высокопроизводительным. Типа "вот здесь есть проблемы, решаемые или нет-хз.
б)М1 превзошёл x86 на 4.5ггц (не утверждаю, но и не возражаю) Вот только превзошёл не ARM а узкоспециализированные ускорители вычислений в M1. С точки зрения энергоэффективности решение огонь. А вот с производительностью.... возникают провалы в задачах которые не ускорены. Для ноутбука провалы не столь катастрофичны. А вот сможет ли такой подход сработать в hi-end PC-смотри п 2а
demon416nds
06.09.2021 12:06Тут вся проблема в скорости света,
Слишком маленькая она, поэтому чем короче синхронные участки процессора тем большей частоты можно достигнуть, накой нибудь 4004 выполненный по новейшему техпроцессу и на 11 ГГц будет работать.
Зы у vliw в этом плане особых недостатков нет если не намудрили с конвейерами
amartology
06.09.2021 12:11+1Причем тут скорость света? Она влияет радикально меньше, чем емкости затворов и RLC соединительных линий. Мы же электрические сигналы между вентилями гоняем, а не свет.
Pyhesty
07.09.2021 00:08-3влияет, скорость света - это предел распространения эм волны, для меди 23см на 1нс, для 10Ггц на размере чипа 10мм сигнал инвертируется, синхронность развалится, для примера на ПЛИС постоянная проблема протащить сигнал через кристалл
amartology
07.09.2021 09:14+1Повторяю: скорость света не влияет, в реальности у меди есть RLC, а у затворов транзисторов — ёмкость. И в реальности сигналы разваливаются по совершенно другим причинам и намного раньше.
Ваше заявление звучит примерно как «скорость света ограничивает предельную скорость современных пассажирских самолётов». Вообще да, но на самом деле — нет.Pyhesty
07.09.2021 10:07вы путаете теплое с мягким (макро с самолётами и микро мир с электронами), если вам нужно передать сигнал через весь кристалл размером 10-20мм при частоте 10Ггц (реальная нормальная частота), и при этом обеспечить синхронность выполнения, вы вынуждены будете вставлять промежуточные регистры, так как только задержка распространения составит сотню пикосекунд. Это без учёта емкостей, которые так же есть в схеме.
Скорость света фундаментальный фактор ограничения производительности синхронных схем в общем и процессоров в частности.
ps: скажу банальную истину, что скорость света в принципе фундаментальная постоянная одна из шести и считать, что она не влияет по меньшей мере наивно.
amartology
07.09.2021 10:43+2Это вы путаете теплое с мягким. Подходящую аналогию я вам привел.
если вам нужно передать сигнал через весь кристалл размером 10-20мм при частоте 10Ггц
То вам стоит попробовать посчитать длинную линию, которая получается, и понять, что скорость света ни при чем, а промежуточные регистры нужны для того, чтобы не драйвить RLC, а не потому, что скорость света что-то ограничивает.Скорость света фундаментальный фактор ограничения производительности синхронных схем в общем и процессоров в частности.
Да конечно. Только современные процессоры от этого ограничения очень и очень далеко, поэтому никакого практического влияния оно не оказывает.Pyhesty
07.09.2021 11:22давайте посчитаем длинную линию:
скорость света в меди 2.3*10^8м/с или 2.3*10^11мм/с, что даёт поворот фазы на 180 градусов уже на около 10мм расстояния, если вы попробуете сделать push eax, а потом pop eax на процессоре, а кэш у вас отнесен на 5мм, то вероятно биты придут уже перепутанные и вы должны будете поставить условный nop, что бы дождаться, пока сигнал дойдёт до кэша и вернётся обратно
вот что сказал Мур в одном из своих интервью
"I remember we had Stephen Hawking, the famous cosmologist, in Silicon Valley one time. He gave a talk, and afterward he was asked what he saw as the limits to the integrated circuit technology.
Now this is not his field, but he came up with two things: the finite velocity of light and the atomic nature of materials."
"Помню, однажды в Кремниевой долине у нас был Стивен Хокинг, знаменитый космолог. Он выступил с докладом, а затем его спросили, в чем, по его мнению, есть пределы технологии интегральных схем.
Это не его область, но он предложил две вещи: конечная скорость света и атомарная природа материалов. И я думаю, что он прав. Сейчас мы очень близки к атомному ограничению. Мы используем всю возможную скорость, но скорость света ограничивает производительность. Это основы, и я не понимаю, как мы когда-нибудь сможем их обойти. И в следующей паре поколений мы будем прямо против них."
https://spectrum.ieee.org/gordon-moore-the-man-whose-name-means-progress
amartology
07.09.2021 12:10+7а кэш у вас отнесен на 5мм
то удельное сопротивление меди 0,01707 Ом·мм²/м, то есть линия длиной 5 мм, толщиной 10 нм и шириной 50 нм будет иметь сопротивление порядка 2 кОм и паразитную емкость под пикофараду, что даст нам даже на модели RC-цепи с локализованными параметрами задержку в 2 нс, а в реальности еще больше, и это при условии, что у вас выход логического вентиля вообще сможет драйвить такого монстра (а он не сможет).
Так что я не понимаю, о каких вообще 10 ГГц вы говорите, если вы в такой ситуации и 200 МГц не сможете в кремнии иметь.amartology
07.09.2021 17:50+5Причем тут ёмкости затворов? Они действительно единицы фемтофарад. А вот порядок величины паразитной ёмкости длинной металлической линии на соседние металлы и на подложку я назвал верно. Я с ними на работе каждодневно дело имею.
Coocos
06.09.2021 12:26+5В каких задачах возникают провалы? Только если векторизованный код с AVX512.
Какие, например, узкоспециализированные ускорители вычислений в M1? И как они влияют на высокую скорость работы JDK, 7zip, Safari и прочих приложений?
Tarakanator
08.09.2021 11:29возможно мне стоило выразиться мягче, не как провал, а как производительность ниже ожидаемой по заявлениям на презентации.
Я обзор смотрел по выходу m1, результаты запомнил, конкретные тесты\блоки нет. Мне техника apple неинтересна. ЕМНИП там было ускорение редактирования видео.Civil
08.09.2021 11:46возможно мне стоило выразиться мягче, не как провал, а как производительность ниже ожидаемой по заявлениям на презентации.
Да в общем-то нет, как заявляли что будет холоднее и быстрее - так примерно и вышло.
Я обзор смотрел по выходу m1, результаты запомнил, конкретные тесты\блоки нет. Мне техника apple неинтересна. ЕМНИП там было ускорение редактирования видео.
Вот не только в редактировании было. По факту прирост был везде. Естественно в плане видеокодирования - аппаратные блоки сыграли свою роль, но вот прирост в скорости работы браузера - чисто за счет микроархитектуры. Также и в других задачах, типа компиляции и даже, как ни странно, в обработке фото (фотшопы, лайтрумы и прочие capture one на M1 везде где не задействован GPU работают быстрее чем старые Macbook Pro 16" на Intel'ах, но вот где GPU-интенсивные задачи, там они проседают).
Собственно гипотеза "да это все из-за ускорителей" была в начале, пока была доступна только официальная презентация (в ней упор был на видеоредакторе сделан), но этот миф развенчали как только у людей устройства появились на руках.
Civil
06.09.2021 16:44+1Вот только превзошёл не ARM а узкоспециализированные ускорители вычислений в M1
Это миф кстати. Специализированных ускорителей там не так много и их наличие не объясняет почему он быстрее, например, в компиляции софта.
speshuric
06.09.2021 18:43Память распаяна на плате и быстрая. С одной стороны - не апгрейднешь через пару лет. С другой стороны - купишь новый ноут. С третьей - получилось показать огромную производительность.
Civil
06.09.2021 19:21+1Распаянная память свойство многих ноутбуков и на скорость это не так чтобы сильно влияет на производительность. Apple ее вообще на ту же подложку что и чип разместила, но не очень понятно как это влияет на производительность (тайминги памяти не публикуются же, а частоты вполне обыденные для LPDDR4X, ничего особенного в них нет). Плюс память - не является акселератором как таковая.
gudvinr
06.09.2021 10:22-7И везде видно, что VLIW решения всегда своим конкурентам уступают по частоте.
Ну такое себе. Вы вспомните ещё "перфоманс рейтинг", которые для атлонов вводили, когда у них частоты были меньше, чем у пентиумов.
Civil
06.09.2021 10:45+8Ну такое себе.
В статье же отдельно разобран про IPC и про мегагерцы.
Тут и IPC хуже получается (в среднем) и частоты ниже - то есть не взять ни тем, ни другим.
gudvinr
06.09.2021 11:26-1IPC хуже получается
На конкретном примере в конкретной версии компилятора. Но всё же надо понимать, что в случае с x86 — это фактически потолок, обусловленный железом, а для e2k — это вопрос оптимизации на стороне компилятора.
Само собой, другие проблемы от этого не уходят. Закрытая архитектура, закрытый компилятор и сложности с доступом к оборудованию явно никак не помогают развитию.Автор делает довольно большой акцент в сравнении на частоту, хотя сам же говорит, что частота определяется архитектурой. И не упоминает, например, что x86 не будет работать на 5ГГц, если его загрузить операциями AVX-512.
Ну достигают и достигают, а дальше что? Graviton, если не ошибаюсь, максимальную частоту имеет те же 2.5-3ГГц и при меньшем TDP.IPC — это тоже довольно размытая метрика. Инструкции разные бывают. Операции над целыми числами и над числами с плавающей точкой могут разными блоками выполняться и одних за такт может выполниться больше, чем других. А есть ещё SIMD и прочие интересные вещи.
Я не говорю, что автор не прав, но такое ощущение, что он почему-то на МЦСТ зуб точит и точно так же срезает углы в удобном ключе, оставляя полуправду, как это делал автор предыдущей статьи. Только наоборот.
Civil
06.09.2021 13:23+8На конкретном примере в конкретной версии компилятора. Но всё же надо понимать, что в случае с x86 — это фактически потолок, обусловленный железом, а для e2k — это вопрос оптимизации на стороне компилятора.
Теоретически? Да, конечно, компилятор повлияет. Практически? Компилятор делают около 20 лет (если не больше), результат до сих пор плачевный.
Автор делает довольно большой акцент в сравнении на частоту, хотя сам же говорит, что частота определяется архитектурой. И не упоминает, например, что x86 не будет работать на 5ГГц, если его загрузить операциями AVX-512.
Потому что на самом деле будет, но и время и частота зависят от модели цпу и длительности нагрузки. Современные десктопные CPU при нагрузке не более чем на 4 ядра совсем не сбрасывают частоты под avx-512, а при полной нагрузке сбрасывают до 4.8 ГГц. То есть ограничение связано в первую очередь с удержанием процессора в пределах заявленного TDP. К тому же в примере автор исключал векторизацию специально.
IPC — это тоже довольно размытая метрика. Инструкции разные бывают. Операции над целыми числами и над числами с плавающей точкой могут разными блоками выполняться и одних за такт может выполниться больше, чем других. А есть ещё SIMD и прочие интересные вещи.
Так посмотрите еще раз что привел автор. Он привел и количество тактов на итерацию (эта величина не зависит от частоты) и количество инструкций за такт (как мерило эффективности). По сути автор показал что:
Цикл выполняется дольше (в тактах)
Количество инструкций больше
Темп выполнения инструкций ниже
Тактовая частота ниже
Да, это не общий случай (то есть будут задачи где у Эльбруса будет высокий IPC), но это обычный ничем не примечательный цикл, подобные которому будут встречаться повсеместно в реальной жизни.
срезает углы в удобном ключе, оставляя полуправду
Автор скорее срезает углы в местах где объяснение простой вещи потянет на двухчасовую лекцию (например про частоты для VLIWов), что не совсем хорошо если честно, но я не знаю как иначе кроме как оставлять эти вещи на откуп читателям.
Galperin_Mark
06.09.2021 10:59+6Хотелось бы, чтобы Эльбрус вышел на коммерческий рынок. Только на госзаказах не выжить.
goldrobot
07.09.2021 14:11+2Тоесть и комерсов с обычными гражданами вы хотите обязать импортозаместить?
Galperin_Mark
07.09.2021 17:52+1Хочу, чтобы Эльбрус продавался в интернет-магазинах. Именно продавался, а не выставлялся в виде прайс-листа. Причем продавался не только в России, но и за рубежом. Тогда будет ясна истинная ценность продукта.
Pyhesty
06.09.2021 11:11+1с учётом того, что производительность современных процессоров уже упёрлась в потолок и замещается многоядерностью, то будут выигрывать архитектуры, мне так видится, что ARM уже догоняет x86, другие архитектуры подтягиваются и интересно, как всё будет выглядеть в пределе...
можно ли уже спрогнозировать этот предел производительности одного ядра для каждой архитектуры? (графики там может какие есть?)
siziyman
06.09.2021 16:27+2В какой потолок упёрлась? Каждое поколение пользовательских процов всё ещё наращивает производительность отдельно взятого ядра в том числе.
Pyhesty
06.09.2021 17:25незначительно, я связан с задачами ориентированными на однопроцессорные вычисления, в частности трассировка ПЛИС, так вот с 2010 года скорость трассировки зависит только от частоты ядра, на текущий момент частота ядра уперлась где-то в 5ГГц и соответственно проекты как комплились 60 минут в 2012 году, так и компилятся чуть быстрее скажем около 40минут. Рост в моих задачах составил менее 2х раз, хотя количество ядер возросло это да... И да для конкретно задач у нас производительность семейств для i3, i5, i7 и i9 пропорционально только скорости одного ядра, а частота работы все же ограничена... это я к чему? есть шанс у конкурентов ARM, A1 и остальных догнать по производительности x86 архитектуру и частично её заместить её, а та архитектура, что будет изначально более производительная при одних и тех же технологиях может чуть вырваться вперед...
cepera_ang
06.09.2021 18:14Специализированные задачи становится всё больше смысла выносить отдельно. Если лет 10-15 назад не было смысла делать отдельную железку — пока будешь проектировать и изготавливать, процы сделают 2-10х и опять обгонят, то в наше время это в лучшем случае 1.2х за пару лет. Поэтому и цветёт ускорение конкретных задач в железе — в проце узкие места за счёт универсальности и упирается всё в основном в память, да предсказание ветвлений. Глядишь скоро и для трассировки ПЛИС будут специальные ПЛИС :)
Pyhesty
06.09.2021 18:26я совершенно не могу понять, почему трассировку ПЛИС не вынесли на GPU, это должно было на порядок сократить время на перекомпиляцию... но, к сожалению, Quartus (тот же intel, какая ирония...) компилит все только на одном ядре проца игнорируя GPU...
cepera_ang
06.09.2021 18:29Ничего не знаю об алгоритмах трассировки, но если это в теории можно положить на ГПУ, то на все ядра должно паралеллиться гораздо проще.
JerleShannara
06.09.2021 21:56Эммм, не знаю как у вас, но у меня quartus_fit и прочие спокойно жрут все доступные ядра, на одном ядре долгое время висело всё, что было через Qsys/Platform Designer, но и оно нынче научилось отъедать всё доступное.
Brak0del
08.09.2021 10:20+1GPU не спасут, потому что значительная часть вещей в этих алгоритмах параллелится либо плохо, либо никак.
Bromles
06.09.2021 18:11Можно поподробнее, кто там куда уперся? Вон у AMD их Zen 3 в конце 2020 года увеличил IPC в среднем на 19% по сравнению с Zen 2 июля 2019. При сохранении TDP, техпроцесса и прочего. Разница в частоте тоже в пределах 0.1-0.2ггц
cepera_ang
06.09.2021 18:21+3Да это и есть "упёрся", по сравнению с тем, что было 20 лет назад. Ну да, может ещё по десять процентов за двадцать лет нацарапаем ускорение в 3-5 раз ценой увеличения сложности в космос космический — транзисторы в атомах, кеши гигабайтами, ОоО на пол-программы, предсказатели ветвления на нейронках (которые ещё и обучать под нагрузку станут) и т.д.
Это всё отлично и желанно, но не идёт ни в какое сравнение с тем, когда компьютеры ускорялись в миллион раз за те же 20 лет — вот этого нам в процессорах общего назначения точно не увидеть больше.
Pyhesty
06.09.2021 18:24я как и любой другой могу только рассуждать исходя из своего видения, в частности для наших задач применим только Intel, потому что AMD при тех же задачах проигрывает от 20% и более. Задача - компиляция под ПЛИС, которая занимает очень много времени - часы. К сожалению, она не занимает все ядра, а только одно ядро. Последние тесты по части выбора процессора мы проводили в 2020 году, AMD проигрывало и значительно, если в это году Zen 3 будет лучше, то это отлично. В наших очень специфических задачах мы видим, что зависимость только от частоты ядра и производителя (архитектуры).
опять же предположу, что есть взаимное влияние тестов на направление оптимизации процессоров, в частности процы профилируют, что бы они получали большее количество попугаев на этих самых тестах, что не меняет производительность на прикладных задачах.
Brak0del
08.09.2021 10:26+1В наших очень специфических задачах мы видим, что зависимость только от частоты ядра и производителя (архитектуры).
Если что, ещё увеличение размера кэша процессора и наличие SSD немножко помогает по части ускорения сборки проектов для ПЛИС.
jakushev
06.09.2021 11:28+5Максим, спасибо за статью. Но у меня остался один вопрос. Как то так получилось, что буквально месяц назад, в одну бессонную ночь, ко мне пришли флешбеки из конца 90х - начала 2000х. Как раз у университете учился. И тогда на "широкую команду" чуть ли не молились, предрекая ей светлое будущие. Которое не наступило. И вот в разговоре самого с собой, решил проанализировать ситуацию. Пришел к выводу, что VLIW, помимо расхода памяти, что критично но не фатально, просто не может в нормальную JIT компиляцию, на которой базируется почти вся современная инфраструктура прикладного программирования. Но вот чего не могу понять, так это ограничений на максимальную тактовою частоту. Упрощенно, VLIW процессор - это набор относительно простых IP ядер на стероидах. Ни модуля предсказаний, ни сложного дешифратора команд там нет. По сути, сама команда описывает что то вроде "подключи вход А АЛУ1 к Р1, вход Б к Р2, выход к Р3 и выполни операцию сложения". Конечно, не все так просто, но в целом - смысл такой, или я не прав? Вот что ограничивает частоту? У меня только одна мысль - сложность или невозможность реализации относительно длинного и эффективного конвейера + жесткая связь с компилятором для его эффективной утилизации. Просто интересно мнение специалиста.
amartology
06.09.2021 11:58+6сложность или невозможность реализации относительно длинного и эффективного конвейера
Это правильная мысль. Если начинать делать конвейер глубже, то паковать команды в пачки станет сложнее, и производительность упадет. А с неглубоким конвейером нельзя наращивать частоту.jakushev
06.09.2021 12:44+2Спасибо за уточнение. Да, часто так бывает, что на бумаге все гладко, а мелкие нюансы портят всю картину. Прискорбно, что столько усилий, можно сказать, пропадают зря, но не могу с Вами не согласиться. Порой дешевле и разумней вовремя "закопать стюардессу". Возможно, даже не закапывать, а, снова же, на мой взгляд, немного упрощенный VLIW неплохо бы чувствовал себя в специализированных системах жесткого реального времени. Где важна не супер производительность, а детерминированное время исполнения инструкций. И да, а что там с асинхронными прерываниями? Как процессор "узнает", когда разорвать команды и перейти в обработчик? Прошу прощения за терминологию, не процессоростроитель, но если RISC/CISK, пусть внутри и разгребает поступающие команды на микро операции, он "знает", что вот этот "mov" пришел последним, далее как разработчик микроархитектуры решит, флашить конвертер и выполнять прерывание или отработать то, что есть, параллельно загружая код обработчика в кэш, то как понимаю, в VLIW, допустим, условный "LD" может начаться, а завершиться через 50 - 100 тактов, и где рвать выполнение программы - неизвестно...
Paskin
06.09.2021 15:16VLIW действительно хорошо себя чувствует в задачах ввода и обработки данных - допустим, преобразования того, что передает сенсор камеры - в привычное нам изображение. Но это в устоявшемся режиме - после каждого запуска вычислений ему нужно "разогнаться". И, разумеется - никаких прерываний, переключения контекстов и так далее.
jakushev
06.09.2021 13:11+11000 извинений, был крайне не внимателен и перепутал Вас с автором поста... Не судите строго. Просто в предыдущих публикациях от Вас было тоже много дельных комментариев, и при первом взгляде на ник, как то вырвалось "arm", но это уже моя профдеформация...
Armmaster Автор
06.09.2021 12:57+2В вопросах частоты, я, к сожалению не эксперт (моя область компетенции это компиляторы, архитектуры и микроархитектуры). Из того, что я вынес из общения с экспертами - проблема в более коротком размере конвейера, его ширины и необходимости уметь быстро передавать через байпасы значения в большое количество портов и для большого количества регистров. Из-за этого в Эльбрусе, например, есть 2 кластера внутри одной ШК, между алу которых нет байпасов.
jakushev
06.09.2021 13:07Спасибо за ответ и 1000 извинений, понимаю, что не булькают, перепутал ответ пользователя "amartology" с Вашим. И предыдущий комментарий был адресован Вам. Максим, Валерий, извините, впредь буду внимателен и не идентифицировать пользователя по первой букве ника...
edo1h
06.09.2021 22:02+1offtopic: помнится, в детстве я не любил, если у двух героев в произведении имя начиналось на одну букву. особенно неприятно было если заметил это не сразу и приходилось возвращаться назад чтобы разрешить путаницу )))
amartology
06.09.2021 23:18+1Покажись
Verstecken verzichten
Verbrennen und vernichten
Verhütung verboten
Verstreuen sie Gebote
Verfolgung verkünden
Vergebung der Sünden
Verbreiten, sich vermehren
Im Namen des Herren
a1batross
06.09.2021 12:20+1Кстати со сложностью ассемблера не соглашусь. Он необычный, кого-то можно даже удивить им, но можно ли сравнить его с ассемблером x86 и сказать что он заметно сложнее? По-моему опыту с ними двумя как-то нет. Сложно для этого писать компилятор, конечно. А куда без компиляторов денешься...
Armmaster Автор
06.09.2021 13:16+7Я знаю ассемблер e2k и x86 примерно на одинаковом уровне. Так вот, чтобы найти код горячего цикла в приведённом в статье примере мне пришлось потратить минут 10. А для x86 где-то 10 секунд. Тут можно в теории устроить такого рода эксперимент более массово. Но давайте объективно, мне кажется результат предсказуем.
a1batross
06.09.2021 21:02+1Не знаю, мне в целом одинаково, что тут, что там.
После эмулятора меня это не пугает конечно. Особенно запуская те части, от которых исходного кода нет.
sparhawk
06.09.2021 12:30-2В примере результата компиляции под e2k широких команд 6 (широкие команды выполняются за такт, в ассемблере они в фигурных скобках, согласно мануалу), а не 13. Отсюда, неверный вывод, что это займет 13 тактов (должно быть 6).
Хотя у x86 получается всего 8 операций, скорее всего он выполнит их быстрее, чем за 8 тактов. Так что примерно паритет, Эльбрус чуть проиграет из-за более низкой частоты.
Но эти числа (6 и 8) слишком маленькие, чтобы делать какой-то далеко идущий статистический вывод. Хотелось пример хотя бы немного сложнее.
Да и в целом в статье много сумбура и манипуляций
Armmaster Автор
06.09.2021 12:48+14Нет, 13. Вы не учли операции nop, которые приводит к исполнению процессором пустых тактов. Посмотрите внимательно на ассемблер приведённых ШК
sparhawk
06.09.2021 13:29+1Да, вы правы, спасибо за подсказку. Действительно nop-ы добавляют 7 тактов. Судя по всему, они используются для какой-то синхронизации load-store.Тема nop-ов для синхронизации в e2k мало где прояснена, и требуется дополнительный анализ, насколько это влияет.
Впрочем, в других примерах https://ce.mentality.rip/ выдает меньше задержек nop-ами, например, для процедуры Sort 28 задержек nop на 36 широких команд (против 7 на 6). Так что по-прежнему кажется, что стоит проанализировать код посложнее, прежде чем сделать выводы
Armmaster Автор
06.09.2021 15:25+2Цифры Spec'ов и других бенчмарков, как мне кажется, достаточно красноречиво показывают, что происходит на "коде посложней"
beeruser
06.09.2021 18:45+4Отсюда, неверный вывод, что это займет 13 тактов (должно быть 6).
Кому должно?
Даже как-то забавно, как несколько человек, которые в первый раз увидели E2K асм (а может и вообще), начинают «учить» эксперта, который с ним как бы годы проработал :)Судя по всему, они используются для какой-то синхронизации load-store.
Не знаю как у Эльбруса, а у VLIW процессоров в целом не любят делать интерлоки, поэтому нопы нужны для корректности выполнения. Таким образом задача отслеживания конфликтов в конвейере перекладывается на компилятор.
ECE 4750 Computer Architecture; Topic 13: VLIW Processors
стр.5Constant operation latencies are specified
• Architecture requires guarantee of:
– Parallelism within an instruction => no cross-operation RAW check
– No data use before data ready => no data interlocks
Armmaster Автор
06.09.2021 13:17+1Я смотрю, вы дописали комментарий. В x86 эти 8 операций исполнятся за 3 такта. В статье же всё подробно разобрано
CTDEVIce
06.09.2021 12:48+7Я думаю, что ладно бы с ней с производительностью - вы сделайте платформу доступной любому желающему, а энтузиасты найдутся и портируют что надо и напишут новое и оптимизируют. Проблема Эльбруса - проблема его доступности.
GHouL512
06.09.2021 12:48+1А кто-то занимается в отечестве RISC-V? Просто как по мне открытая архитектура даёт массу возможностей пользоваться чужим опытом. Что как по мне позволяет экономить на человеческих ресурсах у нас ведь не так много специалистов чтобы тянуть архитектуру процессора с нуля а вместе с ней и софтверную часть.
Armmaster Автор
06.09.2021 13:00+2Абсолютно верная мысль. В России я знаю 2 компании, разрабатывающих Risc-v ядра - это Syntacore и CloudBear. Я упоминал про них в своей статье про пути развития отечественных процессоров
amartology
06.09.2021 17:00+3Ядра делают две упомянутые выше компании, а продуктами на их основе уже занимаются такие гранды, как «Микрон», «Миландр» и НИИМА «Прогресс». Плюс Yadro, которое начало делать на основе разработок Синтакора процессор общего назначения.
r9wep
06.09.2021 12:49-3Есть мировой рекорд "максимальная частота компьютерного процессора", который, вроде как, все еще принадлежит AMD FX 8,429 ГГц. Ну и кто скажет,что данный процессор производительней современных?
Armmaster Автор
06.09.2021 13:01+3Половина данной статьи посвящена как раз описанию того, насколько Эльбрус проигрывает по микроархитектурной скорости и почему
siziyman
06.09.2021 16:32Кажется, людей немного коробит форма подачи: тон/текст создают впечатление, как будто вы подразуемеваете связь "раз частота ниже, значит, процессор медленнее" (что, как вы сами понимаете, не является правдой само по себе без каких-то оговорок и уточнения). Если бы была пара предложений в духе "производительность процессора складывается из частоты и instructions per cycle, давайте посмотрим, почему там и там всё плохо у Эльбруса" (максимально утрированно), восприятие было бы лучше.
flx0
06.09.2021 17:13+6А вы точно читали статью? Там это не просто написано, а несколько раз специально выделено.
Тут как минимум половина комментариев в защиту Эльбруса тупо повторяет критику, на которую автор уже ответил в статье, как по шаблону. Такое ощущение что кроме заголовка ничего не читали.
as_victor03
06.09.2021 12:49+5Создается впечатление что мы наблюдаем баталию производителей отечественных процессоров за гранты и субсидии на полях хабра. Заголовок первой статьи «Процессор Эльбрус — почему это тупик для развития отечественной линейки general-purpose CPU» не мог не вызвать отрицательной реакции у разработчиков Эльбруса. Переход на личности стал неизбежен. Печально то, что пользы дискуссий в подобном тоне не приведут к появлению достойного процессора. Да и место выбрано неподходящее. Наша электронная промышленность находится на низком уровне, это точно. Разрабатывать процессоры в таких условиях непросто. И вместо поливания грязью друг друга было бы неплохо организовать что-то что подталкивало бы к творчеству. Грустно все это.
SerjV
06.09.2021 14:25А разве это не так? Причём борьба не только за гранты и субсидии, но и за административный ресурс для устранения конкурентов хотя бы с доли рынка.
Как говорится, с автоматом и любым процессором - можно продать больше, чем просто с хорошим или даже отличным процессором.
as_victor03
06.09.2021 15:25Вот я и говорю, грустно…
SerjV
06.09.2021 16:33-1Конечно грустно... А может еще ж и скандально стать, поскольку без официально спиратченного софта (это каперство такое, что-ли?) на нём нативно собранные приложения не работают.
Но это проблема потенциально решаемая (говорят, что дело в закрытости системы команд - если "хозяина" убедить, то проблему решить можно), а вот архитектурные особенности уже без "автоматчиков за спиной у покупателей" труднее объехать.
amartology
06.09.2021 17:10+4И вместо поливания грязью друг друга было бы неплохо организовать что-то что подталкивало бы к творчеству.
С одной стороны, людей много, а денег мало, и грызня неизбежна. С другой стороны, уже через месяц будет конференция «Микроэлектроника», на которой соберутся практически все российские разработчики процессоров.Обзорное заседание № 2
«Проблемные вопросы и актуальные задачи создания перспективных
отечественных вычислительных комплексов и ЭКБ для их реализации»
Модераторы:
Горбунов Максим Сергеевич (НИЯУ МИФИ)
Хренов Григорий Юрьевич (АО «Байкал Электроникс»)
Докладчики:
1. Хренов Григорий Юрьевич (АО «Байкал Электроникс»)
2. Бычков Игнат Николаевич (АО «МЦСТ»)
3. Аряшев Сергей Иванович (ФГУ ФНЦ НИИСИ РАН)
4. Редькин Александр Николаевич (ООО «Синтакор»)
5. Мякочин Юрий Олегович (АО ПКК «Миландр»)
Эксперты:
Мохнаткин Алексей Эдуардович (АО НТЦ «Модуль»)
Осипенко Павел Николаевич (ООО «ИВА ТЕХНОЛОДЖИС»)
Семилетов Антон Дмитриевич (АО НПЦ «ЭЛВИС»)
Козлов Александр Владимирович (ООО «КЛАУДБЕАР»)
Формат научной/индустриальной конференции гораздо больше способствует продотворной работе, чем формат срача в интернете.bipiem
07.09.2021 11:04+1К сожалению, это тоже ничего не изменит.
Тут уже говорилось, что главное не в "крутой" архитектуре. Выигрывают простота, массовость (дешевизна), доступность - открытость, масштабируемость (в т.ч. отсутствие технологического тупика) и т.п. "Простой" Ethernet обошел намного продвинутые сетевые технологии, включая ATM, IBM совместимость и х86 похоронили куда более совершенные технологии. Не "крутизна", а оптимальность технологии - главное (оптимальность по указанным критериям, включая цену).
Но и оптимальность технологии - тоже вторично. Важнее не научная конференция, а "государева воля", т.е. реальная, а не провозглашаемая (показушная) промышленная политика государства. Текущая власть этого (развития) не хочет \ не может. Было много провальных проектов "народный телевизор", "народный автомобиль" и т.п. Народный (отечественный) микропроцессор \ компьютер - это реальность (это далеко не технологическая проблема), но не с текущими правителями. Вопрос технологий вторичен, поэтому "сушите весла". Наивно думать, что какая-то конференция изменит политику, ведущуюся на протяжении 30-ти лет.
Да, по обсуждать на хабре VLIW vs RISC - интересно, но нужно понимать, что текущая политическая система не совместима с научно-техническим прогрессом (НТП), включая микроэлектронику. Это правительство максимум на что способно - подобные проекты "завалить деньгами", что периодически и делает, только это не помогает. Хотелось бы оценить, сколько денег похоронили в Эльбрус, насколько понимаю - "денег не жалели" (считать нужно и все субподряды, особенно НИОКР, где головняки - военные институты).
В НТП первичны не технологии и деньги (в стране любые бюджеты легко и быстро разворовываются), а грамотная политика, включая контроль и ответственность чиновников. Утвержденная правительственная программа, кажется 2015 года, включала к 2020-му какое-то безумное количество внедрённых Эльбрусов. Где они? Только на бумаге остались.
count_enable
06.09.2021 12:49+5Независимо от теоретических недостатков\преимуществ VLIW для процессоров общего назначения, "Эльбрус" был бы значительно успешней если бы разработчик открыл бы архитектуру и обеспечил бы программистов полноценными инструментами разработки и качественной документацией.
bagamut
06.09.2021 13:15-3Это все есть. Еще и консультации живых экспертов обеспечиваются.
count_enable
06.09.2021 15:02+13Сейчас заглянул на сайт производителя (очень винтажный), там документацию найти невозможно. Почему я могу за секунду найти исчерпывающую информацию по системе команд и устройству x86, ARM, MIPS, RISC-V, SPARC и прочим без ухищрений?
Спасибо "Яндексу", нашел статью от 2020 года, где рассказали что МЦСТ открыл доки. Там же была ссылка на
Руководство по эффективному программированию на платформе «Эльбрус»". В разделе "Статьи". И это всё? Для самого завалящего китайского процессора есть десятки даташитов, мануалов, Application Note, Whitepaper, SDK и примеры в репозиториях. Даже неловко как-то. Эльбрус недружелюбен к разработчику и неконкурентоспособен ни производительностью, ни ценой, ни удобством использования. Единственный механизм его продаж это прямое принуждение государственным лобби.symbix
06.09.2021 15:28+4Создаётся впечатление, что МЦСТ существует в каком-то своём ограждённом от внешнего мира пузыре, как будто они не в курсе общепринятых в индустрии практик, и им кажется, что это норм. Как какой-нибудь советский НИИ не был (и не мог быть) в курсе международных стандартов и практик. Что довольно странно, учитывая их тесные связи (хоть и в прошлом) с Sun Microsystems, отраженные даже в их названии.
count_enable
06.09.2021 16:28+1Ну они в принципе и выросли из ведомственного НИИ, с единственным заказчиком в лице государства. Коммерческие контракты в 90х это досадное недоразумение которое они рады забыть побыстрее.
МЦСТ не понимает что качественная и доступная докуменация важнее чем "комментарии живых экспертов". Доки это то что позволяет студенту в Австралии написать свой RISC-V, студентке в Венгрии написать свой компилятор под RISC-V да так, что программа, скомпилированная вторым, запустится на первом без проблем, хотя эти двое никогда не встречались и не консультировались.
Подменять экспертами доки это всё равно что вместо чертежа на производство отправлять гонца, который на словах и на пальцах расскажет как точить вал для турбины.
MadHacker
06.09.2021 14:01+1Подскажите пожалуйста по закрытости архитектуры и вот этому всему. Возможно уже где-то разбиралось…
С точки зрения разработки и производства — архитектура принадлежит кому то в МЦСТ и выпускать эмуляторы, аналогичные по архитектуре процессоры и так далее — незаконно?
С точки зрения разработки системного ПО — ассемблер не предоставляется вообще, предоставляется не полный с ограничениями, ..? Возможно ли создание своего компилятора (технически, юридически) под данную архитектуру?
С точки зрения разработки прикладного ПО — доступность SDK, компиляторов, инструментария, эмуляторов, ...?Armmaster Автор
07.09.2021 14:50+1Архитектура закрыта. Её принадлежность на самом деле вопрос не очень понятный. Но давайте считать, что она принадлежит МЦСТ
В принципе, с точки зрения легальности, нет особых проблем разрабатывать системный софт, включая эмуляторы, компиляторы и т.д. Проблема в том, что в ситуации закрытости архитектуры и отсутсвия необходимой документации - это в действительности нереально. Именно поэтому разработкой системного софта по факту занимается только само МЦСТ (ну плюс тех, кого МЦСТ напрямую под это наняло)
Это объёмный вопрос. Главная проблема тут на мой взгляд - это банальная невозможность просто взять и купить Эльбрус - его нет в свобоной продаже. Понятно что в такой ситуации развивать экосистему прикладного ПО сложно. Какое-то прикладное ПО есть. Компилятор предоставляется МЦСТ. Дебаггеры, перфы и пр. - что-то есть, но я не могу сказать, насколько оно адекватно по функционалу и надёжности. Симуляторов насколько я знаю в открытом доступе нет. Внутри МЦСТ есть свои симуляторы, но они вроде не доступны вовне.
MadHacker
07.09.2021 16:30Закрытость документации (даташиты, наборы команд, ...) это принципиальная позиция МЦСТ или типичная бюрократия из серии «вы нам напишите мы подумаем»?
amartology
07.09.2021 17:52Все разработки МЦСТ оплачивает государство. Это вполне может быть позиция Минпромторга, которому на самом деле принадлежат все права на все, что им оплачено.
Arioch
06.09.2021 14:24+1Простим автору его неинформированность .... Для Arm существуют .... ExaGear
А вот это очень странно. Вы сами-то пробовали поискать, что это за такой ExaGear? У меня все результаты поиска выходят либо на eltechs.com, либо на elbrus-technologies.com
Эльбрус Технологии — это молодой высокотехнологичный стартап по разработке программного обеспечения
Наш проект — это двоичный транслятор, позволяющий запускать приложения для обычных настольных ПК и процессора x86 на энергоэффективных процессорах ARM без каких-либо изменений.
Вы уверены, что ни вы лично, ни @alexanius не знаете разработчиков ExaGear даже и лично? Название, если не попытка выехать на чужом хайпе, как бы символизирует...
Armmaster Автор
06.09.2021 14:51+4Я не очень понял суть претензии. Я являлся CTO компании Эльбрус Технологии и являюсь непосредственным разработчиком и архитектором ExaGear. Вполне очевидно, что я понимаю о чём идёт речь.
Arioch
06.09.2021 15:35+5В статье про это ни слова же, откуда остальные могут знать, что вы знаете (но не говорите) ?
Но тем лучше.
Я правильно понимаю, что название вызвано тем, что ядро ET составили люди, ушедшие из МЦСТ ?Если да, то
такая информация напрямую относится к теме разговора и должна быть упомянута в статье
такая информация должна быть распространена среди "оставшихся в МЦСТ", и в том числе Алексея: это ненормально если в МЦСТ не знают о технологиях/компаниях отпочковавшихся от МЦСТ
Armmaster Автор
06.09.2021 16:19Мне казалось (и сейчас так кажется), что данный вопрос не имеет отношения к теме дискуссии. Иначе у нас тут будут исторические опусы, а не техническое обсуждение.
Что касается:
такая информация должна быть распространена среди "оставшихся в МЦСТ", и в том числе Алексея: это ненормально если в МЦСТ не знают о технологиях/компаниях отпочковавшихся от МЦСТ
Вряд ли эту претензию можно адресовать лично мне. Но тем не менее, в МЦСТ многие люди вполне в курсе об Элтехе, и сдаётся мне, что Алексей тоже.
Arioch
07.09.2021 13:43+2данный вопрос не имеет отношения к теме дискуссии
В идеальном мире - да. И в этом идеальном мире вы бы не проезжались по "неинформированности" вашего оппонента. Оставили бы это целиком за скобками статьи.
Но раз уж вы решили проехаться по нему лично, то IMHO сказав А, говорите и Б.
Или не упоминать вообще, или с конкретикой достаточной, для конкретного обсуждения.>> информация должна быть распространена среди "оставшихся в МЦСТ"
Вряд ли эту претензию можно адресовать лично мне.
Да, к вам другая претензия: что упомянув в статье историю с Э.Т. косвенно, вы не проговорили, чем конкретно Алексей вас "удивил". А конкретно эта - к МЦСТ в целом и Алексею, как его части.
SerjPeleng
06.09.2021 16:21-7все статьи прочитал, но т.к. не являюсь специалистом в микроархитектурах, прокомментировать технические моменты не могу... и кто прав не знаю...
но вот то, что я почерпнул из ваших комментариев, сложилось у меня в какую-то неприятную картинку...
т.е. Вы 10 лет тренировались на кошечках в МЦСТ, делая двоичный транслятор, а потом ушли, унесли с собой кошечек и стали публично топить бывшего работодателя, продвигая "свой" продукт на конкурирующей платформе?
Ничего против Вас не имею, просто сложилось такое вот мнение на основе прочитанного... наверное Вы этого не хотели, когда писали все свои статьи и комментарии..Arioch
07.09.2021 11:51+1Вы 10 лет тренировались на кошечках в МЦСТ, делая двоичный транслятор, а потом ушли, унесли с собой кошечек
А вот тут подробнее, каких именно кошечек они унесли?
Они украли программу-транслятор и продают Хуавею контрафакт? А где тогда суды? Может быть хотя бы по торговой марке "Эльбрус" суды были?
А по умолчанию это: "работал мужик землекопом 20 лет, накачал на руках огромные бицепсы. А потом уволился и пошёл копать ямы в другом месте. И бицепсы свои, сволось, с собой унёс, а должен был работодателю отдать!
P.S. А если оторваться конспироложить, то может быть им этим транслятором, например, долги по з/п выплатили за 10 лет, например. Или сказали им "ваш транлятор - дерьмо, нам такого не надо, мы сделаем другой хороший! ах не надо, тогда мы его сами продвинем!" и разошлись, каждый со своими игрушками. И ещё можно вариантов напридумывать, на любой вкус, в которых никакой "кражи кошечек" не будет.
продвигая "свой" продукт на конкурирующей платформе?
Забавно, что напрямую они не конкурируют. А может быть и вообще, если в ExaGear сохранили/восстановили поддержку e2k, пусть непублично.
Это как если Microsoft или RedHat начнёт откровенно топить Alpha или ARM или SPARC, например, вместо захвата его, как потенциального рынка.
antag
06.09.2021 14:55+5На основе имеющихся результатов Spec CPU 2017 можно, кстати, достаточно хорошо оценить микроархитектурную скорость своременных RISC/CISC процессоров. Она колеблется в среднем в диапазоне 2-3 SpecRate на один гигагерц одного ядра, переваливая за 4 для SpecFP для топовых решений (как для приведенного выше решения на базе AMD EPYC 72F3). Для Эльбруса же эта микроархитектурная скорость равна 0.9 для SpecINT и 1.4 для SpecFP.
Посмотрел результаты Spec CPU 2017 китайского процессора Kunpeng 920.
Для Kunpeng 920 эта "микроархитектурная скорость" получается
0.96 для SpecINT
0.79 для SpecFP.
А значит Эльбрус выигрывает у Kunpeng по этой характеристике для SpecFP.
Про частоту. Kunpeng - 2.6 GHz на техпроцессе 7 нм, а Эльбрус - 2.0 GHz на 16 нм. А на одинаковых 7 нм у них было бы почти равенство по частоте.
Или для другого нового китайского процессора Loongson 3A5000 заявили про 80 в SPEC CPU2006 для всего процессора, что на уровне Эльбрус-8С.
Так все "неамериканские" альтернативные процессоры все еще сильно уступают процессорам AMD и Intel. Но среди этих "альтернативщиков" цифры производительности у Эльбруса не такие провальные. А для FP у Эльбруса вполне приличная производительность на ядро.
Armmaster Автор
06.09.2021 15:09+2Спасибо за интересный комментарий. Давайте на его примере разберём, в чём тут нюансы.
Kunpeng 920 - это процессор, у которого на одном чипе собрано 128 ядер. Чтобы такое сделать, надо иметь очень оптимизированные по TDP ядра, иначе вы не влезете в теплопакет. Для Huawei это лишь второй чип в серии, основанный изначально на Cortex-A57 если мне не изменяет память (т.е. как Байкал-М). Поэтому там просто пожертвовали определёнными вещами в пользу TDP, т.к. не было достаточно времени и опыта всё это вылизывать. В Kunpeng 920 всего лишь 2 FPU юнита, когда как в Эльбрусе их 6. И поэтому современных Эльбрусов поставить на чип 128 ядер нереально - слишком большое TDP.
Но проблемы Kunpeng как раз просто решаются - добавляются новые FPU юниты, оптимизируется микроархитектура. Следующая модель Kunpeng уже достигнет показателей в нижней границе текущих SpecRate для современных x86 (рост микроархитектурной скорости будет примерно таким же, как у Байкал Электроникс при переходе с Байкал-М на Байкал-S, ну может чуть меньше, т.к. что-то в Kunpeng 920 они всё же опимизировали). У Эльбруса же нет никаких перспектив роста, кроме увеличения частоты и размеров кэшей. Микроархитектура там жёстко приколочена к архитектуре и её переделка фактически будет означать создание новой архитектуры.
Ну т.е. случай Kunpeng'a это просто вопрос развития и оптимизации, если кратко. А у Эльбруса это потолок.
antag
06.09.2021 15:53+4Вы хотя бы уточнили информацию и характеристики про главный процессор компании Huawei.
Процессор Kunpeng 920 - это 64 ядра, а не 128. И там три кристалла в каждом процессоре Kunpeng 920, как показали на cайте wikichip.
Так для Эльбруса на 7 нм тоже можно разработать аналогичные два кристалла по 32 ядра. Это вопрос финансирования разработки. И даже можно вписать все это в нужное потребление.
Да, у Эльбрусов есть потолок по производительности, но этот потолок выше нынешних неамериканских альтернативщиков по FP, хотя и ниже по INT. И этот микроархитектурный уровень Эльбруса те "альтернативщики" превзошли только сейчас, а микроархитектура Эльбрус существует 15 лет, почти не меняясь.
Если кому-то здесь нужен относительно высокий уровень производительности FP без использования американских процессоров, то ставка на Эльбрусы была вполне оправдана какое-то время.
Для Байкал-S воспользовались топовыми мировыми наработками ядер ARM Cortex, и поэтому Байкал-S выиграет у нового Эльбрус-16С, который базируется на разработках и идеях 20-летней давности. Но те же китайцы пока не имеют таких совершенных ядер, как Cortex и Neoverse. И поэтому отставание от китайцев у Эльбруса не такое большое, как отставание от Intel, AMD и ARM.
Armmaster Автор
06.09.2021 16:34Да, про количество ядер согласен ( у них просто базовая версия сервера идёт с 128 ядрами, я поэтому постоянно путаю, 64 или 128).
Но все рассуждения о микроархитектуре Kunpeng и её развитии остаются в силе.
antag
06.09.2021 17:10+5Huawei закрыли доступ на новый техпроцесс, и поэтому никакого развития линейки Kunpeng больше нет.
А Эльбрус есть только на старых техпроцессах, где ограничены возможности.
Наиболее близкий аналог для Эльбруса - это Loongson. У них тоже своя архитектура и микроархитектура. И новый серверный процессор Loongson - это аналог Эльбрус-16С. У них по 16 ядер. У Loongson - 12 нм, Эльбрус - 16 нм. Производительность в среднем тоже схожая. При этом китайцы постоянно улучшали и развивали свои ядра Loongson уже 20 лет. И эти китайцы в итоге сейчас вышли на уровень Эльбруса. Они чуть сильнее в INT, но слабее в FP.
Есть высшая лига производителей, которая получает новые техпроцессы, новейшие ядра, и большие объемы производства. А есть вторая лига, которая получает старые техпроцессы и не самые оптимальные ядра. Байкалу из высшей лиги досталось хорошее ядро A75. Поэтому они сделают рывок в новом Байкал-S. Но остальные самостоятельные игроки второй лиги не имеют такого преимущества из-за хорошего ядра.
В рамках "второй лиги" будут и все разработки на RISC-V. Там же уже есть еще Sparc от МЦСТ. Но такие процессоры RISC-V и Sparc все равно будут уступать в несколько раз представителям "высшей лиги". А значит не смогут конкурировать на равных с лучшими процессорами.
А Эльбрус - это нестандартное решение на VLIW, что дает перекос в сторону более высокой производительности FP в ущерб производительности INT, что и отличает их от всех других представителей "второй лиги".
amartology
06.09.2021 17:15risc-v и Sparc все равно будут уступать в несколько раз представителям «высшей лиги».
Почему? ARM же не уступает х86. Это не вопрос системы команд, это вопрос выделенных на разработку микроархитектуры ресурсов.VlK
06.09.2021 18:58+2ARM перестал уступать x86 потому что Intel задержал ввод в производство следующего техпроцесса в то же время, когда TSMC сделали правильную ставку на EUV и смогли внедрить более тонкий техпроцесс.
Других тут секретов нет. В наши дни в реализации процессоров принципиальной разницы между x86 и Arm уже давно нет.Хотя x86, конечно, это довольно мерзкий набор инструкций.
amartology
06.09.2021 20:16+2ARM перестал уступать x86 потому что Intel задержал ввод в производство следующего техпроцесса в то же время, когда TSMC сделали правильную ставку на EUV и смогли внедрить более тонкий техпроцесс.
Вы сейчас тактично умолчали о существовании производимых на TSMC AMD Ryzen.VlK
06.09.2021 20:28+1У них не последний техпроцесс. 7нм против 5нм у apple, что только подтверждает мою мысль.
VlK
07.09.2021 09:19+1Вчера не было возможности нормально отписаться, пардон.
Итак.
Процесс есть, конечно же, у TSMC, а не у AMD. И TSMC последний процесс (5нм) продали Apple, а не столь богатая AMD пока использует позапрошлогодний 7нм техпроцесс TSMC с кусками 12нм от GlobalFoundries.
И сразу выясняется, что полноценные мощные ядра настольных AMD Ryzen работают так же, как мобильные ядра в Apple M1 с обрезанным теплопакетом.
С другой стороны, Intel выбрасывает безумные деньги в свои процессоры, но ничто не помогает ей в соревновании с AMD и Apple - техпроцесс отстает.
Тут, конечно, и талантливые инженеры, и все такое, но на первом месте стоит именно техпроцесс, позволяющий запихать больше логики в тот же квадратный мм.amartology
07.09.2021 09:55+1Разница между 5 нм и 7 нм хорошо известна и публично озвучивается TSMC. Она никак не объясняет разницы в производительности.
Да, техпроцесс важен для таких применений, и для любой компании, занимающейся производством мощных микропроцессоров, разумно вкладываться в меньшие проектные нормы, но техпроцесс не является панацеей. Можно получать значительное преимущество за счёт архитектуры, используя одну и ту же технологию.VlK
07.09.2021 11:05Можно получать значительное преимущество за счёт архитектуры, используя одну и ту же технологию.
При прочих равных разница действительно может проявиться. Помните, как продавали RISC в 80-ые? Простые инструкции позволяют делать быструю реализацию. Скажем, на 5% при прочих равных CISC-процессор проигрывает RISC-процессору.
Но история показала, что увеличение транзисторного бюджета и доступного теплопакета в полтора-два при переходе на более тонкий техпроцесс позволяет, к примеру, удвоить кэши на чипе. Или реализовать эмуляцию нужных инструкций. Или добавить вычислительных устройств - векторных ли, VLIW или еще каких.
Вот wikichip пишет, что при переходе с техпроцесса TSMC N7 (AMD Ryzen) на N5 (Apple M1) плотность размещения транзисторов увеличивается в 1.84 раза.
То есть при прочих равных можно пихнуть настолько больше памяти в чип, что конкретный набор инструкций вообще никакой роли не играет. Apple вот решила одновременно и тепла меньше выделять, и производительность нарастить.
Другими словами, дискуссия о производительности должна сводиться к техпроцессу.
Вот еще раз ваши слова:Можно получать значительное преимущество за счёт архитектуры, используя одну и ту же технологию.
Реально почти никогда не бывает так, что соревнуются строго наборы инструкций и их реализации. Выигрывает тот, кто получил более тонкий техпроцесс.
VlK
06.09.2021 18:15+5Дискуссию про VLIW, RISC, CISC иже с ними ведется разработчиками процессоров не первое десятилетие. Что @Armmasterсовершенно верно заметил, так это тот факт, что после коллапса Itanium консенсус в области гласит: VLIW/EPIC это не перспективно, а перспективно RISC с расширениями в форме всяких там наборов векторных инструкций (SSE и компания).
Это может быть верно, может верно не быть. Я же готов утверждать, что это не важно.
Концепции это просто концепции, на практике же многие микроархитектуры, в том числе ARM или x86, эволюционируют. x86 начиналась как CISC, но со временем стала реализовываться как эмуляция на микрокоде. Монопольный доступ к последнему техпроцессу Intel обеспечивал (до недавних пор) этому неуклюжему набору инструкций абсолютное превосходство в производительности. В следствие чего CISC, считающийся архаизмом уже лет тридцать как, продавался без каких-либо проблем.
Почему так? Потому что практически важен только один параметр: объем производства чипа. Объем определяет цену производства. Цена, в свою очередь, через продажи определяет объем. Главный провал Intel последних десятилетий это не несчастный Itanium, а упущенный в пользу ARM рынок носимых устройств. Что в долгосрочной перспективе привело к появлению конкурентов с доступом к нужному техпроцессу.
Еще раз. Конкретный набор инструкций не так важен, как объем производства.
При неоходимости любой набор инструкций (в стиле CISC, векторные инструкции, VLIW/EPIC, бла-бла-бла) можно эмулировать микрокодом (см. эмуляцию AVX512 у AMD) и всякими там железными ускорителями. Важней продать как можно больше процессоров, что позволит снизить цену отдельного чипа.
И в этом смысле Эльбрус - та же история CISC. Он может быть хорош для вычислительных задач, и не очень хорош для более общих программ. Такие вещи важны только нам, программистам.
Но экономика полупроводникового производства имеет свои законы. И разработчики Эльбруса, как мне кажется, их вполне осознают: в масштабах нашего локального рынка только они сейчас имеют хоть какой-то объем, что позволяет показывать разумную цену отдельно взятого устройства.
PS мои слова подтвердит масса канувших в Лету процессоров, наборы инструкций которых концептуально давали 100 очков вперед x86: Motorola, Sparc, POWER, Alpha...cepera_ang
06.09.2021 18:26+4Про объём производства всё правильно, но вот то, что разработчики Эльбруса их правильно осознают — здесь сомнительно. Если логику про объём корректно применять, то становится очевидно, что объём российского рынка настолько мизерный, что никакая, даже монопольная и обязательная архитектура не будет здесь достаточно хорошей, чтобы сравняться даже со средненькой, но мировой.
VlK
06.09.2021 18:54+2разработчики Эльбруса их правильно осознают — здесь сомнительно.
Очень даже осознают! МЦСТ лично платит тем больше за каждый напечатанный процессор, чем меньше партия.
достаточно хорошей, чтобы сравняться даже со средненькой, но мировой.
Не уверен, что в данном случае вообще идет речь о "сравняться". Я под прошлой статьей уже объяснял кому-то, что техпроцессов последних даже у Интела уже несколько лет как нет, и еще не факт, что появится. В вопросах производительности техпроцесс важней архитектуры. И никто никому этот самый техпроцесс не дает, а то и явно запрещает (см., к примеру, историю с Huawei).
Повторю свой тезис еще раз: любое конкретное решение в вопросах производительности процессоров не так важно, как использованный при производстве техпроцесс.amartology
06.09.2021 20:18МЦСТ лично платит
Платит МЦСТ или бюджет Российской федерации?техпроцессов последних даже у Интела уже несколько лет как нет
Они есть у AMD.Повторю свой тезис еще раз: любое конкретное решение в вопросах производительности процессоров не так важно, как использованный при производстве техпроцесс.
Важна не архитектура и даже не техпроцесс. Важна софтовая экосистема. И все разговоры о прекращении изобретения велосипеда в пользу других решений — они в первую очередь про то, чтобы делать что-то, для чего не нужно писать весь софт самостоятельно.VlK
07.09.2021 09:39+2Платит МЦСТ или бюджет Российской федерации?
Это вы к какому именно моему замечанию комментарий добавили? :-) Как МЦСТ, так и любые их конкуренты, будут питаться прежде всего из бюджета, что очевидно. Соревноваться на глобальном рынке с китайцами и китайе-тайваньцами бесполезно, очевидно же.
Важна не архитектура и даже не техпроцесс. Важна софтовая экосистема. И все разговоры о прекращении изобретения велосипеда в пользу других решений — они в первую очередь про то, чтобы делать что-то, для чего не нужно писать весь софт самостоятельно.
И тут мы вот-вот придем к мысли о том, что ничто и никому не нужно, потому что китайцы и так сделают лучше и дешевле :-)
Но если серьезней, то да, важно абсолютно все. С точки зрения производительности - техпроцесс. С позиции пользователей - софт. И даже критики не могут поспорить с тем, что в МЦСТ делают вполне достойный компилятор.
В статье речь шла о производительности, но не упоминался техпроцесс, именно поэтому я тут постарался раскрыть эту тему: разница в наборе инструкций делает 5% разницы в производительности, а вот техпроцесс - 30%.
Меня смущает в позиции противников Эльбруса следующее. 50 лет назад были в моде CISC с их почти высокоуровневым ассемблером. 35 лет назад - RISC. 25-30 лет назад появились векторные процессоры и VLIW. 20 лет назад EPIC пришел на смену VLIW, и появились GPU.
Создавай вы новый процессор 35 лет назад, то он был бы примитивным RISC. 20-25? Имел был VLIW или EPIC черты. 10? RISC + векторные инструкции + элементы VLIW.
Популярные наборы инструкций общего назначения вроде архаичных x86 и немолодых уже ARM реально содержат всю эту историю. Внутреннее устройство этих железок не отличается в практическом смысле. RISC-V, ARM, x86, MIPS... Оно все сводится к транзисторному бюджету (= техпроцесс), куда укладываются или не те же самые вычислительные устройства.
Так какая разница? Сегодня ветер дует в сторону ARM, завтра еще куда-нибудь. Мы каждый раз будем выбрасывать деньги на очередную моду?amartology
07.09.2021 17:54Мы каждый раз будем выбрасывать деньги на очередную моду?
Есть мнение, что на разработку процессора Байкал-М было потрачено радикально меньше времени и денег, чем на Эльбрусы, а результат как минимум не хуже. А если так, то зачем тратить больше?VlK
07.09.2021 19:10+2Есть мнение
Существует много мнений. :-) Вот вы, к примеру, считаете, что разрабатывать самостоятельный набор инструкций - дело неблагородное.
на разработку процессора Байкал-М было потрачено радикально меньше времени и денег, чем на Эльбрусы
А я вот считаю, что МЦСТ за эти деньги проделали огромную работу, причем как техническую, так и организационную. А еще я тут много писал о том, что конкретный набор инструкций на фоне экономических аспектов производства процессоров играет в вопросах производительности незначительную роль.
МЦСТ сделали процессор, компилятор, портировали ОС и прикладной софт. Софт работает приемлемо быстро. Это уже очень и очень много.
Предвидеть же появление всяких там OpenPower, OpenMIPS и RISC-V в свое время они никак не могли, да и с реализацией это бы никак не помогло.
Взамен же предлагается закрытый Arm (ну или несуществующее Yadro), да еще и в исполнении конторы, которая не всегда справлялась с политическими и экономическими проблемами.
На мой взгляд дешевле и развивать имеющийся набор инструкций вкупе с компилятором, тем более что боги компиляторостроения утверждают, что за совместной разработкой компиляторов и железа будущее.
Но это всего лишь мое мнение, которое есть.Arioch
08.09.2021 14:00+1МЦСТ сделали процессор,
Точнее - два. SPARC и E2K
компилятор, портировали ОС и прикладной софт.
То, что можно было бы не делать, потому что под SPARC оно уже было
Это уже очень и очень много.
В смысле академического результата и прокачивания скиллов - да.
В смысле получения практически полезного результата - весьма дорогостоящее изобретение велосипеда с квадратными колёсами, который будет "приемлемо быстро" ездить по специальным дорогам, если их для него везде построить. Это результат? Да. Большой? ДА! Но полезный ли, если можно было бы тупо и скучно клепать гладкие дороги и велосипеды с круглыми колёсами?> На мой взгляд дешевле и развивать имеющийся набор инструкций вкупе с компилятором
Ну так МЦСТ с этого и начинал. Релизовывал "имеющийся" SPARC под которые были компиляторы и коммерческие и GCC, и именно это сейчас собираются делать Байкал и Синтакор (только не со SPARC'ом, а с другими ISA).
Но они решили "пойти своим путём". Причём в эпоху усыхания, когда усыхают и вымирают даже когда-то вполне успешные Alpha-SPARC-MIPS-PowerPC. Они решили "в одну харю" развернуть общемировую тенденцию. Безумству храбрых поём мы песню.
Предвидеть же появление всяких там OpenPower, OpenMIPS и RISC-V в свое время они никак не могли
Они могли бы их cоздать на базе своей E2K и быть первыми. Нужно было "скрестить" широко известные концепции коммерческих SIG (тот же PowerPC alliance) и GPL/BSD. Если уж решили перечеркнуть общемировой опыт и сделать революцию - то надо тогда делать революцию.
Или они (плюс государство) могли бы выкупить у Sun все нужные права на SPARC, в том числе даже и с самой компанией.
edo1h
08.09.2021 14:24+1Или они (плюс государство) могли бы выкупить у Sun все нужные права на SPARC, в том числе даже и с самой компанией.
тут уж какой-то опель не дали купить, а вы замахнулись на покупку спарка
(речь не про то, что опель дороже, а про передачу технологий; хотя, если подумать, в автопроизводсте тоже куча технологий есть, которые могут быть использованы и военными)VlK
08.09.2021 14:36Мне как-то смешно спорить с родительским комментарием: купи то, купи это, сделай открытым, и все это - 20 лет назад. Есть вещи, которые не продаются. Sun не продала был Sparc полностью. И сама Sun, очевидно, нам не продалась бы.
История с опелем была, кстати, до Мюнхенской речи и 2008 года, то есть в эпоху дружбы-жевачки. Про сейчас даже говорить не приходится.amartology
08.09.2021 14:40Есть вещи, которые не продаются. Sun не продала был Sparc полностью.
Система команд SPARC — опенсорсная. Не надо ничего покупать, можно просто взять задаром.
Gryphon88
08.09.2021 15:13Кстати, а как это юридически выглядит: есть открытая система команд, которую владелец берёт и закрывает. Что происходит с теми, кто уже её реализовал? Не могут делать новые разработки на основе теперь закрытой системы или как?
edo1h
08.09.2021 15:26я думаю так же, как с софтом: отозвать открытие нельзя. но можно выпустить новую версию под новой лицензией.
Civil
08.09.2021 14:42-4тут уж какой-то опель не дали купить
А есть где почитать про "не дали купить" это?
А то я поискав нашел случай 2009 года про попытку купить Опель консорциумом из канадской Magna и Сбербанка, а потом на базе документов из wikileaks уже в 2011 году стало известно что сделка сорвалась потому что потенциальные покупатели хотели позже продать заводы российскому государственному автопроизводителю, что вкупе с рестуктуризацией GM позволило им выбить гос поддержку и опель стало продавать не нужно.
Это в общем и целом не звучит как "не дали купить", причины были сугубо внутри GM.
amartology
08.09.2021 14:39Или они (плюс государство) могли бы выкупить у Sun все нужные права на SPARC, в том числе даже и с самой компанией.
Зачем что-то выкупать? Система команд SPARC — опенсорсная.Arioch
08.09.2021 16:06Вот не думаю, что многолетнее сотрудничество МЦСТ с санями заключалось только в чтении хором опенсорсных документов. Думаю, что всякое ноу-хау тоже передавалось, в виде ли обучения сотрудников или ещё как.
victor_1212
06.09.2021 22:28>Повторю свой тезис еще раз: любое конкретное решение в вопросах производительности процессоров не так важно, как использованный при производстве техпроцесс.
именно, ключевые на данный момент вещи техпроцесс, и экосистема
VLev
07.09.2021 00:22+2объём производства Эльбрусов за всё время их существования был озвучен в прошлом году Кимом: 20 тысяч единиц.
Новости этго года существенно ничего не поменяли, навскидку:
Alcor
06.09.2021 19:15+6У Эльбруса, на самом деле, есть только одна проблема - он не нужен. Причем не нужен он в первую очередь своим создателям. Если посмотреть на RISC-V, то популярность она набрала не по команде какого-то лидера, а из-за фактически бесплатных камней, с ARM было примерно то же самое. Цена решает. Если бы создателям Эльбруса он был нужен, то мы бы уже видели его везде, на диджикее бы продавались отладочные платы по цене в десяток баксов за штуку, было бы куча акций, по которым его можно было бы получить бесплатно (как было с младшими армами), одноплатники с ним шли бы для обучения. Производительность не имеет решающего значения, значение имеет цена и доступность. А Эльбрус фиг купишь, значит он нужен ради распила.
Sabubu
06.09.2021 23:01+5Не могу пройти мимо. По моему, вы в статье немного манипулируете, рассчитывая на то, что читатель не сможет разобраться и поверит вам на слово. Вы сравниваете 2 примера кода сортировки и пытаетесь на их примере показать недостатки архитектуры VLIW в сравнении с архитектурой Интел. Что динамическое планирование, осуществляемое процессором Интел, эффективнее статического планирования компилятором.
Но код этого не показывает.
Действительно, в коде процессора Эльбрус мы видим много NOP'ов:
- 2 ненужных NOP в начале цикла. Это, очевидно, ошибка компилятора, так как никакой нужды в них нету. Их нужно вынести за цикл.
- 2 NOP после операции чтения из памяти
- 3 NOP после сдвоенной операций записи в память
В то же время процессор Интел выполняет итерацию за 3 такта. Процессор Интел, видимо, не делает пауз после операции работы с памятью (если бы он делал, он бы не уложился в 3 такта). Также, я подозреваю, он делает спекулятивную запись в память (которая будет отменена при выполнении перехода jle .L7).
Последние 5 NOP вставлены не из-за того, что архитектура VLIW или статическое планирование плохи. Нет, они вставлены из-за того, что в Эльбрусе медленная подсистема работы с памятью. Он, получается, не умеет быстро читать данные и быстро записывать, и, видимо, не умеет записывать спекулятивно.
Но это не недостаток архитектуры VLIW или статического планирования. Это недостаток конкретного процессора Эльбрус. Архитектура VLIW не запрещает и не мешает вам сделать работу с памятью/кешем быстрой. А статическое планирование позволяет уложить цикл в 3 такта.
Если бы у нас был процессор, который быстро работает с памятью, то этот цикл можно было бы статически скомпилировать в 3 такта:
L1: mov edx, [rax] | tmp = rax + 4 | cmp rsi, rax | подготовка перехода к L8
L2: (спекулятивно) mov [tmp], edx | cmp edx, ecx | jne .L8 | подготовка перехода к L7 и к L1
L3: (спекулятивно) mov [rax], ecx | jle .L7 else jmp .L1 | (спекулятивно) sub rax, 4То есть, в теории архитектура VLIW и статическое планирование позволяют достичь той же производительности, что и Интел. А если бы процессор позволил нам совместить в одной команде cmp с jmp и делать 2 операции записи за такт, то может быть этот цикл можно было бы ужать и в 2 такта.
Да, сложно сделать такой компилятор. Но сделать аналогичный "оптимизатор" в железе может быть еще сложнее и дороже.
Далее, про Интел. Архитектура x86 это как раз слабое место Интел. Эта архитектура была придумана для 16-битного процессора, а часть команд в ней (вроде add bl, al) вообще была введена для совместимости с 8-битным 8080. То есть, эта архитектура содержит 50-летнее легаси, разрабатывалась для медленных процессоров без распараллеливания операций, без кеша.
Соответственно, любая более новая архитектура будет лучше, чем у Интел. То, что Интел при плохой архитектуре показывает такую производительность, говорит лишь о таланте их инженеров и огромном количестве вложенных в разработку средств.
Приводить как пример хорошей архитектуры Интел нельзя. Это пример, как плохая архитектура может быть коммерчески успешной.
Что касается "сложности" ассемблера. Я это вообще не считаю недостатком. Если мы можем упростить процессор путем усложнения ассемблерного кода, то это однозначно выигрыш. Так как написать код дешево, просто и быстро, а проектировать железо дорого и сложно.
Ну и еще одна мысль. Допустим, Интел потратил миллиард долларов и сделал быстрый процессор. А мы потратили 10 миллионов и сделали процессор в 5 раз медленнее. Но в пересчете на затраченный доллар мы выиграли в 20 раз.
creker
06.09.2021 23:21+3Приводить как пример хорошей архитектуры Интел нельзя. Это пример, как плохая архитектура может быть коммерчески успешной.
Мне вот всегда непонятны были эти теоретизирования. Какая разница сколько там легаси. Если оно не мешает, то плевать. А оно не мешает, судя по постоянному росту IPC и суммарной производительности чипов. Пусть хоть еще 50 лет пилят. А что до новой архитектуры. Есть мнение, что набор инструкций не имеет ровным счетом никакого значения. Если посмотреть на лучших представителей, микроархитектура у них у всех одинаковая. Включая новенький М1. То, что они гоняют разные инструкции поверх нее, никак в этом всем не прослеживается. Человечество достигло пределов того, что оно может выжать в микроархитектуре обычными средствами. Оно достигло пределов того, что можно упаковать в кристалл. Поэтому сейчас в индустрии идет качественный переход. Сейчас правит балом техпроцесс, интерконнекты и упаковка. 3d stacking, тайлы, чиплеты — вот будущее индустрии, а не арм или x86. Достаточно посмотреть презентации интел, тсмц, амд на прошейдшей пару недель назад hot chips.Ну и еще одна мысль. Допустим, Интел потратил миллиард долларов и сделал быстрый процессор. А мы потратили 10 миллионов и сделали процессор в 5 раз медленнее. Но в пересчете на затраченный доллар мы выиграли в 20 раз.
Клиентам до этого никакого дела. Интел может сколько угодно тратить. Важно, что он быстрый и просит за это немного денег. Пусть хоть трилионы тратят, это их дело.
cepera_ang
06.09.2021 23:26+1Если бы у нас был процессор, который быстро работает с памятью
Если бы у нас была быстрая память, то 95% содержимого любых современных процессоров можно бы было просто выкинуть и получить быстрый и эффективный процессор. Вы посмотрите на план любого современного процессора — в нём ALU занимает один квадратный миллиметр, а остальные сто — это костыли, чтобы спрятать медленную память. Назовите любую фичу последних 50 лет в процессорах и окажется, что она нужна только из-за памяти.
То есть, эта архитектура содержит 50-летнее легаси, разрабатывалась для ...
Легаси карман не тянет (почти). То, что в системе команд есть древние, не значит, что процессор тормозит от их существования. Когда процессор с кучей легаси выполняет сгенерированный под него компилятором (или разработчиком) плотный AVX код, он не тормозит на n% только потому что в нём есть команды 8-битного режима. А вот этот AVX разработан вполне уже сновья и без оглядки на 1973-й год.
Если мы можем упростить процессор путем усложнения ассемблерного кода, то это однозначно выигрыш. Так как написать код дешево, просто и быстро, а проектировать железо дорого и сложно.
Ха-ха-ха.
А мы потратили 10 миллионов и сделали процессор в 5 раз медленнее. Но в пересчете на затраченный доллар мы выиграли в 20 раз.
Разработчики процессора может и выиграли, а заказчики получат процессор в пять раз медленее и в пять раз дороже, а оплатят этот банкет простые налогоплательщики.
yalex1442
06.09.2021 23:46+1>проектировать железо дорого и сложно.
>Ха-ха-ха.
В сегодняшних условиях многомесячных очередей на доступ к мощностям кремниевых фабов, подход к проектированию чипов с вынесением из кремния всего чего можно на сторону софта смотрится все более разумнымamartology
06.09.2021 23:48+2А в чем разумность? Если ваша очередь уже пришла, то размер чипа роли не играет. Если не пришла — тоже)
cepera_ang
06.09.2021 23:55+1Эти очереди и возникают потому, что клиентам нужна вычислительная мощь.
Работа железячников по оптимизации железа имеет огромный мультипликатор — одно дело оптимизировать какой-нибудь горячий цикл и получить 5% в одной задаче из миллиона в датацентре или на пользовательских устройствах, другое дело оптимизировать те же 5% в новой микроархитектуре — это улучшение получат все миллионы пользователей. А затраченные усилия могут быть сравнимы.
Поэтому мы и видим движение совершено наоборот в сторону внесения всего в кремний — с каждым годом транзисторный бюджет всё растёт и растёт, но всё равно приходится ждать памяти. К тому же, реализуя в железе, есть возможность всё тщательно продумать и запроектировать, в отличие от "аджайл-херакс-херакс и в продакшен" как принято в софте, поэтому зачастую в железе получается вдвойне эффективно — кремний и работает быстрее и к разработке подходят серьёзнее, потому что однажды залитое в кремень потом очень сложно переделать.
japplegame
07.09.2021 17:27Если бы у нас был процессор, который быстро работает с памятью
Если бы у нас была быстрая память
Первая цитата о медленно работающем с памятью процессоре, а ваша цитата о медленной памяти. Это же разные вещи.
cepera_ang
07.09.2021 17:37Возможно я недопонял чего-то, но тогда значит "процессор быстро работает с памятью"? Вот у нас есть типичная DRAM с доступом за 80ns и процессор на 2-3гигагерцах, т.е. под 200 тактов на один доступ. Что в данном случае будет обозначать "быстро работает с памятью"?
japplegame
07.09.2021 19:32Может об отсутствии тех самых костылей для компенсации работы с медленной памятью?
creker
08.09.2021 02:39Вы предлагаете бороться со следствием. Эти костыли нужны, чтобы процессор хоть как-то работать мог при такой медленной памяти. Убрать их и мы вернемся в каменный век, где конвейер тупо стоял и ждал память постоянно. Лучшее решение проблемы это убрать память вообще (хотя бы в ее привычном виде), к чему мы кажется движемся с учетом прогресса с 3d компоновкой и HBM. В каких-то областях вычислений это может быть вполне рабочим вариантом. Во всех остальных же все останется как есть и иерархия кэшей/памяти постоянно только расширяется. Мы только за последнее время накинули туда несколько новых уровней.
cepera_ang
08.09.2021 11:05Да, попытки ускорить память есть, но там речь идёт грубо говоря о том, что бы не дать разрыву между процессором и памятью перейти из порядка сотен тактов в тысячи, а может даже снизить до десятков.
А пока имеем что есть — в процессоре куча железа, которое смотрит вперед, угадывает какую память скоро будем читать/писать и старается максимально забить очереди на всех уровнях кеша и наружу. Но там уже столько наворочено, что предсказывается уже всё, что можно, включая псевдорандом, остались только натурально непредсказуемые доступы к памяти. И всё равно, вот этот последний процент промахов даёт до десятков процентов замедления (и чем шире проц — тем больше).
amartology
06.09.2021 23:47+1Но в пересчете на затраченный доллар мы выиграли в 20 раз
Можно ещё бесплатно ничего не делать. Или бесплатно взять готовый опенсорсный восьмибитный микроконтроллер, так мы в пересчёте на потраченный доллар вообще всех обгоним. Клиенты только вряд ли будут рады восьмибитному микроконтроллеру вместо серверного процессора.
Armmaster Автор
07.09.2021 00:35+72 ненужных NOP в начале цикла. Это, очевидно, ошибка компилятора, так как никакой нужды в них нету. Их нужно вынести за цикл
Это не ошибка. Это необходимость выдержать задержку в 3 такта от чтения из памяти значения в r0 до его использовании в операции cmplesb
Нет, они вставлены из-за того, что в Эльбрусе медленная подсистема работы с памятью
Нет, подсистема работы с памятью в Эльбрусе как раз отличная. Nop вставлены для того, чтобы выдержать задержку в 3 такта от чтения из памяти до его использования (считаем, что попали в L1). Это вполне стандратная задержка для процессоров, на более высоких частотах она может увеличиваться до 4-х.
Остальной ваш поток сознания, уж извините, даже комментировать не хочу. Начните изучения вопроса хотя бы с классики: Хеннеси&Паттерсон , Computer Architecture: A Quantitative Approach
Arioch
07.09.2021 18:05Это не ошибка. Это необходимость выдержать задержку в 3 такта от чтения из памяти значения в r0 до его использовании в операции cmplesb
Предположу, что имелось в виду, что "sufficiently smart compiler" обязан был начать чтение из памяти за 3-10 тактов ДО начала цикла, а в дальнейшем - на предыдущей итерации цикла. Регистровый файл же огромный (на x86 тоже, только он скрыт позади registry mapping). Надеюсь, move регистр-регистр на e2k почти бесплатный? В общем то же, что на "обычных" процессорах делают OoO и предиктор обращения к памяти. Ведь в этом же и идея VLIW, вынести эти хитрости в компилятор? и тогда недоработки компилятора - это такая же ошибка системы, как кривая работа OoO и кэша в "пентиуме".
Кстати, а что будет в случае cache miss, когда "nop 2" окажется по определению недостаточным? Остановка всего конвейера? Но тогда почему бы ровно так же не останавливать конвейер на операциях cache/register без явного nop? Или в случае cache miss процессор отработает заказанные "три такта" и дальше почешет, не дожидаясь прогрузки из ОЗУ ?
Armmaster Автор
07.09.2021 18:12Предположу, что имелось в виду, что "sufficiently smart compiler" обязан был начать чтение из памяти за 3-10 тактов ДО начала цикла
Предполагать можно много чего, наверное. Вообще, этот цикл компилятор плохо соптимизировал, на самом деле. Как тут уже выснили, если его скомпилить с -O2 (sic!), там лучше намного получается. Но это всё как раз хорошо демонстрирует реальные проблемы статического планирования, а не как эт овыглядит в бравурных реляциях от МЦСТ.
Кстати, а что будет в случае cache miss, когда "nop 2" окажется по определению недостаточным?
Да, весь конвейер будет булькать
Но тогда почему бы ровно так же не останавливать конвейер на операциях cache/register без явного nop?
В общем случае как-то так можно делать, но там исторически не всегда был scoreboarding (т.е. аппаратура не гаранировала доставку корректного результата если задержка не выдержана программно), плюс вроде это иногда может увеличивать задержки. В любом случае, по перфу это никак положительно не скажется.
Arioch
07.09.2021 19:51Ну "sufficiently smart compiler" давно уже стало мемом. Кроме прочего ещё и потому - что чем "умнее" компилятор, тем он тормознее, и тем длиннее цикл разработки, которые в случае всяких интерпретируемых LISP-оподобных вообще делается в REPL-режиме кусками по одной строке.
И да, если два гиганта HP+Intel не смогли за десятилетия это сделать совместно, даже с привлечением Microsoft и GCC, то... Elbrus должен иметь огромное самомнение, чтобы надеяться это сделать. Ну или даже и не собираться делать это на самом деле.В любом случае, по перфу это никак положительно не скажется.
Гипотетически может сказаться. Просто выйдет некий улучшенный Elbrus 2030 в котором будет предиктор обращения к памяти, и окажется что загрузка там занимает уже не три такта, а один. Но поскольку "nop 2" прибит гвоздиком - увы, процессор будет тупо ждать давно приехавшее значение.
Ведь что интересно, VLIW по идее это как раз процессор для компиляторов, для VM, JIT и вот это вот всё. Для компиляции "по месту" под конкретное железо (как Transmeta). Как всякие OpenCL и прочие шейдеры на видеокартах. Иначе это в самом деле не имеет смысла. Казалось бы эльбрусовцам надо не C++ вылизывать, а как раз JS, JVM, .Net, Parrot и всякие тензоры... А C++/Fortran/Pascal выедет на интринзиках и инлайнящихся полу-ассемблерных библиотеках типа Intel TBB, если это кому-то в самом деле сильно понадобится
unv_unv
09.09.2021 07:37Поясните по поводу «NOP 2 прибит гвоздиком». Если загрузка занимает 1 такт, то зачем NOP 2? Или речь о том, что с использованием предсказателя обращений памяти загрузка занимает от 1 до 3 тактов и всё равно придётся вставлять NOP 2 на всякий случай? Но что мешает вместо NOP 2 добавить команду, взаимодействующую с этим самым предсказателем?
Arioch
09.09.2021 11:45+1Поясните по поводу «NOP 2 прибит гвоздиком»
Открываете статью, смотрите распечатку кода, порождённого компилятором Эльбрус C++ для процессора Эльбрус, видите там команду nop 2.
Если загрузка занимает 1 такт, то зачем NOP 2?
Вопрос к МЦСТ, разработчику компилятора Эльбрус C++ для процессора Эльбрус
с использованием предсказателя обращений памяти загрузка занимает от 1 до 3 тактов и всё равно придётся вставлять NOP 2 на всякий случай
Она УЖЕ вставлена. Появится предсказатель или нет, но команда nop 2 уже записана компилятором в исполняемый код программы.
Но что мешает вместо NOP 2 добавить команду, взаимодействующую с этим самым предсказателем?
Добавить куда? В процессор? да хоть команду "сварить кофе" добавьте. Команда nop 2 УЖЕ вставлена в программу и там останется.
История RISC/CISC и x86 показывает, что идёт положительная обратная связь. Компиляторы не умеют использовать сложные команды; процессоры начинают вылизывать простые команды, оставляя сложные для галочки (они работают, но работают дольше, чем аналогичный десяток простых команд); компиляторы теперь даже если научатся - не хотят использовать сложные (и медленные) команды.
Плюс к тому, программа, не работающая на процессорах купленных в прошлом году, обычно никому не нужна.
Поэтому пока все уже выпущенные процессоры Эльбрус не окажутся на свалке - компиляторы будут добавлять стандартный nop 2, а не какие-то новомодные нововведения, совместимые с тремся с половиной компьютерами. И даже когда появятся новые компиляторы (за новые деньги и с новыми ошибками) - никто не бросится бесплатно пересобирать старые программы. А если кто и пересоберёт, никто не бросится их обновлять.
Всё, nop 2 - это всерьёз и надолго.
P.S. на самом деле "команду, взаимодействующую с этим самым предсказателем" даже добавлять не надо. Это уже будет предательство теоретической частоты VLIW. Предсказатель же должен быть в "умном калькуляторе", а не "в кремнии". Надо просто использовать два регистра, вместо одного, и грузить значение ДО начала цикла, а после начала - в ПРЕДЫДУЩЕЙ итерации. Но сама МЦСТ "не шмогла", а другим даже и позволять не собирается. А учитывая так себе опыт HP+Intel+Microsoft, у которых ресурсов было несравнимо больше, то и надежд не много.
unv_unv
09.09.2021 19:50+1Ну вот в ветке ниже (https://habr.com/ru/post/576420/comments/#comment_23456356) оказалось, что NOP 2 гвоздиком не прибит и что это не «всерьёз и надолго» — что при других настройках происходит компиляция всего цикла в одну широкую команду.
Civil
09.09.2021 20:04+1при других настройках происходит компиляция всего цикла в одну широкую команду.
Внутреннего цикла, ценой разрастания внешнего. И как скомпилировал, так и прибьет гвоздями до следующей перекомпиляции.
В итоге можно попытаться костылями (там в общем из треда-то следует что это не ошибка компиляции, а осознанное взвешенное решение для общего случая) сделать лучше в тестовом примере, испортив жизнь во всех других случаях (так как, строго говоря, разрастется внешний цикл в разы). Поэтому выводы человек выше делает верные, просто Вы недочитали что говорили в тредике.
Arioch
10.09.2021 18:48-1что при других настройках происходит компиляция всего цикла
Других настроек не будет. Просто вот вообще не будет.
Закажите у Майкрософта собрать вам Windows 95 компилятором Visual C++ 2020 в 64-битах со всеми инструкциями процессоров 2015-2021 годов.Потом расскажите, какой был ценник и заплатили ли вы его.
Повторяю:Поэтому пока все уже выпущенные процессоры Эльбрус не окажутся на свалке - компиляторы будут добавлять стандартный nop 2, а не какие-то новомодные нововведения, совместимые с тремся с половиной компьютерами. И даже когда появятся новые компиляторы (за новые деньги и с новыми ошибками) - никто не бросится бесплатно пересобирать старые программы. А если кто и пересоберёт, никто не бросится их обновлять.
Заодно сравните популярность настольных и серверных Линуксов, собираемых из исходных текстов (Gentoo, LFS и аналоги/производные), и Линуксов, раздаваемых в виде "прибитым гвоздиком" собранных кем-то где-то бинарных файлов.
YuriPanchul
07.09.2021 07:15+5*** Если бы у нас был процессор, который быстро работает с памятью, то этот цикл можно было бы статически скомпилировать в 3 такта: ***
Дык вот тут-то и самое-самое слабое место VLIW!
VLIW хорошо работает константной латентностью памяти!
Но в современных процессорах доступ к памяти может длиться от 2 тактов (scratch memory внутри процессора) до 200 тактов (промах L1 и L2 кэшей). В таких условиях OoO может работать, а вот комбинация VLIW, даже с хорошим комплятором - не очень.
farafonoff
07.09.2021 10:17Интел не делает пауз, потому что он OoO. В этом и смысл всего цикла статей.
Архитектура X86 под собой имеет какую-то хитрую и быструю микроархитектуру, которая и позволяет ей идти вровень с более новыми конкурентами (ARM).
Сложность ассемблера - не недостаток, пока можно достаточно оптимизировать программы не заглядывая в ассемблер. (Когда я оптимизирую код на java или js, ассемблер мне вообще не нужен, а скорость примерно сравнима с C++). Судя по всему, у VLIW ручная оптимизация дает до 10 раз выигрыша, этим сложно пренебречь.
Если вы бежите марафон за 2 часа, а я иду за 10 часов, это ничего не говорит про эффективность на "затраченный доллар".
beeruser
07.09.2021 19:11+82 ненужных NOP в начале цикла. Это, очевидно, ошибка компилятора, так как никакой нужды в них нету. Их нужно вынести за цикл.
2 NOP после операции чтения из памяти
3 NOP после сдвоенной операций записи в память
Вот оно чё(с)
У вас почти получилось «поучить» не только автора, но ещё и его оппонента компиляторы писать!
Сколько лет вы программируете на ассемблере E2K? Хотя бы 1 секунда есть?
Если посмотреть на конец цикла, имеем{ ct %ctpr1 ? ~%pred0 } { nop 2 disp %ctpr1, .L636 ldw,0 %dr10, %dr3, %r0 }
Вы уверены, что disp %ctpr1 можно выполнять сразу после операции перехода?Их нужно вынести за цикл.
С какой целью? НОПы не являются вычислениями.
Я уже давал ссылку вашим коллегам — «учителям».
www.csl.cornell.edu/courses/ece4750/handouts/ece4750-T13-vliw-processors.pdfVLIW Compiler Responsibilities
• Schedules to maximize parallel
execution
• Guarantees intra-instruction parallelism
• Schedules to avoid data hazards (no
interlocks)
– Typically separates operations with explicit NOPsОн, получается, не умеет быстро читать данные и быстро записывать, и, видимо, не умеет записывать спекулятивно.
Эльбрус умеет не только записывать спекулятивно, но и зачитывать.Если бы у нас был процессор, который быстро работает с памятью, то этот цикл можно было бы статически скомпилировать в 3 такта:
L1: mov edx, [rax] | tmp = rax + 4 | cmp rsi, rax | подготовка перехода к L8
L2: (спекулятивно) mov [tmp], edx | cmp edx, ecx | jne .L8 | подготовка перехода к L7 и к L1
L3: (спекулятивно) mov [rax], ecx | jle .L7 else jmp .L1 | (спекулятивно) sub rax, 4
Что, если я вам открою маленькую тайну — в процессорах Интел латентность чтения данных из кэша составляет 5 тактов, т.е. ещё больше чем на Эльбрусе. Вы шокированы?
То что вы тут понаписали, невозможно исполнить на in-order процессоре за 3 такта.
«cmp edx, ecx | jne .L8» может быть выполнена на х86 в одном такте только потому, что macro fusion объединит две операции в одну. Иначе будет задержка по данным.Так как написать код дешево, просто и быстро, а проектировать железо дорого и сложно.
Это утверждение не соответствует действительности.
Писать код долго и дорого.
По факту сделать процессор за 500 миллионов дешевле и быстрее чем тупо пересобрать и оптимизировать весь софт. Потому что никто не будет этого делать.Но в пересчете на затраченный доллар мы выиграли в 20 раз.
На соревнованиях по бегу, Леонид Ильич занял второе место, а американский президент пришел предпоследним(с)Armmaster Автор
07.09.2021 23:40+1Писать код долго и дорого.По факту сделать процессор за 500 миллионов дешевле и быстрее чем тупо пересобрать и оптимизировать весь софт. Потому что никто не будет этого делать.
Эти слова надо золотом выбить на Красной площади.
К сожалению, я не очень хорошо акцентировал данную мысль в статьях, что является упущением
Arioch
08.09.2021 15:01+1В случае "ведомственного НИИ" это не так.
Тут вопрос в масштабируемости/тиражируемости и "размазывании" капитальных инвестиций по тысячам/миллионам/миллиардам единиц товара.
Если бы программы и процессоры изготавливались одинаковыми тиражами, то процессор был бы несравнимо дороже. В конце концов, для выпуска новой версии программы нужны минуты/часы, а новой версии процессора "от Verilog'a до коробки в магазине" ?Поэтому, если есть изолированная структура, которая сама себе делает процессоры и сама себе пишет программы, то внутри неё всё именно так: процессор менять долго и дорого, а софт - быстро и дешёво. МЦСТ+ВПК например именно такие, во всяком случае так о себе традиционно думают.
Проблема именно в переходе к "глобальному рынку", когда процессоры делают десяток вендоров тиражами от 100К, а программы пишут не только гиганты типа Microsoft, но и безымянные анонимы на коленке (любой веб-мастер делая страничку сложнее визитки делает программу тиражом один экземпляр). И всех их просто перечислить даже не получится, не то что принудить переписать программу.
Соответственно, люди "внутри" и "снаружи" пузыря действительно просто не понимают друг друга.Ещё аналогия - Япония. По всей стране проходит раскол, две разные системы электрообеспечения. Казалось бы дел на одни сутки, "дать приказ" и в "день М" лишняя система выключается и вся страна строем переходит на одну. А вот хрен, десятилетия проходят - ничего не меняется.
Ещё одна аналогия, военная "манчестерская" шина. В её варианте MIL-STD - полно бесплатных документов и толстых учебников хоть от Боинга. В российском - 30 страничек ГОСТа, за которые ещё и заплатить надо. Один из этих миров явно вывернут наизнанку, но в каждом из зазеркалий наверняка искренне уверены, что правильно именно у них.
OpenA
13.09.2021 03:50Вы уверены, что disp %ctpr1 можно выполнять сразу после операции перехода?
Конечно можно, в чем проблема? Мало тог, оно и выполняется сразу в следующем такте, nop 2 стоит для следующей команды, которая очевидно использует результат
ldw,0 %dr10, %dr3, %r0Это утверждение не соответствует действительности. Писать код долго и дорого. По факту сделать процессор за 500 миллионов дешевле и быстрее
Вы бредите, даже в той же мцст разработкой софта (всего - библиотеки, компиляторы дистрибутив) занимается 20 человек, а железом 200. Во вторых какая бы железка не была, хоть за 100 хоть за 500 миллионов, под нее все равно придется софт портировать и ускорять под новые инструкции, автоматом к процессору ничего не прилогается.
Civil
13.09.2021 10:40Вы бредите, даже в той же мцст разработкой софта (всего - библиотеки, компиляторы дистрибутив) занимается 20 человек, а железом 200
Вы так говорите, как будто МЦСТ тут вообще показательные. К тому же еще вопрос, точно ли вы правы про 20 человек и 200 и распределение задач? Откуда у вас инфа?
Во вторых какая бы железка не была, хоть за 100 хоть за 500 миллионов, под нее все равно придется софт портировать и ускорять под новые инструкции, автоматом к процессору ничего не прилогается.
То есть если сделать armv8.2 (или rv64g, как удобнее) совместимый процессор, то на нем ничего не запустится и софт на него придется портировать? Расскажите почему так?
spam-receiver
07.09.2021 02:16+2MZjr
08.09.2021 03:02+1ага, 47% компенсирует Минпромторг, а если вдруг процессор не выкатят, то ВТБ не виноваты)
trak
07.09.2021 09:09+1Тут столько светлых голов высказалось. Для меня как эльфы про магию. А меня вот что огорчило в Эльбрусе: не то что он медленее древних интелов, и не цена. А вот дайте свежие libc gcc qt и ядро линукса!. Мне вот все равно что там внутри за магия.
ZaitsXL
07.09.2021 10:01По итогу все равно получилась перепалка, да ещё и на очень странную тему сравнения массовых коммерчески доступных процессоров с тем, что существует только в бенчмарках, документах и может быть где то в госзаказах.
Но стратегия всего этого вполне понятна: в какой то момент отечественные процы станут единственно доступными, и вот тогда народу придется заняться портированием и изучением чудного ассемблера и забыть про сравнение с х86
Gryphon88
07.09.2021 11:00Поясните дилетанту: VLIW
делает вжух выдаётвысокий IPC, если хорошо отработал компилятор: полностью заполнил команду и предсказал обращение к памяти. Такие вопросы:Насколько это реально при разработке софта, если его писать под Эльбрус? Решается ли проблема деньгами, или там куча вещей, который даже теоретически неразрешимы?
Помечтаю: допустим, в МЦСТ признали, что запуск имеющегося софта на Эльбрусах невозможен с заявленной эффективностью, сделали язык, который лучше ложится на архитектуру, и транслятор из С и плюсов в этот язык со статическим анализатором aka рекомендательной системой для ручного допиливания. Такое в хоть теории реально? Какой выигрыш в производительности относительно х86/ARM должен быть, чтобы гиганты озаботились допиливанием софта под новую инфраструктуру?
Armmaster Автор
07.09.2021 15:30+1В общем случае это теоретически неразрешимо. Для определённого класса задач - возможно (т.е. микроархитектурная скорость на них будет стремиться к ОоО процессорам, разница будет минимальной). Но класс таких задач очень узкий.
Давайте я просто скажу, что это всё нереально на практике. Ну т.е. в теории можно говорить о том, что хорошо бы иметь какой-то супер-пупер язык, в котором будет параллельность заложена на уровне каких-то концепций. Но это золотой Грааль индустрии на протяжении десятилетий, а воз и ныне там. Ну и под такие языки уже понятно, какие архитектуры можно создавать. Там есть подходы, куда более перспективные, чем современный Эльбрус.
Gryphon88
07.09.2021 15:48Спасибо. Я сосредоточенно пытаюсь понять, сколько правды было в презентациях, начиная с Бабаяна, и правда ли надо закапывать стюардессу (как будто это от меня зависит).
Насколько много задач, в которых VLIW быстрее ОоО, как когда-то обещалось? Грубо говоря, имеет ли смысл строить суперкомпьютеры-числомолотилки на Эльбрусах или ставить VLIW-сопроцессоры, как Интел ставил FPGA.
Жаль, я думал, что Erlang, Oz и Lucid сделали достотаточно много шагов в сторону "параллельного программирования без боли".
Armmaster Автор
07.09.2021 16:16VLIW теоретически не может обогнать OoO, только к нему приблизиться ( ну вернее я могу написать синтетику, где это не так, но если мы говорим именно о реальном коде и классах задач - это именно так). Здесь речь может идти только о том, насколько он отстаёт. В хороших случаях, где по факту работа ОоО не нужна, а компилятор всё смог статически разрешить, мы можем говорить о том, что машинерия ОоО нам не нужна и её можно выбросить, чтобы она не жрала мощность. Ну т.е. где-то в таком разрезе можно искать ниши для VLIW. Но это точно не GP CPU вцелом.
К сожалению, это не так.
Gryphon88
07.09.2021 16:34Т.е. конкуренция была изначально для равной частоты не про выигрыш по OPs, а по энергоэффективности и площади кристалла?
Armmaster Автор
08.09.2021 03:12Ну сложно сказать что там считали изначально. Видимо, были разные мнения. По-крайней мере сам Бабаян когда двигал концепцию Эльбруса в 90-х говорил именно о большей производительности, т.е. о лучших OPs в вашей терминологии.
Arioch
08.09.2021 12:59А есть ли тут противопоставление? Если вы в какой-то момент ограничены энергоэффективностью и площадью - то как раз выигрыш в них приводит к выигрышу по OPs. Можно добавить блоков-исполнителей, можно добавить кэша, можно поднять частоту в пределах "теплового конверта", можно просто поставить 2-3-4 процессора, и т.д.
В общем-то RISC vs CISC изначально как раз был об этом. Давайте выкинем из процессора "умные" вещи, а освободившееся "место" займём усилением "числодробилки". VLIW в части "машинерия ОоО нам не нужна" - это в каком-то смысле продолжить эту тенденцию. Но оказалось (для "обычных" задач), что в данном случае это уже слишком много экономии, золотую середину перепрыгнули.
creker
08.09.2021 03:032. Сделали, но это все очень далеко от споров про VLIW. В конечном итоге, каждая корутина это обычный поток выполнения с обычными же инструкциями. А в случае erlang там будет тупо C рантайм, который незамысловато реализует кооперативную многозадачность. В этом плане мы возвращаемся к тому же, о чем в статье речь — имеется самый обычный код и OoO процессоры его всегда будут выполнять лучше. Сложно представить, где тут от VLIW будет польза.
japplegame
07.09.2021 15:03+1Трудоёмкость разработки под архитектуру Эльбрус, ввиду высокой сложности ассемблера широкой команды и необходимости постоянно проводить анализ кода и его изменение для достижения приемлемых цифр производительности (в Эльбрусе без этого никак, т.к. здесь если компилятор не справился, то аппаратура не подстрахует. А не справляться компилятор будет постоянно по вполне объективным причинам)
Мне не совсем понятно. Вы хотите сказать, что аппаратура успешно оптимизирует код, а компилятор тот же самый код соптимизировать не в состоянии?
В итоге, микроархитектурная скорость исполнения данного кода на x86 превышает Эльбрус в 13/3 = 4.33 раза. Т.е. во столько бы раз проиграл Эльбрус, будь он по частоте сопоставим с топовыми RISC/CISC системами.
Опять не совсем понятно. Я конечно не специалист в этой области, но насколько мне известно код x86 в современных микропроцессорах декодируется в некоторый внутренний микрокод, который затем оптимизируется и выполняется.
В Эльбрусе же такого не происходит и VLIW-команда сама по себе является аналогом такого вот внутреннего микрокода.
Но тогда ваше сравнение получается некорректным.
Поправте, пожалуйста, если я ошибся.Armmaster Автор
07.09.2021 15:07Мне не совсем понятно. Вы хотите сказать, что аппаратура успешно оптимизирует код, а компилятор тот же самый код соптимизировать не в состоянии?
Да
Опять не совсем понятно. Я конечно не специалист в этой области, но насколько мне известно код x86 в современных микропроцессорах декодируется в некоторый внутренний микрокод, который затем оптимизируется и выполняется
Само по себе не так важно, в какой микрокод и как что-то оттранслировалось. Важно по итогу с какой скоростью мы этот код исполняем. Здесь приведено сравнение, что одну итерацию цикла на Эльбрусе мы исполняем 13 тактов, а на x86 только 3. Т.е. по итогу время исполнения всей задачи будет отличаться на 13/3 = 4.33 раза при условии, что частота Эльбруса будет равна частоте x86. Т.е. таким образом мы рассчитываем микроархитектурную скорость каждого процессора.
japplegame
07.09.2021 16:46Да
Звучит примерно как: аппаратура успешно декодирует видео, а совтферно это сделать нереально. Неужели аппартные оптимизации сделать проще, чем аналогичные компиляторные?
Само по себе не так важно, в какой микрокод и как что-то оттранслировалось. Важно по итогу с какой скоростью мы этот код исполняем. Здесь приведено сравнение, что одну итерацию цикла на Эльбрусе мы исполняем 13 тактов, а на x86 только 3. Т.е. по итогу время исполнения всей задачи будет отличаться на 13/3 = 4.33 раза при условии, что частота Эльбруса будет равна частоте x86. Т.е. таким образом мы рассчитываем микроархитектурную скорость каждого процессора.
Хорошо. Но тогда получается, что вы пытаетесь сравнивать принципиальные характеристики архитектур сравнивая конкретных представителей этих архитектур и возможности конкретных компиляторов.
Ваше утверждение доказывает, что обсуждаемый Эльбрус медленее Core I5, но не доказывает, что VLIW процессоры принципиально медленнее OoO процессоров.cepera_ang
07.09.2021 17:20+1Неужели аппартные оптимизации сделать проще, чем аналогичные компиляторные?
У процессора есть куча рантайм информации, которой нет у компилятора.
goldrobot
07.09.2021 19:05А можно какие-то примеры на конкретном алгоритме/задаче? Мол вот считаем то то то, и вот тут процессор на основе такой то информации, которая берется отседова, может сделать круто.
Не спора ради, я вам верю, но пока неполучается в голове конкретнее представить.
Armmaster Автор
07.09.2021 23:51+1Самое простое - это проблема перестановки обращений в память. Представьте, у вас есть 2 указателя, которые пришли откуда-то сверху. По одному вы делаете store, а потом по второму load. В общем случае, эти обращения в память могут пересекаться и компилятор их не может переставить. В рантайме же процессор сразу вычисляет адреса (чтобы эти обращения в память физически выполнить) и просто проверяет, пересекаются ли они или нет. Если нет, то просто load пооднимает выше store и никаких проблем.
Armmaster Автор
07.09.2021 17:24Неужели аппартные оптимизации сделать проще, чем аналогичные компиляторные?
Зачастую да
Хорошо. Но тогда получается, что вы пытаетесь сравнивать принципиальные характеристики архитектур сравнивая конкретных представителей этих архитектур и возможности конкретных компиляторов.
А вы как себе представляете обобщенное сравнение? Естественно, идёт демострация на конкретных примерах. А обобщение основано на том, что в нише GP CPU все VLIW процессоры по итогу умерли. Описанные здесь проблемы достаточно общие для них всех, хотя есть, конечно же, нюансы.
antag
07.09.2021 16:28+5/Выставил в качестве компилятора e2k lcc 1.26.04, опции оптимизации -O4.
Там лучше было выбрать не -O4, а обычный -O2. И количество тактов в цикле сокращается примерно в 2 раза.
Armmaster Автор
07.09.2021 17:30-2Ха-ха, и ведь правда)
Ну согласитесь, ситуация, когда для получения самого лучшего результата надо вместо -O4 поставить -O2, это достаточно странно. Понятно, что об этом догадаться невозможно. Уж скорее я бы подумал подать какие-то доп опции. Проще всего прагмой цикл подсветить, наверное.
Это кстати, хорошо демонстрирует проблемы компилятора. Ну и все рассказы про супер-пупер эвристики про инлайн и горячие функции - тоже.
antag
07.09.2021 17:44+5А еще это доказывает, что все еще есть значительный потенциал улучшения производительности Эльбруса за счет компилятора.
Если компилятор сейчас плохой, то после его исправления реальная производительность Эльбруса улучшится и в реальных нагрузках, и во всяких тестах типа того же SPEC2017.
Armmaster Автор
07.09.2021 18:00Нет, это не так. На Spec2017 у Эльбруса таких проблем нет (вернее, цифры, которые Алексей привёл, они получены для ситуации, когда все такого рода проблемы решены). Потому что именно на Spec2006/2017 всё и вылизывалось. Именно поэтому я привёл сравнения микроархитектурной скорости и на спеках, потому что это близко к теоретическому максимуму Эльбруса (и про это вообще много в статье написано).
А данный пример просто показывает, что будет происходить на реальных задачах пользователей, на которые эвристики, подстроенные под Spec'и, не заточены.
antag
07.09.2021 18:35+6Не думаю, что они хорошо работают с кодом SPEC, если они прокололись даже на таком простом коде.
Делаем простой эксперимент. Выносим один главный внутренний цикл в отдельную функцию, и в итоге одна итерация там исполняется за 2 такта:
while(p >= 0 && a[p] > t) { a[p + 1] = a[p]; a[p] = t; p--; }.L19: { loop_mode ldw,3,sm %dr0, %db[3], %b[0] cmplesb,4,sm %b[4], %r1, %pred0 subd,5,sm %db[3], 0x4, %db[1] } { loop_mode alc alcf=1, alct=1 abn abnf=1, abnt=1 abp abpf=1, abpt=1 ct %ctpr1 ? ~%pred1 && %NOT_LOOP_END staaw,2 %b[6], %aad0[ %aasti1 + _f32s,_lts0 0x4 ] ? ~%pred1 staaw,5 %r1, %aad0[ %aasti1 ] ? ~%pred1 incr,5 %aaincr1 }Можно сделать вывод, что компилятор не умеет хорошо оптимизировать вложенные циклы. Или он ожидает, что вложенный цикл будет коротким.
В итоге можно получить ускорение в 6.5 раза от первоначального варианта: 13 тактов / 2 такта = 6.5.
Armmaster Автор
07.09.2021 18:45Ну я не думаю, я знаю. В МЦСТ анализом спеков по факту отдельные люди специально занимались и занимаются. Это их работа. Вся отчётность по улучшению компилятора она на Spec'и ориентирована.
А вот что происходит при попадании в реальный мир - мы видим. Собственно, мои тезисы про сложность оптимизации про Эльбрус - они про это. Придётся потом на простейших примерах сидеть и смотреть, что компилятор там наделал.
Но в качестве некоторого предела по архитектурной скорости - Spec'и дают хороший ориентир. Сильно лучше там не будет.
И согласитесь, если компилятор пилили 20+ лет, а он в таких примерах лажает - наверное, это неспроста. Наверное , есть объективные проблемы.
antag
07.09.2021 19:08+5Вот мы получили три разных реальных результата для одного и того же кода на Эльбрусе:
13 тактов для -O4
7 тактов для -O2
2 такта, если просто вынести главный цикл в отдельную функцию.
Такой же разброс возможен и на реальном коде, и на коде SPEC.
Но минимальный результат в 2 такта оказался в 1.5 раза лучше вашего x86, который ~3 такта. И этот результат на Эльбрусе можно получить. Хотя неизвестно, что там будет, когда закончится кэш. Без подкачки будет плохо.
Поэтому основные выводы в статье можно пересмотреть. Потенциал VLIW Эльбруса на таком коде достаточно хороший. Компилятор подкачал.
shcher
07.09.2021 19:54+5Не могу не заметить, что разговор о производительности на примере сортировки вставками всё ещё оторван от реальности: если это будет узкое место, то, наверное, начать стоит с выбора другого алгоритма. Но раз уж заговорили о нём, то предлагаю не останавливаться на достигнутом.
Очень похоже, что Вы правильно определили, что "компилятор ожидает, что вложенный цикл будет коротким". Это ошибка с его стороны, которая лечится достаточно просто, хоть и затрагивает мелкую модификацию исходника: перед циклом while следует добавить
#pragma loop count(1000).Дальше можно заметить, что в программе все обращения в память соблюдают выравнивание. В этом случае следует добавить опцию компиляции -ffast (да, для Эльбруса это такой же важный шаг, как просто компиляция с включением оптимизаций). Посмотрим на результат:
.L38: { loop_mode alc alcf=1, alct=1 abn abnf=1, abnt=1 abp abpf=1, abpt=1 ct %ctpr1 ? ~%pred3 && %NOT_LOOP_END staaw,2 %b[16], %aad1[ %aasti2 + _f32s,_lts0 0x4 ] ? ~%pred3 cmplesb,4,sm %b[10], %r2, %pred0 staaw,5 %r2, %aad1[ %aasti2 ] ? ~%pred3 incr,5 %aaincr2 movaw,1 area=0, ind=0, am=1, be=0, %b[0] }В итоге вышел всего лишь один такт и даже успешно сработал механизм подкачки данных. Кстати, @alexanius давал в своей статье ссылки на ситуации, когда показано "микроархитектурное превосходство" Эльбруса, но в этой статье такая информация была проигнорирована.
antag
07.09.2021 20:16+2В итоге вышел всего лишь один такт и даже успешно сработал механизм подкачки данных.
Хорошо бы проверить исполнение на реальном железе Эльбруса с разными размерами массива.
Ожидаю два потенциальных подвоха:
1) как работает подкачка за пределами границ кэша 64 KB, 512 KB, и 16 MB для Эльбрус-8C.
2) потенциальный конфликт между операциями чтения и записи. Они же читают и записывают одни и те же области (строки кэша) одновременно. A значит буферы подкачки, кэш L1 и кэш L2 должны работать синхронно, и разрешать все возможные конфликты. Хотя кэш L1 тут вообще не будет работать в этом варианте с одним тактом?
Если по результатам реального исполнения там действительно будет один такт на итерацию, тогда признаем полную победу Эльбруса.
Кстати внутри цикла есть одна лишняя операция записи, которую можно вынести за пределы цикла в исходном коде. Но она особо не мешает. Пусть будет.
shcher
07.09.2021 23:07+8Согласен, без проверки никуда. Поэтому берём машины на базе Эльбрус-8С @ 1.2 ГГц с 1 и 4 процессорами (дальше уточнять не буду, но результат не отличается существенно). Позволю себе для начала полениться и замерить только на массиве из 100000 элементов, как предложено в статье (это около 390 КБ). Это будет полностью честный замер скорости работы предложенной функции сортировки.
Исходный код для замера, реализация Sort по ссылке выше
#include<stdlib.h> #include<stdio.h> #include <sys/time.h> #define ARRAY_SIZE 1000000 void fill(int*a) { for(int i=0;i<ARRAY_SIZE;i++) { a[i]=ARRAY_SIZE - i; } } void Sort(int*a); void print_array(int*a, int n) { printf("%d \n",a[n]); } int main() { int n; scanf("%d", &n); int*array=(int*)malloc(ARRAY_SIZE*sizeof(int)); fill(array); struct timeval start, end; gettimeofday(&start, NULL); Sort(array); gettimeofday(&end, NULL); double time = (double)(end.tv_usec - start.tv_usec) / 1000000 + (double)(end.tv_sec - start.tv_sec); printf("\t%3.6f s\n", time); print_array(array, n); return 0; }Массив заполнен в порядке убывания элементов, значит, количество внутренних итераций будет порядка 100000 * 100000 \ 2. Прогон занимает 4.214 с. Итого получается 4.214 * 1200000000 / 100000 / 50000 = 1.0136 — тот самый один такт.
Чтобы дождаться квадратичной сортировки при большем размере массива, нужно много терпения, так что упрощаем тест. Удаляем внешний цикл, массив заполняем по возрастанию, в конце ставим один минимальный элемент (будем вставлять его на правильную позицию внутренним циклом while). Ставим количество элементов 200000000 (760 МБ) и запускаем. Отрабатывает за 0.214 с, то есть 1.284 такта на одну итерацию.
Для пытливых читателей пересчитаем показатель IPC: не меньше 7 полезных инструкций на один такт.
А точно все полезны?
alc — продвинуть счётчик цикла
ct — передача управления, здесь же скрыта ещё одна булева операция (&&)
staaw — 2 записи значений в память
movaw — пересылка значения из буфера APB в регистр
cmplesb — сравнение
Насчёт остальных надо думать:
abn и abp — продвинуть базу вращения числовых и предикатных регистров, соответственно — позволяет наслаивать итерации друг на друга
И ещё скрыты инструкции работы с APB, обеспечивающие подкачку данных.
edo1h
08.09.2021 01:02+1код, отличается добавлением счётчика итераций
#include<stdlib.h> #include<stdio.h> #include <time.h> #define ARRAY_SIZE 100000 void fill_random(int *a) { for (int i = 0; i < ARRAY_SIZE; i++) { // a[i]=rand(); a[i] = ARRAY_SIZE - i; } } long long Sort(int *a) { int t, // временная переменная для хранения значения элемента сортируемого массива p; // индекс предыдущего элемента long long loops = 0; for (int c = 1; c < ARRAY_SIZE; c++) { t = a[c]; // инициализируем временную переменную текущим значением элемента массива p = c - 1; // запоминаем индекс предыдущего элемента массива while (p >= 0 && a[p] > t) // пока индекс не равен 0 и предыдущий элемент массива больше текущего { a[p + 1] = a[p]; // перестановка элементов массива a[p] = t; p--; loops++; } } return loops; } int main() { int *array = (int *) malloc(ARRAY_SIZE * sizeof(int)); fill_random(array); struct timespec t1, t2; clock_gettime(CLOCK_MONOTONIC, &t1); long long loops = Sort(array); clock_gettime(CLOCK_MONOTONIC, &t2); long long diff = (t2.tv_sec - t1.tv_sec) * 1000000000LL + t2.tv_nsec - t1.tv_nsec; printf("time diff: %lld, loops: %lld, ns per loop: %f\n", diff, loops, (float) diff / loops); return 0; }
byman
09.09.2021 12:58сделал так же, как ни странно, в сравнении с рандомным массивом скорость на amd заметно выросла, на intel такого эффекта нет.
может из-за предсказателя? когда только в одну сторону , то предсказателю проще, а как случайно, то порой и не угадаешь.
edo1h
08.09.2021 02:42+3Чтобы дождаться квадратичной сортировки при большем размере массива, нужно много терпения, так что упрощаем тест. Удаляем внешний цикл, массив заполняем по возрастанию, в конце ставим один минимальный элемент (будем вставлять его на правильную позицию внутренним циклом while). Ставим количество элементов 200000000 (760 МБ) и запускаем. Отрабатывает за 0.214 с, то есть 1.284 такта на одну итерацию.
не можете привести получившийся код? чтобы можно было запустить его на x86 и быть уверенным, что сравниваем апельсины с апельсинами.
shcher
13.09.2021 19:34Без проблем. Функцию (не)сортировки я уже привёл ссылкой на Compiler Explorer (проверив, что внутренний цикл остался без изменений после того, как исчез внешний). Соответственно, при сравнении с x86 придётся тоже проверить, что внутренний цикл сохраняется в неизменном виде.
А вот так замерял:
#include<stdlib.h> #include<stdio.h> #include <sys/time.h> #define ARRAY_SIZE 200000000 void fill(int*a) { for(int i=0;i<ARRAY_SIZE;i++) { a[i] = i + 1; } a[ARRAY_SIZE - 1] = 0; } void Sort(int*a); void NotSort(int*a); void print_array(int*a, int n) { printf("%d \n",a[n]); } int main() { int n; scanf("%d", &n); int*array=(int*)malloc(ARRAY_SIZE*sizeof(int)); fill(array); struct timeval start, end; gettimeofday(&start, NULL); NotSort(array); gettimeofday(&end, NULL); double time = (double)(end.tv_usec - start.tv_usec) / 1000000 + (double)(end.tv_sec - start.tv_sec); printf("\t%3.6f s\n", time); print_array(array, n); return 0; }
antag
08.09.2021 12:59Удаляем внешний цикл, массив заполняем по возрастанию, в конце ставим один минимальный элемент (будем вставлять его на правильную позицию внутренним циклом while). Ставим количество элементов 200000000 (760 МБ) и запускаем. Отрабатывает за 0.214 с, то есть 1.284 такта на одну итерацию.
А эта потеря скорости происходит только после 16 MB из-за медленной памяти?
Получается примерно 4 ГБ/c на чтение и 4 ГБ/c на запись. Но в буферы подкачки нужно читать заранее, чтобы побороть большую латентность памяти, которая примерно 100 нс, а это примерно 120 слов (или 480 байт) в том коде.
Чтобы лучше проверить пиковую скорость буфера префетча у Эльбруса, можно заменить там 32-битные числа на 64-битные, чтобы память нагружалась в два раза быстрее. И проверить ту функцию для разных размеров массива: до 16 MB и после.
Фактически этот код измеряет скорость сдвига memmove() массива на 4 или 8 байт, но с дополнительной проверкой значений элементов массива, которая никогда не срабатывает. В случае реального массива проверка сработает тоже только через много итераций.
byman
09.09.2021 12:56Массив заполнен в порядке убывания элементов
а на случайном наборе из 100000 какой результат?
Armmaster Автор
08.09.2021 00:22+1Реальность для Эльбруса наступит тогда, когда на нём сборка AOSP начнётся. Что там будет по перфу мне даже представить страшно.
А сейчас, чтобы простейшую сортировку, надо исходники править
Это ошибка с его стороны, которая лечится достаточно просто, хоть и затрагивает мелкую модификацию исходника
Ну вот и началось - без правки исходников никуда
Кстати, @alexanius давал в своей статье ссылки на ситуации, когда показано "микроархитектурное превосходство" Эльбруса, но в этой статье такая информация была проигнорирована.
Серьёзно? И где же там такое показано?
shcher
08.09.2021 01:18+4Как стакан наполовину пуст и полон одновременно, так же и в этих обсуждениях нет чёткой истины. Нет, править исходники в общем случае не нужно. Да, если нужно здесь и сейчас быстро — можно дописать pragma. Да, это ошибка в компиляторе. Досадно, что она есть. Информация о ней уже доведена до МЦСТ, в новых версиях проблему обещают исправить и нам править ничего не придётся.
Я понимаю, что Вы взяли первый попавшийся код специально, чтобы продемонстрировать проблемы. Но, на мой взгляд, этот пример всё ещё не несёт никакой прикладной ценности — я запускал сортировку 100000 элементов (всего лишь 390 КБ) на Эльбрус-8С и i7-9700K. Итоговая разница времени выполнения у них 2 раза. При этом выполнение 2-4 секунды является безобразно долгим что на одном, что на другом. Если в этом месте в программе проблема, то править исходники нужно в любом случае — переписыванием алгоритма сортировки на более быстрый. Так что этот пример показывает, какой код не надо писать в реальных программах и какие проблемы могут быть у компилятора. Но он никак не показывает того, что Вы заявляете (якобы отставание в микроархитектурной скорости). Кстати, сейчас при обучении программированию всё чаще используются методы "стимулирования к написанию хорошего кода", например, системы ejudge с контролем времени выполнения. Не уложился в 1 секунду из-за медленного алгоритма или его плохой реализации (даже на x86) — получи
линейкой по пальцамштраф на несколько баллов и оценку ниже. Вряд ли неоптимальные алгоритмы или реализации можно считать нормальным явлением в местах, где реально требуется производительность :)Вообще, вся эта ветка комментариев началась с опровержения тезиса о плохой "микроархитектуре". Согласитесь, в данном контексте он опровергнут. Да, к компилятору оказалось много вопросов и претензий, но не к "микроархитектуре".
Серьёзно? И где же там такое показано?
Там дана ссылка на мою статью, в которой рассказано об эффективности реализаций ГОСТ алгоритмов симметричного шифрования на Эльбрусе. Да, речь идёт о конкретной задаче, но пока все разговоры идут только на примерах конкретных задач.
Armmaster Автор
08.09.2021 01:53+1Я понимаю, что Вы взяли первый попавшийся код специально, чтобы продемонстрировать проблемы
Я его взял, потому что он крайне показателен.
Вообще, вся эта ветка комментариев началась с опровержения тезиса о плохой "микроархитектуре". Согласитесь, в данном контексте он опровергнут
Уж извините, но вся данная ветка для меня как раз доказывает, насколько мой тезис верен. Но честно говоря, я уже настолько утомился доказывать достаточно очевидные на мой взгляд вещи, что пусть каждый делает дальнейшие выводы сам. В конце концов, сделать правильные выводы из статей куда важнее МЦСТ, чем мне. Лично для меня это в общем-то чисто академические споры.
Там дана ссылка на мою статью, в которой рассказано об эффективности реализаций ГОСТ алгоритмов симметричного шифрования на Эльбрусе
Вы взяли, и руками наоптимизировали какой-то код под e2k. Какой в итоге - непонятно. Что получилось в ассемблере в итоге - непонятно. Что пускалось на x86 - непонятно. И предлагаете, чтобы я на это ссылался. Причём в вашей же статье есть ссылка на куда более печальные для Эльбруса результаты на том же алгоритме, где он на ядро Комдиву проиграл в 2 раза.
Просто я подозреваю, что на том же x86 если пооптимизировать, можно также существенно результаты увеличить. Так что ваша претензия не принимается.
Я уже выше написал - есть достаточно фундаментальные вещи, определяющие производительность. В пределе они будут стремиться к количеству АЛУ юнитов. Главная проблема Эльбруса в этом треде как раз и продемонстрирована - без серьёзной оптмизации он не может приблизиться к своим максимальным цифрам, в то время как RISC с ОоО делает это намного лучше, что мы и видим. Для архитектуры, внедряемой в масштабах всей страны - это приговор.
shcher
08.09.2021 02:11+5Вы взяли, и руками наоптимизировали какой-то код под e2k. Какой в итоге - непонятно. Что получилось в ассемблере в итоге - непонятно. Что пускалось на x86 - непонятно.
Понимаю Ваш обоснованный скептицизм. К сожалению, нужно быть достаточно глубоко в теме, чтобы в деталях понимать, о каких именно реализациях идёт речь в статье. В статье есть ссылки на материалы, по которым можно со всем разобраться и даже повторить результаты, но это требует больших затрат времени и сил.
Ассемблер и, тем более, исходники у нас в России никто не показывает. Можно сказать, специфика разработки СКЗИ. Но вкратце могу рассказать следующее: под x86 используются написанные руками ассемблерные реализации, зарекомендовавшие себя как самые быстрые. Они превосходят выдаваемое компиляторами где-то на 10% (это к тому, что дальше пооптимизировать вряд ли получится). Под e2k я реализовал то же самое на Си с использованием интринсиков и получил отличный результат. Пробовал на ассемблере писать, но тут я отставал от компилятора. Я считаю, что это вполне корректное сравнение уровня микроархитектуры: что в одном, что в другом случае мы берём вручную оптимизированные реализации.
Armmaster Автор
08.09.2021 02:25-1Понимаю Ваш обоснованный скептицизм
Ну вот видите. О чём тогда спорить
Я считаю, что это вполне корректное сравнение уровня микроархитектуры
Нет, это не так. Микроархитектура это намного большее, чем вручную наоптимизированные реализации. Тем более, в случае вашего алгоритма есть очень много "но", которые мне просто не хочется даже поднимать в онлайне.
В первом приближении что-то об микроархитектуре может сказать SpecCPU2017, по-крайне мере, вас поймут. Алексей из МЦСТ именно поэтому на SpecCPU2017 упор и делал. Хотя и в случае Эльбруса SpecCPU2017 тоже несколько обманчив.
Civil
08.09.2021 11:28+1Ассемблер и, тем более, исходники у нас в России никто не показывает.
Когда пишешь статью об оптимизации и сравнении и не показываешь исходники - сводит на нет полезность статьи и по сути статья ничем не отличается от фразы "мы что-то потестировали и что-то получили".
shcher
08.09.2021 11:41-1Ознакомьтесь, пожалуйста, с научными работами, ссылки на которые приведены в статье. Нигде в них нет исходного кода, но есть описание алгоритма, достаточное для понимания. Школьник повторить не сможет, но всем заинтересованным это не мешает воспроизводить результаты и использовать идеи.
Civil
08.09.2021 11:54-1Не надо пенять на научные работы плохого качества. То что в России в целом отсутствует культура написания научных работ (и публикаций результатов изысканий) не значит что это нормальная практика и так надо делать.
Простите, но звучит как очень слабое оправдание. Так что я продолжу настаивать что либо не пишите статью, либо выкладывайте нормально результаты.
edo1h
08.09.2021 03:37+4Я его взял, потому что он крайне показателен.
честно говоря, я не понял, что он показал в итоге )
ну да, компилятор под эльбрус сыроват, но уже то, что оптимальный код существует (и даже оптимальнее, похоже, в пересчёте на такт, чем для x86) — это уже говорит, что этот пример не подходит для иллюстрации плохой производительности на такт эльбруса.
Armmaster Автор
08.09.2021 04:05Он показал, что даже на простейшем коде без игр с компилятором и правки исходников мы не можем получить нормальный перформанс.
Данный пример хорошо иллюстрирует то, что будет происходить в реальности, а не на красивых презентациях от МЦСТ.
edo1h
08.09.2021 10:38+2ну игры с компилятором тут не выглядят какими-то запредельными. так, небольшие игрочки )))
если серьёзнее, именно на этом примере вполне верится, что компилятор могут быстро пофиксить.
Armmaster Автор
08.09.2021 11:25+4ну игры с компилятором тут не выглядят какими-то запредельными. так, небольшие игрочки )))
Ну да. А теперь представьте то же самое на коде сложных приложений и на триллионах строк из реальной жизни.
если серьёзнее, именно на этом примере вполне верится, что компилятор могут быстро пофиксить
Ну т.е. на компиляторе, который разрабатывался 20+ лет и в который вложено сотни человеко-лет разработки, приходится фиксить случай простейшей сортировки? Нет подозрения, что здесь есть подвох?
Там не проблема пофиксить, если знать, что этот цикл самый горячий. А это неизвестно без профиля или подсказки. Проблема в том, что такого рода оптимизация может легко дать серьёзную деградацию, если, например, внутренний цикл имеет обратную дугу с вероятностью 0.5, например. Отсюда основная проблема в данном случае. Этот пример был ответом на рассказы, что "в реальном коде всё довольно неплохо".
Можно дальше приводить примеры, где всё плохо будет даже с тряской опций и ручными оптимизациями. Но для этого нужен уже доступ к машине, чтобы результаты нормально чекать, а не игрушки вроде годболта. И главное, зачем, если на простейших случаях такие проблемы.
edo1h
08.09.2021 11:36Там не проблема пофиксить, если знать, что этот цикл самый горячий. А это неизвестно без профиля или подсказки. Проблема в том, что такого рода оптимизация может легко дать серьёзную деградацию, если, например, внутренний цикл имеет обратную дугу с вероятностью 0.5, например
вы именно про этот случай или вообще? если про этот — хотелось бы деталей, как так может получиться.
Но для этого нужен уже доступ к машине, чтобы результаты нормально чекать, а не игрушки вроде годболта
ЕМНИП доступ по ssh получить не проблема.
всё-таки, я считаю, что невозможность качественной кодогенерации под vliw в случае использования «обычного» кода — это принципиальный момент.
если это действительно так, то эльбрус надо закапывать, если всё-таки не так — пусть живёт )
Armmaster Автор
08.09.2021 12:10+1вы именно про этот случай или вообще?
вообще, это же принципиальная проблема. такая оптимизация внутрененнего цикла небесплатна - она стоит многих тактов подготовки, которые вы можете лицезреть на приведенном примере
если про этот — хотелось бы деталей, как так может получиться
Конкретно в этом случае у вас итерация внешнего цикла начинает работать 30+ тактов. Это цена, которую вы заплатили за оптимизацию внутреннего цикла. Ну а теперь представьте, что мы во внутреннем цикле почти не крутимся, а в реальности работаем почти всегда во внешнем.
ЕМНИП доступ по ssh получить не проблема.
нет, это проблема. да и как я уже написал выше, столько времени я тратить не готов уже. По-моему, я привёл более чем убедительные аргументы. если кого-то они не устраивают или хочется в чём-то доразбираться - пожалуйста, получайте доступ и разбирайтесь
всё-таки, я считаю, что невозможность качественной кодогенерации под vliw в случае использования «обычного» кода — это принципиальный момент.
Совершенно с вами согласен. Об этом и статья.
если это действительно так, то эльбрус надо закапывать, если всё-таки не так — пусть живёт )
в теории можно попытаться найти какую-то нишу, например, для HPC кластеров, где мы будем плавучку долбить и там в общем потратить время на оптимизацию кода в целом обычный подход. Но люди должны понимать, на что они идут. Потому что не все HPC на Эльбрус хорошо лягут, всё равно
edo1h
08.09.2021 16:01Конкретно в этом случае у вас итерация внешнего цикла начинает работать 30+ тактов. Это цена, которую вы заплатили за оптимизацию внутреннего цикла. Ну а теперь представьте, что мы во внутреннем цикле почти не крутимся, а в реальности работаем почти всегда во внешнем.
ИМХО это чуть ли не самый важный момент во всём обсуждении, а он спрятан где-то в глубюине комментариев.
то есть проблема, если я вас правильно понял, была не в том, что оптимизатор плохо оптимизировал, а в том, что он не так оптимизировал (исходил из неверных предположений о профиле исполнения кода), а цена ошибки гораздо больше, чем у x86.
мне, как человеку далёкому от эльбрусов, это совершенно неочевидно.
Armmaster Автор
08.09.2021 16:39Конечно же - он не знает профиля (да даже если знает, там есть другие проблемы, но Бог с ними). Поэтому он не знает, как ему лучше соптимизировать и получается то, что мы видим. А аппаратура тут не подстрахует.
Мне казалось, я это достаточно подробно в обеих статьях объяснял. Видимо, не достаточно хорошо получилось.
JerleShannara
08.09.2021 05:01+4Реальность такова, что пока у нас есть куча кода написанного по принципу «покопал стековерфлоу и слегка наговнокодил всё ура проект готов» с перлами типа «if (strlen(booleanvalue)>4)» c кучей абстракций от железа и т.д., включая всякий JIT, производительности на VLIW можно не ждать, т.к. надо конкретно каждый пакет вылизывать и обхаживать с профилировщиком (что в этом случае делать с JS/Python и прочими я вообще слабо понимаю). При этом amd64/aarch64 позволяет говнокоду показывать хоть какую-то производительность без оптимизаций руками за счёт всяких плюшек типа спекулятивного выполнения и прочего. Как инженеру-алгоритмисту мне этот подход не нравится (в случе сферической программы в вакууме она должна быть вылизана и т.д. — ну чем не идеал для VLIW компилятора), но увы, «пока Петя делает идеальное крыло для самолёта и думает о новых лопатках турбины, Вася уже пролетает над ними на куске фанеры от стола, с табуретками и движком от ракеты, попутно собирая от заказчиков деньги на вторую версию леталды».
К примеру, если мне сейчас поставить ПК на базе топжыр Эльбруса, то он так и останется стоять в углу, т.к. нужный мне софт для работы на него точно не портировали и врядли портируют вообще, а запускать под СБК задачи, которым надо кучу памяти и кучу ядер, желательно ещё на высокой частоте работающих — это так себе, вариант пригодный только на случай, когда «за доллар будут давать по морде».
edo1h
08.09.2021 10:23+3Как инженеру-алгоритмисту мне этот подход не нравится (в случе сферической программы в вакууме она должна быть вылизана и т.д. — ну чем не идеал для VLIW компилятора)
а я наоборот с годами начал понимать, что из всех вариантов кода надо выбирать самый читаемый, а применение оптимизаций, усложняющих код, должно быть только там, где оно уместно.
Armmaster Автор
08.09.2021 00:062 такта (и даже меньше) получается и на современных x86, вон выше перемеряли. И под него тоже можно начать код переписывать, исходя уже из микроархитектуры конкретного проца.
Тут же всё просто фундаментально - есть количество вычислительных устройств, чем больше мы их используем, тем лучше. Если каким-то образом (потрясти опциями компилятора, переписать код и т.д.) сделать так, чтобы компилятор смог разобраться, разорвать нужные зависимости и применить необходимые оптимизации - то в пределе на Эльбрусе вы придёте к тому, что ОоО получает автоматом.
Поэтому если вы можете потрясти опциями и переписывать код - то получаете то, что в вашем примере
Если только первое (и заточить оптимизации) - цифры Spec2017
В реальной жизни, когда нет ни того, ни другого - получаете то, что я показал в статье.
shcher
08.09.2021 20:42+1Ну согласитесь, ситуация, когда для получения самого лучшего результата надо вместо -O4 поставить -O2, это достаточно странно. Понятно, что об этом догадаться невозможно.
Странная? Странная! Кто бы мог подумать, что то же самое происходит на x86. Встаёт вопрос, почему Вы в одном случае выбираете -O2, а в другом -O4, хотя для lcc заявляется примерно аналогичное gcc поведение для уровня -O2 и включение агрессивных платформо-зависимых оптимизаций с -O3. Честно говоря, я всё больше начинаю думать, что Вы проверили все эти комбинации, а в публикацию пустили наиболее выгодный для Вас вариант.
Dim0v
08.09.2021 22:39+1Автор комментария, на который вы ссылаетесь, либо вообще не имеет понятия, что он делает и что измеряет, либо очень умело притворяется. Не повторяйте его ошибок.
Не нужно быть экспертом, чтобы увидеть, что GCC выдает абсолютно одинаковый ассемблерный код сортировки и с -О2, и с -О3. Разница в измерениях объясняется тем простым фактом, что godbolt - это и близко не инструмент для проведения каких бы то ни было бенчмарков.
shcher
08.09.2021 23:10+1Спасибо, что обратили внимание! Действительно, не пригляделся достаточно внимательно, а там появились ещё и дополнительные инструкции для замера, замыливающие глаз. Вот и доверяй людям... Тогда беру назад все слова из предыдущего комментария.
Armmaster Автор
07.09.2021 18:31+4Я, кстати, не могу не отметить, что от Вас поступило 2 наиболее интересных дополнения к статье (про микроархитектурную скорость Kunpeng'ов и про компилирования с -O2) .
Если для вас актуально, напишите мне в личку, я пришлю приглашение на Хабр
nin-jin
08.09.2021 10:43-1Для меня как-то оба ассемблера малопонятны. Но если выучить ключевые слова, то скорее всего оба станут одинаково понятными. Что такого мы должны оценить на godbolt, можете пояснить?
Что означают 6 пар фигурных скобочек в ассемблере эльбруса? И как вы посчитали 13 тактов?
edo1h
08.09.2021 11:16послушайте, я в первый раз увидел ассемблер эльбруса, и ответы именно на эти вопросы мне кажутся очевидными: фигурные скобки используются для удобной записи широкой команды, всё внутри них — это одна команда, которая должна выполняться за один такт, команд 6, итого 6 тактов. однако, в некоторых из команд стоят nop'ы, на которых набегает ещё 7 тактов, думаю, это ожидание данных из памяти.
почему их так много и как получилось, что тот же компилятор с другим настройками генерирует рабочий код в котором на цикл приходится один такт — это уже надо разбираться.nin-jin
08.09.2021 11:27А мне вот как-то совсем не очевидно, что 3 нопа - это 7 тактов. Да и почему эти нопы находятся не в отдельных фигурных скобках, если представляют собой отдельный такт?
edo1h
08.09.2021 11:40А мне вот как-то совсем не очевидно, что 3 нопа — это 7 тактов
после каждого нопа есть число, означающее сколько тактов надо подождать.
Да и почему эти нопы находятся не в отдельных фигурных скобках?
думаю, дело в экономии места, vliw код и так достаточно «пухлый», что является проблемой. выгоднее прицепить этот nop к какой-то команде.
nin-jin
08.09.2021 11:44Тогда следующий вопрос: какой смысл начинать исполнение с двух нопов?
edo1h
08.09.2021 16:10выше было написано, не знаю, насколько это правда )
https://habr.com/ru/post/576420/#comment_23454006
rogoz
08.09.2021 14:28Я вот вижу много дискуссий о закладках и может чего не понимаю, они же все бессмысленны?
Кто производит чипы сетевого контролёра и прошивки к ним?
Кто производит чипы HDD/SSD и прошивки к ним?JerleShannara
08.09.2021 14:42Сетевой контроллер мы заменяем на ПЛИС, которая выполняет его функции. При этом из закладок гипотетически реальной остаётся только «выключит нафиг». Между вражеским диском и православной материнской платой мы включаем шифратор с правильными алгоритмами шифрования и опять остаётся только «сделается кирпич».
Потом смотрим на цену получившихся решений и понимаем, что эти решения пойдут только для военных дел и супер-параноиков типа Сноудена.
edo1h
08.09.2021 15:01я вообще не понимаю этих разговоров о закладках. да, для облачного хостера, который запускает сторонний код, уязвимости в железе вроде spectre могут быть опасны.
мне кажется, что для условной задачи обсчёта данных с радаров подразумевается, что компьютер не подключен к публичным сетям, на нём запускается только доверенное ПО. и т.д., и т.п.
как при таких вводных злоумышленник сможет в час X включить рубильник, запускающий закладки — ума не приложу.VlK
08.09.2021 15:26+1Ну, к примеру, ходят слухи, что ПВО можно выключить.
А еще в Иране "ломались" микроконтроллеры, использованные в важнейшей для них ядерной программе.
Да что там, одно сообщение на мобильный телефон может дать полный контроль над трубкой. Мало ли где этот мобильник потом окажется, вдруг, в полезном месте вроде кармана солдата на посту.
Intel так вообще прямо в чипсеты вшивает процессоры, работающие даже без питания.
Какая-нибудь гадость на компьютере программиста, перепрошивающего контроллер. Гадость по таймеру что-то делает... Мир полон дивных и удивительных вещей.
Или, как шутят, "если вы параноик, то это не значит, что за вами не следят".edo1h
08.09.2021 15:44про пво — да, не удивлюсь, если в dsp могут быть закладки.
ну так, надеюсь, именно эту часть мы используем свою.в случае ирана там был обычный вирус под windows, который удачно удалось внедрить.
разработчики эльбруса говорят о качественной эмуляции x86, так что стой тот сименсовский (или чей там это был?) софт управления на эльбрусе в режиме эмуляции x86, вирус точно так же запустился бы.
а вот то, что вирус смог добраться до машин, управляющих ключевой инфраструктурой — явное разгильдяйство.и, опять же, там была целенаправленная атака. собственная архитектура по большому счёту от этого не защищает (или вы думаете, что у американских военных до сих пор нет описания системы команд эльбруса, а то и рабочих экземпляров?)
«процессоры, работающие без питания» — очевидный бред.
да, me есть, но как вы собираетесь слать команды в случае изолированного контура — вопрос.мобильник у солдата — да, проблема. начать с того, что у него его вообще не должно быть, но чем дальше, тем нереальнее это выглядит.
только причём тут эльбрус?и т.д., и т.п.
VlK
08.09.2021 15:52«процессоры, работающие без питания» — очевидный бред.
у них могут быть отдельные батарейки. Ну и Intel ME вполне себе работает, например, во всяких там спящих режимах.
только причём тут эльбрус?
чем больше сделано дома, тем меньше возможности для таких вот странных ситуаций, когда что-то вырубается по скрытому таймеру
Хотя, конечно, полностью все сделать на базе сложно. Но хоть что-то (и довольно много).amartology
08.09.2021 16:02чем больше сделано дома, тем меньше возможности для таких вот странных ситуаций, когда что-то вырубается по скрытому таймеру
Неверно. Верно так: «пока вообще все не сделано дома, есть шанс для таких странных ситуаций»VlK
08.09.2021 16:56Одно дело с позиции безопасности - обычный Intel или Arm, совершенно другое - третья архитектура. Безопасники в таких случаях говорят про attack surface и стремятся ее, поверхность, уменьшить.
edo1h
08.09.2021 16:14Хотя, конечно, полностью все сделать на базе сложно. Но хоть что-то (и довольно много).
ну так я не спорю. только серверный процессор собственной архитектуры, который de facto мы не можем производить внутри страны, — явно очень трудоёмкий путь, при этом выхлоп в плане защиты от закладок для меня совершенно неочевиден; ИМХО от закладок нужно защищаться совсем по-другому (изолированные контуры, отказ от запуска недоверенного кода, и т.п.)
alexanius
08.09.2021 14:33+3Максим, добрый день.
Я всего лишь на одну вещь внимание обращу. Вы пишете:
Что мы видим? Одна итерация основного цикла занимает 13 тактов. В нём 9 семантически полезных инструкций (остальные – это специфика Эльбруса, не влияющая на реальное IPC). Т.е. IPC составляет 0.69 инструкций в такт. Эффективность использования широкой команды в данном случае очевидна – она крайне низкая. Никаких разрывов зависимостей не произошло, DAM не применился, но зато произошёл абсолютно бессмысленный инлайн функции Sort в функцию main.
Вот здесь Вам наглядно показали что на самом деле для Эльбруса IPC составляет 7 инструкций на такт, или 1.84 такта на итерацию. Это при сравнении с приведённым Вами интеловским IPC 2.67 и примерно 3 такта на итерацию.
Для того чтобы статья была более честной и объективной, считаю что необходимо сделать дополнение к данной статье с указанием этих цифр. Ведь мы же говорим о перспективности и микроархитектурной скорости, а тут сразу виден потенциал платформы.
С уважением, Маркин Алексей.
cepera_ang
08.09.2021 14:49Может тогда справедливости ради нужно было дать компилятору под x86 векторизовать цикл? А то один бежит в мешке и с барьерами, а другого на руках несут с горки :)
edo1h
08.09.2021 15:06+2векторизовать — использовать simd? можете привести пример кода?
мне пришлось отключить simd, тот код с simd, что генеририрует gcc100, работает в зависимости от процессора так же, или заметно медленнее «наивного».
Armmaster Автор
08.09.2021 15:08То-то и оно. Почему-то люди считают, что руками наоптимизировать цикл для Эльбруса это нормально, а для x86 gcc -O3 и пойдёт. Но всё же это не главная проблема. Главная - это то, что без ручных настроек и допилок кода Эльбрус сильно деградирует по перформансу, в отличие от RISC/CISC. А это фаталити на широком рынке.
unv_unv
09.09.2021 08:12+4Максим, но ведь ваш тезис был про принципиальную невозможность оптимизировать программу лучше, чем на суперскалярных x86-процессорах. А оказалось, что это можно сделать — и получается почти вдвое быстрее. Обнаружилась проблема в компиляторе — ну так пусть исправляют.
Arioch
09.09.2021 13:40у вас разные трактовки "про принципиальную невозможность"
вы сейчас говорите про "возьмём 10 академиков и 100 процессоров, сформируем из них институт, и он будет 10 лет писать одну программу"а он говорит про "ООО 'три директора и два программиста', из которых один уже уволился, а другой студент на испытательном сроке 'за еду', и которым нужно каждые два месяца новую версию программы на рынке продавать"
Одну единственную программу вылизать под Эльбрус++, ради одного единственного рекламно-пропагандисткого шоу, да, можно. Реальный массовый рынок - нет.
unv_unv
09.09.2021 19:41+2Подождите, но ведь исходный тезис был в том, что «Эльбрус» принципиально неулучшаем и что он будет работать принципиально хуже процессоров Intel и AMD. А тут вдруг оказалось, что предложенный цикл сортировки компилируется в одну широкую команду. Ну так можно признать, что исходный тезис ложен или нельзя? А дальше давайте клясть недоработанный компилятор и закрытость системы команд. Я вот с вами наперебой готов это всё клясть — но после того, как признаем, что ложен исходный тезис про неспособность статического планирования «Эльбруса» достичь эффективности выше суперскалярного процессора.
Armmaster Автор
10.09.2021 02:00+3Исходный тезис остаётся - VLIW принципиально хуже RISC/CISC подхода. Потому что наоптимизировать руками можно всё, что угодно. Куда более сложное hw затачивают руками.
Данный пример просто явно показывает, что мы даже простейший код в виде сортировки не можем эффективно без участия человека соптимизировать. На чуть более широких тестах - Spec2017 мы уже видим проигрыш в 3-4 раза современным процам. А на ещё более широком наборе задач - разрыв усугубится. Да о чём мы говорим - на Coremark'е Эльбрус умудрился проиграть Байкалу. Как предлагается такую архитектуру внедрять массово на предприятия? Для меня ответ очевиден. И в статьях я постарался донести суть проблемы.
Suor
10.09.2021 05:27+2Данный пример в итоге продемонстрировал тезис обратный вашему. Так что либо нужен другой пример, либо всё-таки отказаться от тезиса про принципиальную проблему микроархитектуры
Armmaster Автор
10.09.2021 10:51-1Данный пример продемонстрировал именно принципиальную проблему микроархитектуры. Если вы этого не видите - я тут ничего не могу поделать.
Arioch
10.09.2021 11:34+1принципиально неулучшаем
...в рамках сложившейся индустрии и сложившегося рынка "ширпотреба" компьютеров и программ. Вы меняете тезис. Меняете в нём условия.
Может ли человек летать? Да может, купил билет на самолёт и полетел. Значит ли это, что потерявшийся на необитаемом острове человек может улететь. По вашему - да значит, меняем условия задачи, из "шляпы фокусника" достаём аэропорт, кассу и кошелёк с деньгами - и полетели.
А дальше давайте клясть недоработанный компилятор
В реальном мире он НИКОГДА не будет доработан.
Ну или может быть, лет через 50, если вам от практических вопросов хочется улитеть в стратосферу теории.
Как MULTICS, который когда-то считался запредельно сложным, а сегодня меньше даже MINICS'a не то что Linux/Windows.
Но MULTICS не вернулся к жизни, хотя его фанаты считают все UNIXы абортированными уродцами, и даже написали эпохальную книгу про это (hacker's jargon dictionary).
Если лет через 50 кто-то когда-то сможет сделать практически применимый для многозадачных ОС и многопоточных программ общего назначения VLIW-компилятор, Эльбруса там всё равно уже не будет.и закрытость системы команд
Это только крышка в гвоздь гроба. Система команд Itanium была открыта, ресурсов у HP+Intel+Microsoft+Linux/GCC было на порядки больше. Всё равно не выжили.
Т.е. в случае гипотетического МЦСТ-для-всех-потребителей, закрытость команд - это просто овердоз уже смертельно больного наркомана. Без него результат тот же, просто не так быстро.
А второй гвоздь, что не смотря на примеры более-менее жизнеспособных Transmeta и Radeon МЦСТ с упорством зомби долбятся в C++, вмеcто JIT-компиляторов (JS, C#, JVM, etc, а также OpenCL/CUDA/DirectCompute), где у них были бы шансы.ложен исходный тезис про неспособность статического планирования «Эльбруса» достичь эффективности выше суперскалярного процессора
На чисто расчётной задаче, без ветвлений, тем более без многопоточности, тем более без каких либо других задач, кроме "числогрызки" - может. Возьмут "10 академиков и 100 профессоров" и они за 10 лет на ассемблере напишут идеальный алгоритм для этих данных на этом процессоре.
Правда, за это время те же данные уже 10 лет как обсчитают на ферме примитивных x86 или ARM, но медальки академики получат, за повторение того же результата 10 лет спусти.Правда, за это время МЦСТ выпустить другой процессор, на котором этот код станет неоптимальным, и придётся его выкидывать им начинать с нуля.
Правда, даже у лучшем случае результат этот работы будет невозможно применить к чем-то другому, к любой другой задаче. Чисто одноразовое усилие. Как у Дугласа Адамса, считали триллионы лет, потратили полностью звезду, и насчитали "42". Величайший академический результат с околонулевым влиянием на реальный мир.
Armmaster Автор
09.09.2021 14:54оказалось, что это можно сделать — и получается почти вдвое быстрее
Оно не получается вдвое быстрее. Потому что тем же самым (оптимизацией под машину) можно заняться и на x86. В этом и заключается постоянный подлог.
но ведь ваш тезис был про принципиальную невозможность оптимизировать программу лучше, чем на суперскалярных x86-процессорах.
Мой тезис был про то, что невозможно статически компилятору всё разобрать и в пределе это всегда уступает динамическому планировищику.Мы не можем достичь максимальной производительности на практике. Наоптимизировать всегда что-то можно. Но надо понимать, насколько такой подход применим на массовом рынке. И вы опять забываете, что это простейший идеальный пример для Эльбруса. А в реальной жизни вам даже ручная оптимизаация не поможет. Тут в комментах мы это уже обсудили. Представьте, у вас вероятноть обратной дуги во внутреннем цикле - 0.7 например. А внешний - основной. Сколько тогда будет работать предложенный выше оптмизированный код?
Этот же пример был приведен не для того, чтобы показать, что Эльбрус никак не может его соптимизировать. А для того, чтобы опровергнуть утверждения Алексея что "в реальности всё неплохо". Перечитайте все статьи внимательно на данный счёт.
Обнаружилась проблема в компиляторе — ну так пусть исправляют
Ну вот вам самому-то не смешно? 20+ лет делаем компайлер, а он простейший код в несколько строк не может скомпилить. Сколько ждать тогда, 100 лет?
К тому же я написал, что здесь нет никакой ошибки компайлера. Это типичная лапша от МЦСТ, которой они кормят людей уже 20+ лет, обещая что "ещё немного, ещё чуть-чуть". Без профиля тут непонятно, как оптимально соптимизировать. Отсюда и все проблемы. А с профилем будут другие примеры и другой класс проблем.
unv_unv
09.09.2021 19:47+3Ну займитесь оптимизацией под x86 — покажите, что можно сделать быстрее, чем на «Эльбрусе». Вы просто сменили тему разговора — в данном примере ваш тезис про неэффективность «Эльбруса» не оправдался. Можно это признать? А после признания говорить уже о том, что компилятор нехорош, что его долго пилили и всё равно он не может сходу определить горячий цикл и правильно его оптимизировать. Я тут вас абсолютно поддержу — это недоработка программистов. И в тезисе про закрытость системы команд поддержу.
Я просто не понимаю этого нежелания признать, что пример получился не вполне в тему исходного тезиса статьи. Вы же даже приписку к статье не хотите сделать, что вот при таких-то настройках оно компилируется более эффективно, чем на x86. Это же неправильно. И ваши оппоненты укажут на это нежелание как на вашу ангажированность. Вы делаете свою статью подударной.
edo1h
09.09.2021 20:40А после признания говорить уже о том, что компилятор нехорош, что его долго пилили и всё равно он не может сходу определить горячий цикл и правильно его оптимизировать. Я тут вас абсолютно поддержу — это недоработка программистов
уверены, что это недоработка программистов? на мой взгляд задача в общем случае выглядит если не совсем нерешаемой, то близкой к этому.
unv_unv
09.09.2021 23:47+1Это же тоже надо подтверждать фактами. А то выглядит, как будто решаема лишь задача создания продвинутого суперскалярного RISC-V процессора фирмой Yadro. Но как по мне, решаемость этой задачи тоже надо очень сильно доказывать.
edo1h
10.09.2021 01:01А то выглядит, как будто решаема лишь задача создания продвинутого суперскалярного RISC-V процессора
эта задача, очевидно, решаема, некоторое количество коммерчески-успешных процессоров, думаю, появится в ближайшие несколько несколько лет.
будет ли среди них отечественный — не знаю, но мне это кажется не настолько нереальным, как превращение эльбруса в коммерчески-успешный проект.
Armmaster Автор
10.09.2021 02:08Но как по мне, решаемость этой задачи тоже надо очень сильно доказывать.
Этот вопрос существует только у людей, далеких от индустрии процессоров. Нет никакой принципиальной проблемы в решаемости этой задачи. Все RISC/CISC архитектуры по сути своей одинаковы. Вопрос только в том, хватит ли технических компетенций у конкретного коллектива разработчиков, чтобы решить эту задачу.
amartology
10.09.2021 09:30-1А то выглядит, как будто решаема лишь задача создания продвинутого суперскалярного RISC-V процессора фирмой Yadro. Но как по мне, решаемость этой задачи тоже надо очень сильно доказывать.
А что там доказывать? Разными российскими компаниями разработаны десятки процессоров самой разной сложности. Почему вы считаете, что ещё одна компания не справится с ещё одним процессором?
Armmaster Автор
10.09.2021 02:05+1Ну нет же - я вам выше написал ответ. Вы просто не поняли, в чём главная суть статьи. Этот пример отличный показатель проблем Эльбруса. Если вы этого не видите - я ничего не могу поделать
Это не недоработка программистов - это принципиальный недостаток архитектуры, что она без ручной оптмизации не может работать эффективно. Сколько раз я должен написать этот тезис? Он же и есть главный во всех статьях об Эльбрусе.
Suor
10.09.2021 05:37Вы выдвинули тезис и подтвердили его примером. Ваш пример опровергли. Какие у вас адекватные варианты действий:
Признать, что пример неудачный, но тезиса это не отменяет. Привести пример получше или что-то получше примеров вообще.
Отказаться от тезиса.
Показать, что опровержение несостоятельно, и ваш пример всё-таки иллюстрирует ваш тезис, а не обратный.
Менять тему - ответ неадекватный. Хотя в статье действительно есть другие тезисы. Но смещать фокус к ним, игнорируя проблемный, как оказалось тезис о принципиальной ограниченности микроархитектуры, - это попытка замыливания вместо нормальной дискуссии.
Armmaster Автор
10.09.2021 10:58+4Откройте мою первую статью, самое начало. Что там написано? Вот есть пример простого цикла, внутри call, работаем 1 такт и там и там, всё хорошо. Т.е. микроархитектурная скорость равна, как и по результатам ручной оптимизации цикла из данной статьи. Что происходит, если call не заинлайнился? В x86 мы начинаем работать 3 такта, в e2k 17. Что мне на это ответили? Это синтетический пример, в реальности супер-пупер анализ и эвристики и всё хорошо, покажите реальный пример. Я его показал, как все эти супер пупер эвристики работают. Т.е. в рельности мы не можем код нормально соптимизировать. И это и есть принципиальная проблема микроархитектура. Это главный тезис.
Перечитайте внимательно обе статьи и не надо свои фантазии выдавать за мои тезисы и тем более выдвигать какие-то претензии, не разобравшись в вопросе до конца.
Suor
10.09.2021 11:29-3Центральный тезис этой статьи - микроархитектура Эльбруса принципиально плоха - не может исполнять код эффективно. Подкреплено это примером когда Эльбрус исполняет код неэффективно. Однако, вам со всей очевидностью показывают, что по крайней мере в этом случае, проблема в компиляторе. Вместо того, чтобы это признать, вы начинаете ссылаться на что-то ещё. Т.е. неявно признаёте, что пример неудачный и ваш тезис он не подтверждает. В явном же виде вы просто переходите на личности.
Это неадекватное поведение в дискуссии.
Armmaster Автор
10.09.2021 11:35+1Вы упорно не хотите внимательно прочитать то, что я вам написал. В общем, я всё, что считал нужным, написал. Дальше выводы каждый делает сам
Suor
10.09.2021 12:51+1Я выводы сделал - вы отказываетесь признавать ошибки и вести нормальную дискуссию.
Armmaster Автор
08.09.2021 15:03Нет Алексей, это всё в пользу бедных (мы в той ветке всё предметно обсудили). В этом и заключается главная проблема Эльбруса - потенциале, который на деле недостижим. Вы мне рассказывали, как супер-пупер эвристики могут со всем разобраться, а я вам привёл простейший пример, где все ваши рассуждения идут прахом. И именно по этому поводу я написал в самой первой статье:
Собственно говоря, именно с вышеуказанными проблемами связаны те многочисленные истории, когда пользователи Эльбруса, получив возможность скомпилировать и запустить своё ПО на данном железе, часто с первого раза получают удручающие результаты. Потому что если на небольших бенчмарках или тем более Spec2006/2017 (которые вылизывали 20+ лет) компилятор худо-бедно справляется и может сгенерировать близкий к оптимальному код, то на реальных проектах он уже не справляется, а т.к. аппаратура тут подстраховать не может, то производительность падает в разы. И начинается долгая история про то "как правильно переписать код проекта, чтобы lcc смог скомпилировать оптимальный код".
И дальше:
Поэтому оно старается фильтровать потенциальных клиентов, чтобы в случае возникновения перформанс проблем привлечь своих специалистов, которые могут разобраться в проблемах и с помощью правильных опций, допилок компилятора или переписывания горячего кода "под Эльбрус" улучшить производительность пользовательских задач. Но масштабируемость такого подхода, думаю, всем понятна.
Вот именно это мы здесь и увидели. Пришлось руками лезть в функцию сортировки, чтобы её наоптимизировать. Это можно делать в каких-то очень узких применениях. Но такая архитектура не имеет никаких шансов на широком рынке.
И вы должны понимать одну очень простую вещь. Всё, что я написал - это просто констатация факта. По-большому счёту от моих статей ничего не изменится в плане будущего Эльбруса - оно было предрешено уже в середине 2000-х. И прошлый начальник вашего же отдела ушёл в 2010-ом по той самой причине - не видел перспектив у Эльбруса, прекрасно понимая, что нереально создать такой компилятор, который требуется. А идею развиваться в сторону линейки Sparc руководство МЦСТ не поддержало. Т.е. уже в районе 2010-го многим в самом МЦСТ всё написанное стало понятно. И если честно, я пишу данные статьи скорее для вас. Потому что в МЦСТ есть инженерный потенциал, который, будучи направленным в правильное русло, может достичь выдающихся результатов. Но чем дольше вы бьётесь в стену Эльбруса, тем больше уходит время. Надеюсь, точка невозврата ещё не пройдена. Но принимать решения и что-то менять надо прямо сейчас.
yleo
08.09.2021 16:52+5Ради интереса прогнал бенчмарк сортировок на Эльбрус-8СВ и на примерно самом последнем Xeon. Кратко:
при выравнивании частоты Эльбрус-8СВ примерно равен по скорости Xeon Gold 5317 (последнее третье поколение Xeon Scallable на Ice Lake);
есть неожиданности/странности: quick sort существенно быстрее на e2k, а radix sort наоборот (буду смотреть как будет время);
сделав мелкую правку получил +10% на двух моих сортировках.
В текущем виде использованный бенчмарк, разными алгоритмами, по 1000 раз сортирует 42000 64-битных целых и выводит затраченное время в us.
Если не ошибаюсь, исходный вариант этого бенчмарка сделал Christopher Swenson работая в Google. Я же только добавил свои сортировки (
yysort1иyysort2) и расширил паттерны данных, ну и что-то по-мелочи. Кроме полностью случайного паттерна есть и другие (весьма важные). Исходники бенчмарка не являются образцом (он сугубо утилитарный), но "в принципе" пользоваться можно. Также стоит отметить, что большинство алгоритмов сортировки "допилено" до неплохого уровня, а не просто скопипащены из учебника.С управлением частотой на Штеуде, откровенно говоря, я замучился. Специально брал процессоры на 3ГГц, чтобы включать управление частотой и гонять бенчмарки на удобном ровном/круглом значении. Но пока так и не получилось заставить всё ядра работать на нужной частоте (похоже что постоянная работа на 3 ГГц - это вранье/маркетинг, а реальный стабильный максимум только 2800 МГц).
Поэтому я сделал проще - сровнял Xeon 5317 по частоте с Эльбрус-8СВ, т.е. задал частоту 1500 Mhz:
sudo cpupower frequency-set --min 1500MHz --max 1500MHzи прогнал бенчмарк.Intel(R) Xeon(R) Gold 5317 CPU @ 1500 ГГц + gcc version 10.3.0 (Ubuntu 10.3.0-1ubuntu1):
Running tests with random: extra.h yysort1_int64 - ok, 2081347.0 usec extra.h yysort2_int64 - ok, 2164745.0 usec extra.h radix_sort7_int64 - ok, 343104.0 usec sort.h tim_sort - ok, 3609279.0 usec sort.h quick_sort - ok, 2775912.0 usec extra.h std_sort_int64 - ok, 2446849.0 usec extra.h std_stable_int64 - ok, 2670384.0 usec sort.h heap_sort - ok, 2207371.0 usec sort.h merge_sort - ok, 3295311.0 usec sort.h shell_sort - ok, 4344429.0 usec sort.h merge_sort_in_place - ok, 3130430.0 usec sort.h grail_sort - ok, 3710524.0 usec sort.h sqrt_sort - ok, 3189873.0 usec stdlib qsort - ok, 4313366.0 usec ...Эльбрус-8СВ @ 1500МГц + lcc:1.25.17:May-16-2021:e2k-v5-linux
Running tests with random: extra.h yysort1_int64 - ok, 2312807.0 usec extra.h yysort1_int64 - ok, 1807040.0 usec <<< после мелкой доработки extra.h yysort2_int64 - ok, 2377249.0 usec extra.h yysort2_int64 - ok, 1871099.0 usec <<< после мелкой доработки extra.h radix_sort7_int64 - ok, 1153812.0 usec sort.h tim_sort - ok, 3497091.0 usec sort.h quick_sort - ok, 1691747.0 usec extra.h std_sort_int64 - ok, 2788794.0 usec extra.h std_stable_int64 - ok, 2760324.0 usec sort.h heap_sort - ok, 3661523.0 usec sort.h merge_sort - ok, 4256854.0 usec sort.h shell_sort - ok, 3922864.0 usec sort.h merge_sort_in_place - ok, 3830613.0 usec sort.h grail_sort - ok, 4839326.0 usec sort.h sqrt_sort - ok, 3508976.0 usec stdlib qsort - ok, 7311078.0 usec ...Символами
<<<помечены результаты после небольшой экспериментальной правки.Соответственно, у Эльбрусов я не вижу особых/неустранимых проблем с производительностью, но вижу отсутствие принципиальных проблем с безопасностью.
amartology
08.09.2021 16:56+1вижу отсутствие принципиальных проблем с безопасностью.
1) Является ли принципиальной проблемой с безопасностью то, что весь обмен данными с памятью идет через IP-блок американской компании Synopsys?
2) Более ли безопасен Эльбрус, чем Байкал, если вышеуказанный блок у них одинаковый?
3) Есть ли у вас какие-то подтверждения крайне спорного тезиса по ссылке, о том, что «в RISC-V нет ничего хорошего/перспективного при выходе за рамки ниши микроконтроллеров и устройств класса IoT.»cepera_ang
08.09.2021 17:02Да не, тут же речь про то, что нет потенциальных спектров/мелтдаунов, из-за того, что спекулятивного выполнения нет.
erthink
08.09.2021 17:42+1Эти блоки от Synopsys (вроде-бы) крутили-вертели и заглядывали во все гейты...
Но тут речь о другом - у Эльбрусов адреса возврата и данные/аргументы не смешаны в одном стеке. Поэтому большинство атак через переполнение буфера, двойное освобождение и ROP не могут эксплуатироваться. Это не означает что Эльбрусы "не пробиваемы", но всякие болден-RISC-и, прочие MIPSы, ARMы и x86 - буквально решето в сравнении с e2k.
Да, Spectre/Meltdown тоже нет, и я уверен что не появятся в v7 (седьмой версии архитектуры), в том числе, благодаря нашим "позитивным" советам.
Что касается тезиса "в RISC-V нет ничего хорошего/перспективного при выходе за рамки ниши микроконтроллеров и устройств класса IoT", то как в анекдоте про "два штуки/килограмма нифига" - если кто-то считает что такое хорошее/перспективное есть, то пусть покажет или просто использует "это" на всю катушку.amartology
08.09.2021 19:52+1вроде-бы
Хорошее уточнение. Жаль, что подтверждений этому тезису у вас нет. И не будет, потому что задача «крутили-вертели и заглядывали во все гейты» большого хардмаркро блока, от которого вам точно не дают схематик и не факт, что дают GDSII, на актуальных для Эльбруса проектных нормах сопоставима по сложности и стоимости со всей остальной разработкой процессора. И не факт, что в России вообще имеется техническая возможность это сделать.если кто-то считает что такое хорошее/перспективное есть, то пусть покажет или просто использует «это» на всю катушку.
Я таких стартапов в США знаю штук пять наверное. Через пять лет Эльбрус будет пытаться конкурировать не с Intel, а с ними. Или с теми российскими процессорами, которые воспользуются результатами работы этих стартапов.erthink
08.09.2021 20:21-1Не-не...
1. Через 5 лет ВТБ будет судиться с "ядрёным синкакором" в надежде вернуть остатки от 9-и ярдов, после того как Штеуд добавит декодер инструкций болден-риска в свои ядра...
2. Эльбрусы увеличат производительность в 3-5 раз: вдвое за счет роста частоты, а остальное за счет предсказателя переходов "с друзьями", ну и немного добавит компилятор.
За второй пункт готов поспорить на "ящик хорошего пива/коньяка", или (например) на 1 ETH.amartology
08.09.2021 20:28+1За второй пункт готов поспорить на «ящик хорошего пива/коньяка», или (например) на 1 ETH.
Готов поспорить на 1 ETH, что через пять лет Эльбрусы все так же будут содержать американские IP-блоки неизвестного содержания.yleo
08.09.2021 22:58+1Хм, а где и как (через чье плечо) вы увидели "IP-блоки неизвестного содержания" в e2k или в Байкалах?
Или в том смысле что Synopsys и/или МЦСТ публично не отчитались за содержание?
Или что "для безопасности" нужно вытравить весь "ихний/буржуйский верилог"?
Вообще вы за что: открытые ядра, обмен/покупку IP, fair use/provide или железный занавес?
(вопрос риторический)
Тем не менее, аргумент безопасности "достаточно железобетонный".
Поэтому альтернатив e2k в области ответственных применений нет, ибо два стека и т.д. и т.п.
Соответственно, будет тираж, более приемлемая цена и ресурсы на разработку.
А в целом, "болден-риск" - смешно/прикольно, конечно.amartology
08.09.2021 23:12+3Хм, а где и как (через чье плечо) вы увидели «IP-блоки неизвестного содержания» в e2k или в Байкалах?
В том смысле, что эти блоки поставляются как хард макро, и МЦСТ не имеет понятия и возможности проверить, нет ли у этих блоков каких-то недокументированных возможностей. Информация о том, что используются именно хардмакро от Синопсис, публична.
Или в том смысле что Synopsys и/или МЦСТ публично не отчитались за содержание?Вообще вы за что: открытые ядра, обмен/покупку IP, fair use/provide или железный занавес?
Я за глобализацию микроэлектроники и за отсутствие лицемерия в импортозамещении.cepera_ang
09.09.2021 08:21+1за отсутствие лицемерия в импортозамещении
Лезете просто с инженерией в политику, отсюда и вся подоплёка для этого спора :)
VlK
09.09.2021 09:48Я за глобализацию микроэлектроники и за отсутствие лицемерия в импортозамещении.
а что вы под "глобализацией" понимаете? Это ведь противоположность импортозамещения. "Либо крестик снимите, либо..." (с)
amartology
09.09.2021 10:10+2а что вы под «глобализацией» понимаете? Это ведь противоположность импортозамещения. «Либо крестик снимите, либо...»
Так я против импортозамещения в его нынешнем российском виде.
Глупо заниматься заведомо бесплодной конкуренцией с Intel и вливать в нее огромные по российским меркам деньги. Глупо ссориться со всем миром, из-за этого не иметь доступа к нормальному технологическому оборудованию для своих фабрик и жить в постоянном страхе «а что если США велят TSMC перестать работать с Россией» и «а где достать американские спецстойкие компоненты для спутников».
Импортозамещение здорового человека — это драйвер экономики, когда создаются продукты, конкурентоспособные на мировом рынке и способные не только вытеснить конкурентов с внутреннего рынка с помощью господдержки, но и занять долю конкурентов в мире. Конечной целью импортозамещения должен быть высокотехнологичный экспорт.
Завод «Микрон» получает 20% выручки от экспорта автомобильных и силовых чипов. Вот их надо поддерживать и помогать им заместить компоненты Bosch, из-за дефицита которых простаивает АвтоВАЗ.
Syntacore продает свои процессорные ядра за границу — вот их и надо поддерживать, потому что инженерные компетенции в России еще есть, в отличие от современных фабрик.
А Эльбрус на мировом рынке имеет ровно ноль перспектив и никогда не сможет реально конкурировать ни с Intel, ни с AMD, и вся его поддержка — это чисто политическая история напополам с распилом бюджетных денег в виде контрактов на поставки ПК в госструктуры. Никакой экономической отдачи от вложенных в развитие Эльбруса денег никогда не получится.VlK
09.09.2021 10:27+1Так я против импортозамещения в его нынешнем российском виде.
Ну так с этого надо было дискуссию начинать, и этим же заканчивать! Вы не считаете необходимым делать отечественные процессоры общего назначения, потому что Intel, AMD и прочие уже всё на эту тему сделали.
О чем тогда вообще речь?
amartology
09.09.2021 10:41Вы не считаете необходимым делать отечественные процессоры общего назначения, потому что Intel, AMD и прочие уже всё на эту тему сделали.
Не так. Я не считаю необходимым делать отечественные процессоры ради их отечественности. Если кто-то может сделать чип, который будет конкурентоспособен и по характеристикам, и по цене — вперед. Например, Байкалы с этой точки зрения выглядят интереснее Эльбрусов.О чем тогда вообще речь?
О том, что на бессмысленные потуги по созданию российских процессоров общего назначения тратятся бюджетные деньги, которые могли бы быть потрачены с большей для российской экономики пользой.
edo1h
08.09.2021 19:00как-то не бьются полученные результаты с упоминаемыми в статье результатами spec cpu 2017.
пробовали запустить во много потоков?
что-то «крутили» в опциях компиляции?erthink
08.09.2021 19:13Хм, а разве не очевидно что эти сортировки работают в один поток?
Все опции и скрипты сборки доступны в исходниках. Поэтому повторить/воспроизвести элементарно (просто `git clone` + `make`). Самое сложное, наверное, выровнять частоту ЦПУ или вручную отмасштабировать результаты.
edo1h
08.09.2021 20:08Хм, а разве не очевидно что эти сортировки работают в один поток?
очевидно. не очевидно, что при запуске нескольких инстансов производительность останется прежней.
Поэтому повторить/воспроизвести элементарно (просто
git clone+make).это-то я сделаю, только для x86. проверить для эльбруса сложнее.
Самое сложное, наверное, выровнять частоту ЦПУ или вручную отмасштабировать результаты.
с этим я проблем не вижу. смотрим реальную частоту после запуска теста. опыт показывает, что если нет проблем с охлаждением, то частота особо не меняется, так что можно её считать постоянной.
erthink
08.09.2021 21:35смотрим реальную частоту после запуска теста. опыт показывает, что если нет проблем с охлаждением, то частота особо не меняется, так что можно её считать постоянной.
Переключение частоты - это определенная процедура, которая требует времени. Поэтому, чтобы результаты бенчмарка были корректными (не искаженными), частота вообще не должна переключаться - не важно в минус (из-за перегрева) или в плюс (из-за появившейся вычислительной нагрузки).
Кроме этого, без отдельных "приседаний", нет гарантий что процесс/тред не будет мигрировать между ядрами. Поэтому требуется либо выставлять affinity, либо (что удобнее) добиться одинаковой частоты на всех ядрах. Вот последнее у меня пока не получилось сделать (некогда и пока нет большой необходимости этим заниматься).
creker
08.09.2021 20:44+3при выравнивании частоты Эльбрус-8СВ примерно равен по скорости Xeon Gold 5317
И толку от таких достижений? Если эльбрус не может работать на тех же частотах, на которых может интел, то грош цена этим результатам. Максимальные частоты это такая же часть микроархитектуры и эльбрусы, судя по всему, физически не способны забраться выше, а интел с амд могут. Поэтому тестировать нужно не на одинаковых частотах, а на максимальных. А если прямо совсем честно хочется, то в рамках одного теплового пакета.
похоже что постоянная работа на 3 ГГц - это вранье/маркетинг
Если у матери нормально реализована схема питания и все хорошо с охлаждением, то все будет работать стабильно. 3ГГц это вообще базовая частота. Если он на ней не работает, то у вас что-то очень плохое с платформой. По факту, этот процессор на одноядерной нагрузке будет стабильно держать турбо частоты, т.е. 3.6ГГц. Любые иные результаты это повод для беспокойства.
erthink
08.09.2021 21:21И толку от таких достижений?
За в ~1000 раз меньшие деньги (в сравнении с бюджетом штеуда) сделан процессор, который:
- Примерно не позволяет вскрыть систему со стороны 99.99% хакеров. Грубо говоря, примерно "не пробиваем" в сравнении с Intel/AMD, ARM, болден-RISC и прочими MIPS-ами.
- При необходимости может быть переведен на другой тех-процесс и изготовлен внутри страны.
- Позволяет решать все требуемые задачи.то в рамках одного теплового пакета.
Хм, так посчитайте, в моём понимании как-раз получается паритет.
если у матери нормально реализована схема питания и все хорошо с охлаждением, то все будет работать стабильно. 3ГГц это вообще базовая частота. Если он на ней не работает, то у вас что-то очень плохое с платформой. По факту, этот процессор на одноядерной нагрузке будет стабильно держать турбо частоты, т.е. 3.6ГГц. Любые иные результаты это повод для беспокойства.
Все-таки посоветую изучить матчасть, как именно и что там переключается/регулируется, и воздержаться от ненужных пояснений.
Конкретно в моём случае я не исключаю багов ядра и/или BIOS (теоретически могут быть прописываться не совсем те установки, что заданы). А нагрузку одно ядро конечно держит, но для многих (других моих) бенчмарков нужна стабильная и одинаковая частота на всех ядрах всех сокетов.creker
08.09.2021 22:42За в ~1000 раз меньшие деньги (в сравнении с бюджетом штеуда) сделан процессор, который:
Намного медленнее конкурентов, имеет устаревшую и неоптимальную для кода общего назначения архитектуру, не имеет нормальной поддержки со стороны софтовой экосистемы. А конечному клиенту нет никакого дело до бюджета, важна цена продукта. Она у интела низкая. На этом продукт уже закопан, но да ладно.Примерно не позволяет вскрыть систему со стороны 99.99% хакеров. Грубо говоря, примерно «не пробиваем» в сравнении с Intel/AMD, ARM, болден-RISC и прочими MIPS-ами.
Голословное утверждение с учетом всех входных данных, что нифига он не сделан на своих мощностях и с применением только своей логики.При необходимости может быть переведен на другой тех-процесс и изготовлен внутри страны.
И станет еще более ущербным как процессор общего назначения.Позволяет решать все требуемые задачи.
Он позволяет решить только одну задачу — обеспечить импортозамещение. Все остальные задачи его конкуренты решают намного лучше.Хм, так посчитайте, в моём понимании как-раз получается паритет.
Не получается. У процессоров термопакет в районе 150Вт. Только вот в рамках этого пакета интел работает на 3ГГц на всех ядрах, что оставит эльбрус далеко позади.Все-таки посоветую изучить матчасть, как именно и что там переключается/регулируется, и воздержаться от ненужных пояснений.
Не нужно мне этих советов, я прекрасно и так знаю, как там что переключается. Оно работает как я написал — базовая частота, ниже которой проц в максимальной нагрузке в нормальных условиях не опускается. И турбо частота, до которой одно ядро может прыгать. Буст всех ядер у этого процессора это 3.4ГГц. Это базовая спека интела. Дальше дело за вендорами, которые запросто могут выходить за ее пределы и бустить процессор еще выше. Если процессор работает ниже спеки, то платформа говно и, по сути, не может работать с этим процессором, посему он должен быть исключен из ее списка поддерживаемых процессоров.нужна стабильная и одинаковая частота на всех ядрах всех сокетов.
Кто это сказал? Если глянуть тот же SPEC CPU, то никто там частоты не фиксирует. Управление питанием это такая же часть микроархитектуры и нынче чрезвычайно важная. Для бенчмарков надо не частоты лочить, а несколько раз их прогонять как это делается в том же SPEC CPU.Civil
08.09.2021 23:39Кто это сказал? Если глянуть тот же SPEC CPU, то никто там частоты не фиксирует. Управление питанием это такая же часть микроархитектуры и нынче чрезвычайно важная. Для бенчмарков надо не частоты лочить, а несколько раз их прогонять как это делается в том же SPEC CPU.
Более того - я не просто так в прошлом посте просил дать SPEC Power, который как раз фокусируется на энергоэффективности. Там умение менять частоту одно из основополагающих.
Но вообще типично еще используют прогрев и условно первые несколько итераций не засчитывают в общий зачет.
В целом к бенчмаркам человека выше есть ряд вопросов. Нарпимер что он меряет с размером массива в 42 тысячи элементов (и почему 42 тысячи это хорошее число?). Есть у меня предчувствие, что все упрется в L2 кэш (который при зарезании частот до 1.5 ГГц будет рабоать как ни странно на 1.5 ГГц) и у кого latency выше тот и победит (например из x86 скорее всего в топе окажется Sandy Bridge старенький, насколько я помню у него кэш чуть-чуть побыстрее как раз), если только компилятор совсем плохой код не сгенерировал. Впрочем надо конечно разобрать бенчмарк и посмотреть, но немного ради спора лень это проделывать (подожду мнения и доказательства от автора). Правда мне кажется автор обиделся за то что его второй аккаунт забанили.
Если процессор работает ниже спеки, то платформа говно и, по сути, не может работать с этим процессором, посему он должен быть исключен из ее списка поддерживаемых процессоров.
Не обязательно. Мог ошибиться сборщик системы или эксплуататор (перегрев VRM платы может вызывать троттлинг процессора, а это может быть вызвано тем что эксплуататор допустим поставил систему в закрытый шкаф рядом с трубой горячей воды или еще чем-нибудь подобным). По хорошему систему надо сдать по гарантии (если не сам собирал, если сам - долго и нудно дебажить в чем проблема).
yleo
09.09.2021 01:55+1Как выше упомянуто, этот "бенчмарк" - утилитарный инструмент для проверки и оптимизации собственных сортировок (в частности для libmdbx), и 42 тысячи там именно потому-что 42. Никакого отношения к размеру кэшей, e2k и т.п. этот код и константы в нём не имеют (кроме последнего экспериментального коммита).
Для всего остального есть/доступны исходники, берите пробуйте опровергнуть и т.п. Может действительно у меня проблемные/замедленные процы или матплата, а для Эльбруса припасено ведро жидкого азота ;)
---
Да и все ядра обоих 5317 получилось запустить на 3 ГГц. Причина соскока на 2800 была в одной из ~20 опций BIOS в X12DPi-NT6 и (видимо, всё-таки) неточности, из-за которой некоторый захардкоженный/дефолтовый суммарный бюджет по частоте на все ядра был меньше чем 3000*12 на сокет.Civil
09.09.2021 02:08+1И вы проигнорировали половину того, что я сказал. Но, впрочем, ожидаемо. Уровень теста зато понятен.
Причина соскока на 2800 была в одной из ~20 опций BIOS в X12DPi-NT6 и (видимо, всё-таки) неточности, из-за которой некоторый захардкоженный/дефолтовый суммарный бюджет по частоте на все ядра был меньше чем 3000*12 на сокет.
Ну вот видите, а вы уже пытались обвинять интел, даже не разобравшись в вопросе.
yleo
09.09.2021 03:06+1Хм, этот «тест» - просто набор общеизвестных алгоритмов сортировки, подобранных и допеределанных сотрудником Google (в смысле понимаю, что я вам не авторитет). В основном он для сравнения этих сортировок между собой, в тех условиях и с теми параметрами, которые нужны запускающему.
Соответственно, было показано, что при работе на одной частоте, Эльбрус-8СВ и новейший Intel Xeon Gold 5317 выполняют некий одинаковый запрограммированный набор действий (1000 повторов каждой сортировки на 42 тысячах 64-битных элементах) за примерно равное время.
Если вы хотите выяснить что-то еще, опровергнуть результаты, либо показать что они почему-то некорректны или несостоятельны — так делайте/показывайте/доказывайте.
Ну вот видите, а вы уже пытались обвинять интел, даже не разобравшись в вопросе.
Пардон, так как-раз таки я разобрался в вопросе, написал об этом и (даже, вынужденно) оформил еще один багрепорт в поддержку Supermicro.
Теперь, похоже, Ваша очередь «разобраться в вопросе».cepera_ang
09.09.2021 08:27+1За примерно одинаковое время — это интел в среднем на 30% быстрее вообще-то с разбросом от 0.8х до 3х. Т.е. IPC интела оказался выше на 30%, частота одного ядра может быть выше в 2.4 раза, итого 3.1х, ах да, ещё ядер в полтора раза больше. И это какая-то случайная младшая модель. А так в целом паритет, да.
cepera_ang
09.09.2021 10:53Те, кто поставил минусы не смогли поделить цифры в бенчмарке из комментария выше и посчитать среднее ускорение?
Civil
09.09.2021 10:27в смысле понимаю, что я вам не авторитет
Да не, в том что это алгоритмы сортировки и что они работают у вас пока еще есть benefit of a doubt в этом. На авторитетов можно не ссылаться, а то начинает напоминать карго культ немного.
в тех условиях и с теми параметрами, которые нужны запускающему.
Ну я вам, как выбравшему тест, задал несколько вопросов. Получил на них ответы? Нет. Это достаточно, на мой взгляд, очерчивает уровень в первую очередь вашего понимания что вы делаете. А за сим дальнейший разговор теряет смысл. Разберетесь в вопросе достаточно чтобы обосновано дискутировать - можно будет продолжить.
Пардон, так как-раз таки я разобрался в вопросе, написал об этом и (даже, вынужденно) оформил еще один багрепорт в поддержку Supermicro.Теперь, похоже, Ваша очередь «разобраться в вопросе».
Так я ссылаюсь на ваш же пост раньше, где вы заявляли
похоже что постоянная работа на 3 ГГц - это вранье/маркетинг, а реальный стабильный максимум только 2800 МГц
И порадовался за Вас, что Вы наконец-то разобрались в мат. части в этом вопросе и понадеялся что больше не будет голословных обвинений.
Теперь буду ждать когда вы освоите мат часть теста, который сами же предложили в достаточно мере.
yleo
09.09.2021 13:27Ну я вам, как выбравшему тест, задал несколько вопросов. Получил на них ответы? Нет. Это достаточно, на мой взгляд, очерчивает уровень в первую очередь вашего понимания что вы делаете. А за сим дальнейший разговор теряет смысл. Разберетесь в вопросе достаточно чтобы обосновано дискутировать - можно будет продолжить.
Хм, не увидел вопросов на которые не было-бы ответов и/или стоило-бы отвечать отдельно или еще раз. Но давайте пройдемся вместе:
Почему 1.5 ГГц?
Как указал в самом начале - чтобы выровнять частоту с Эльбрус-8СВ. Но, видимо, стоило подробнее пояснить, что базовая частота Xeon 5317 равна 3000 МГц и удобна тем, что ровно вдвое больше частоты Эльбрус-8СВ. Соответственно, 1500 было выбрано как удобно/равное значение после неудачи с переключением Xeon на его родные 3 ГГц.
Наверно стоило как-то обозначить, что сравнивается эффективная/наблюдаемая "скорость архитектур", как если-бы они (были сделаны по одному техпроцессу и) работали на одинаковой частоте. Но вроде-бы это и так понятно из контекста производимых действий и начала текста.
Почему 42 тысячи это хорошее число?
Собственно, я же уже отвечал "этот бенчмарк - утилитарный инструмент для проверки и оптимизации собственных сортировок (в частности для libmdbx), и 42 тысячи там именно потому-что 42". Проще говоря, такой размер сортируемого массива просто подходит (вроде-бы очевидно?) для сравнения скорости сортировок между собой и просто остался в исходниках с его предыдущего использования.
Еще у вас были упоминания про управление частотой в тестах на энерго-эффективность - но я сравнивал/оценивал другое.Упоминание про "прогрев" и отбрасывание первых итераций - тоже не релевантно, так как при фиксированной частоте и замере по wall clock первая итерация растворяется в 1000 повторений.
Да, и на всякий - при переключении Xeon на 3 ГГц время работы бенчмарка уменьшает вдвое с точностью до погрешности. Можно было-бы добавить эти результаты, но в них нет ничего нового/интересного.
Civil
09.09.2021 14:56Но вроде-бы это и так понятно из контекста производимых действий и начала текста.
Тогда Вы не поняли вопрос. Переформулирую - какой в этом смысл?
Изменение частоты имело бы смысл, если бы у Эльбрусов была бы перспектива достичь 3 ГГц вот прям в ближайшем будущем без микроархитектурных изменений. Такой перспективы нет, значит занижение частоты не имеет смысл, так как, как ни странно, микроархитектура на нее влияет напрямую.
То есть уже один момент где сравнение заведомо некорректно.
Собственно, я же уже отвечал "этот бенчмарк - утилитарный инструмент для проверки и оптимизации собственных сортировок (в частности для libmdbx), и 42 тысячи там именно потому-что 42". Проще говоря, такой размер сортируемого массива просто подходит (вроде-бы очевидно?) для сравнения скорости сортировок между собой и просто остался в исходниках с его предыдущего использования.
Прочитайте, пожалуйста, мой вопрос повнимательнее. К сожалению для качественного сравнения "потому что 42" не является достаточным ответом.
Я напомню - я пытаюсь понять какую конкретно часть аппаратуры вы тестируете (чтобы понимать ожидаемое). Потому что пока что ваш пример очевидно может показать проблемы с оптимизацией кода на стороне компилятора (тут то что нужно делать изменение чтоб получить +10% - показательно, но нет объяснений почему тот же самый код что на Эльбрусах не был проверен на интеле). Почему это важно? Потому что Вы привели тест в рамках рассуждений о микроархитектурной скорости, значит нужно обоснование что тест является показательным и будет показывать сильные и/или слабые стороны архитектуры.
С подходом, отрицающим объяснения и попыток докопаться до сути тест не имеет никакого теоретического или практического смысла. Почему? Представим себе гипотетическую ситуацию что вы тестируете по факту скорость работы кэша (комбинированно throughput + latency), в таком случаи у вас практически любая железка, включая простой in-order risc-v или arm (кстати тоже было бы неплохо проверить Ваш тест) будет давать крайне схожие результаты, если компилятор конечно делает хоть какие-то оптимизации, на базе этого строить какие либо выводы будет невозможно.
Еще у вас были упоминания про управление частотой в тестах на энерго-эффективность - но я сравнивал/оценивал другое.
Я не говорил что вы сравниваете что-то в таком духе, я это использовал только в рамках указания другому человеку что есть другие способы получить разумные и даже повторяемые результаты без отключения энергосбережения.
Но такое сравнение было бы интересно, потому что, как ни странно, электричество это важная статья расходов какого-нибудь ЦОДа и если у тебя есть железка которая выдает X попугаев потребляя Y Ватт, и другая железка, выдающая X*2 попугаев потребляя те же Y Ватт, это очень весомый довод в пользу железки №2 даже если она стоит вдвое дороже (на горизонте типичной эксплуатации железа, затраты на электроэнергию выйдут на первое место, помноженное на десятки тысяч серверов это составит уже нехилую такую сумму). Но корректное тестирование железа в таком режиме уже не так просто реализовать (нужно как минимум уметь понимать свое энергопотребление, а по хорошему вообще отдать это на откуп внешнего устройства, которое на выходе даст лог за время проведения теста). И такое я вполне требую от людей из МЦСТ, как от компании (и требовал бы от тестовых лабораторий и прочих журналистов, в это влезших), но Вы вроде бы в категорию "человек из МЦСТ" не попадаете?
Упоминание про "прогрев" и отбрасывание первых итераций - тоже не релевантно, так как при фиксированной частоте и замере по wall clock первая итерация растворяется в 1000 повторений.
Оно также имело смысл для другого человека в первую очередь. Но для Вас оно имеет тот смысл, что во время первых нескольких итераций частота ядра успеет подняться до стабильного уровня и достаточно откинуть первые несколько значений чтобы избавиться от негативного эффекта скейлинга частоты, то есть не обязательно фиксировать ее на одном уровне. Да, зафиксировать базовую частоту проще, особенно когда не хочется разбираться в том как работают режимы энергосбережения, но это даст тоже слегка искаженные результаты относительно реального мира (и это придется учитывать всем кто читает такого рода тесты).
Armmaster Автор
08.09.2021 23:26Это ещё один миф. По ссылке написана очередная дичь для домохозяек
yleo
09.09.2021 00:37+1Ну это уже перебор, или клоунада какая-то.
Вы как "специалист" утверждаете что на e2k все уязвимости (или большинство, или какая-то существенная часть, или хотя-бы одна...) эксплуатируются также легко как на x86 или болден-RISC?
Может покажите хоть один пример, либо концепт?
Для любой известной уязвимости, или гипотетической, на ваш выбор.
Так сказать, покажите мастер-класс домохозяйкам из Positive Technologies?Armmaster Автор
09.09.2021 02:18+3Клоунада - это вся та статья, на которую вы дали линк, а особенно указанный вами комментарий Леонида Юрьева, включая:
Фактически RISC-V — это недопеределанная система команд по мотивам MIPS для применения в простых, низкопроизводительных и дешевых процессорах
Однако, если же на основе ISA RISC-V пытаться делать универсальный высокопроизводительный процессор, то почти все ухищрения системы команд RISC-V начнут работать в минус
Но здесь есть и обратная сторона — пересаживаясь на готовые решения неизбежно теряешь собственные компетенции и возможность выбора в дальнейшем
У RISC-V плохо с безопасностью (поверхностью атаки), а в сравнении с «Эльбрусами» – плохо кошмарно, принципиально и неустранимо
Кроме этого, для достижения высокой производительности предполагается использование внеочередного и спекулятивного исполнения инструкций, что (мягко говоря) закладывает фундамент для уязвимостей класса Meltdown/Spectre/L1TF/ZombieLoad
Всё это бредни человека, не разбирающегося в процессорах и плохо понимающего в их безопасности и уязвимости. И где он работает - в PT, Интел, АМД или у Господа Бога мне абсолютно всё равно.
А теперь по поводу отсутствия проблем безопасности в Эльбрусе. Основа работа VLIW для достижения производительности - это спекулятивное исполнение инструкций. Поэтому он легко может спекулятивно исполнять команды по различным веткам, включая load. Откройте мой пример и посмотрите в код. Load операции с признаком "sm" - это они. Например:
ldw,0,sm %dr0, %dr3, %r7Если этого не делать, там деградация по перфу будет ещё в разы. Поэтому весь потенциал для набора проблем аля Spectre/Meltdown там есть. Хоть и при отсутствии branch predictor'а, но суть та же. И я где-то видел выступление того же Трушкина, где он аккуратно наличие проблемы признавал.
Просто при закрытости и малодоступности архитектуры никто Эльбрус на предмет реальных проблем особо не тестил. А если это сделать - там наверняка вагон проблем вылезет. Понятно же, где слабые места и куда копать. Плюс в Эльбрусе были ошибки в аппаратуре, которые при неудачной последовательности байт вообще машину клали. Не знаю, какова актуальная ситуация, но подозреваю что Errata там очень приличная и с неприятными сюрпризами.
Вся "безопасность" Эльбруса - это отдельный стэк вызовов и тэги. Про тэги можно пока забыть - это специальный режим, работоспособность которого непонятна и в продакшене они не используются - это только для каких-то специальных применений.
А выделенный стэк вызовов даёт защиту от типичных атак переполнения стэка. Но во первых, в типичных стэковых машинах эта проблема частично решается наличием nx-бита. А во-вторых - атака через стэк вызовов это только часть огромного числа вариантов атак. Поэтому по факту Эльбрус лишь снимает потенциальный риск эксплуатирования уязвимости с переполнением стэка. Это хорошо, но глобально проблем не снимает.
KvanTTT
09.09.2021 02:52Кстати, а на сколько вообще критичны эти уязвимости? У меня сложилось впечатление, что похоже на вирусы на линуксе: они есть, но надо еще постараться чтобы это просто сработало, даже запуская собственноручно.
Armmaster Автор
09.09.2021 03:01+2Ну если хотите лично моё мнение - это больше хайп, чем реальная проблема. Но тут сейчас набегут эксперты по безопасности, которые с пеной у рта будут доказывать, что не зря едят свой хлеб.
yleo
09.09.2021 07:42+2У вас зашкаливает апломб, самоуверенность и стремление выдать желаемое за действительное.
Однако, вот должен признать, что я сам себя «подловил». Конкретно, в одном из моих ответов есть фраза: «Да, Spectre/Meltdown тоже нет», что не соответствует действительности, в той полноте смысла как это читается. На Эльбрусах всех актуальных версий (3, 4, 5, 6) можно вызвать спекулятивную загрузку в кэш, а пока не доказано обратное (т. е. пока не опубликованы результаты подобных исследований) действительно нельзя говорить что Spectre/Meltdown отсутствуют.
Думаю всем понятно, что соответствующие дизайнерские решения были заложены в актуальные версии архитектуры Эльбрус до раскрытия информации о Meltdown/Spectre, и без какой-либо экспертизы/оценки возможных проблем (в кулуарах, ваш покорный слуга, предупреждал о потенциальных проблемах из-за спекулятивного выполнения еще лет 15 назад, но к e2k это вообще никак не относится).
На данный момент мне не известно о том, чтобы кто-то завершил работу по более-менее полноценному исследованию этой проблемы в Эльрусах, включая Positive Technologies. Но в соответствии с общепринятыми правилами и практиками, раскрываться такая информация будет после реализации всех необходимых защитных мер в софте и «раскатки» этих патчей у пользователей/заказчиков.
Тем не менее, проблемы типа Spectre/Meltdown есть примерно во всех актуальных процессорах со спекулятивным выполнением. Можно предполагать, что основные игроки будут как-то решать проблему, но где заявления что проблемы будут устранены в такой-то версии или к такой-то дате?
Возвращаясь к Эльбрусам - еще в начале 2018 года обсуждались варианты защиты и мной (и, вероятно, кем-то еще) был предложен достаточно очевидный и приемлемо надежный способ защиты от «спекулятивных проблем» в последующих версиях архитектуры. Соответственно, мне сложно поверить, что в v7 эта проблема сохранится.
Поэтому, у текущих Эльбрусов со Spectre/Meltdown не хуже чем у Intel/AMD и далее по списку. В следующих версиях Эльбрусов, уверен что этой проблемы не будет.
---Теперь давайте вернемся к моим «бредням» в комментарии к статье Касперской и Ашманова:
Утверждается что у RISC-V нет преимуществ при выходе из low-end сегмента с переходом в high-end. Ну а какие технические/технологические преимущества, скажем в сравнении с MIPS64 или AARCH64? Простота декодера тут уже особой роли не играет и x86 хорошо это подтверждает. Как где-то уже мелькало — покажите эти преимущества, либо просто используйте их если они есть.
-
Сравнивается текущая «поверхность атаки» RISC-V и Эльбрусов. Тут у E2K действительно неоспоримое, сравнительно «непробиваемое» преимущество, ибо раздельные стеки для адресов возврата и данных примерно отсекают все сценарии атак через переполнение буфера на стеке и атаки с использованием ROP.
Это не значит что Эльбрусы не уязвимы, но значит что подавляющее большинство атак не реализуемо или крайне затруднено, и что вероятность эксплуатирования уязвимостей существенно меньше. Сформулировать это в виде четкой, достоверной и полезной метрики не возможно, ибо недостаточно статистики и мало самих Эльбрусов. Но можно переформулировать так — практика показывает, что почти любая система на x86/ARM/MIPS (и RISC-V как подвид MIPS) имеет уязвимости эксплуатируемые через ROP. А вот на Эльбрусах эксплуатирования подобных дыр пока не было.
Утверждается что RISC-V предполагает спекулятивное выполнение в высокопроизводительных ядрах и этим закладывает фундамент для Spectre-подобных уязвимостей. Мне по-прежнему не известна информация противоречащая этому тезису, ровно как и ничего не известно о проработки в RISC-V вариантов более-менее гарантированной защиты от Spectre, как это происходит сейчас с e2k.
----
Теперь по остальным вашим аргументам.
при закрытости и малодоступности архитектуры никто Эльбрус на предмет реальных проблем особо не тестил
Ну вот как-бы начинаем, и другого пути нет, кроме как вникнуть и проверить. Но не нужно смешивать заведомо известные принципиальные проблемы в архитектурах x86/ARM/MIPS и болден-RISC с еще не найденными проблемами Эльбрусов. Ну или другими словами — в Эльбрусах искать надо, а там вон бери и взламывай (наблюдаем регулярно).
в Эльбрусе были ошибки в аппаратуре, которые при неудачной последовательности байт вообще машину клали.
Ошибки в аппаратуре были и есть у всех. Буквально у всех, всегда и с самыми разными последствиями, из которых зависание — очень даже безобидно. Глядя в Errata иногда не понятно как оно вообще живет, а тут просто зависания. Премировать надо, если молчаливых багов нет.
Про тэги можно пока забыть - это специальный режим, работоспособность которого непонятна и в продакшене они не используются - это только для каких-то специальных применений.
Так а в чем проблема, что там «непонятно», или просто не пользовались? Конечно работа в 128-битном режиме доставляет, накладные расходы и отсутствие привычных вольностей с указателями. Но используется там где нужно/затребовано.
А выделенный стэк вызовов даёт защиту от типичных атак переполнения стэка… ...Поэтому по факту Эльбрус лишь снимает потенциальный риск эксплуатирования уязвимости с переполнением стэка. Это хорошо, но глобально проблем не снимает.
Эмм, в сухом остатке:
ваше владение темой недостаточно, а рассуждения достаточно ошибочны и опровергаются (в частности и в том числе) CVE-сводками.
полной гарантии никто дать не может, т. е. двойной стек и всё остальное не означает неуязвимость Эльбрусов.
незащищенность Эльбрусов может показать какое-нибудь пробитие, либо какой-то анализ показывающий потенциальную возможность/концепт эксплоита.
Пока «на руках» мы имеем множественные разнообразные примеры эксплуатации дыр на всех популярных архитектурах, и ни одного показанного практического пробития двойного стека Эльбруса, даже без использования тегов.
amartology
09.09.2021 08:03+4ни одного показанного практического пробития двойного стека Эльбруса, даже без использования тегов.
А кто-то пробовал вообще? Ну то есть давайте сравним масштаб усилий, потраченных на взлом х86 и на взлом Эльбрусов. А то пока что Эльбрус выглядит как неуловимый Джо.
cepera_ang
09.09.2021 08:34+1Покажите как кто-то взломал компанию на x86, которая серьезно озабочена безопасностью. Ну там, где взломы гугла например? Или Амазона? А ведь это не от того, что никто не пытается, очень даже пытаются. И эти ребята дают миллионам людей запускать код на своём железе, но что-то не слышно даже чтобы хоть кто-то из виртуалки выбрался на практике, только в теории.
yalex1442
09.09.2021 08:56+1> Или Амазона
Взломов и утечек может и не было, но на кошельках пользователей облаков проблемы legacy-архитекур точно отразились:
www.opennet.ru/opennews/art.shtml?num=55186Предложенные методы позволили поднять производительность обработчика JSON на основе библиотеки libreactor в окружении Amazon EC2 (4 vCPU)…
Отключение защиты от уязвимостей, вызванных спекулятивным выполнением инструкций. Использование параметров при загрузке ядра «nospectre_v1 nospectre_v2 pti=off mds=off tsx_async_abort=off» позволило поднять производительность на 28%, а пропускная способность возросла с 347k req/s до 446k req/s
Видно, что для некоторых сценариев из-за заплаток от дыр в оптимизаторах на чипе придется увеличивать бюджеты на хостинг, т.к. нужно больше узлов для достижения прежнего уровня производительности. А на Э же вовсе невозможна эксплуатация уязвимостей этих оптимизаторов ввиду их отсутствия как таковых.cepera_ang
09.09.2021 10:59+2Эм, вообще-то эти "дырявые легаси оптимизации" давали бесплатное ускорение все эти годы и теперь приходится отдавать часть этого ускорения в некоторых задачах. А практических дыр как не было, так и нет.
Но в сравнении с гипотетическим несуществующим облаком на непогрешимых эльбрусах всё равно выигрывают существующие "дырявые легаси архитектуры" без реальных случае эксплуатации этих дыр и с реальной производительностью и совсем недорогими ценами.
Armmaster Автор
09.09.2021 15:23-1Вот видите. Вы сначала утверждали, что принципиальных проблем с безопасностью нет на Эльбрусе, а оказалось, что они всё-таки есть.
Остальные ваши измышления мне просто неинтересно комментировать. Могу лишь посоветовать перечитать мою статью про то, каким должен быть отечественный процессор. Часть ответов на ваши вопросы там есть.
Если же вы действительно хотите квалифицированных ответов и дискуссии, а не просто доказать какую-то религиозную позицию, то можно с оказией обсудить это в оффлайне в рамках какого-нибудь мероприятия.
yleo
09.09.2021 16:42+4Хм, эка Вы повернули ;) Конечно можете тут крутить/вертеть слова как хотите, в том числе и мои осторожно-аккуратные формулировки о (не)эксплуатируемости Specte-подобных проблем на Эльбрусах (требуется ждать завершения работ и раскрытия информации).
От советов перечитывать и дальше получать "квалифицированные" ответы я вежливо откажусь, и подведу черту чтобы не тратить время:1. В Эльбруса со Spectre не хуже чем в любых других процессорах со спекулятивной загрузкой. А в следующей версии архитектуры этих проблем не будет. Тогда как намерения Intel/AMD по устранению не декларированы, а в участники RISC-V (видимо) вообще не считают это проблемой.
2. В Эльбрусе отдельный стек для адресов возврата, плюс возможность использовать теги и расширенные указатели для дополнительной защиты. Поэтому риски эксплуатации ROP, включая ошибки записи за пределы буфера, double-free и use-after-free кардинально ниже.
3. У RISC-V как ISA нет значимых технических/технологических преимуществ при переходе в сегмент высокопроизводительных ЦПУ.
Armmaster Автор
09.09.2021 17:06Хм, эка Вы повернули ;) Конечно можете тут крутить/вертеть слова как хотите, в том числе и мои осторожно-аккуратные формулировки о (не)эксплуатируемости Specte-подобных проблем на Эльбрусах
Я не знаю, что можно перевернуть в вашей же фразе:
Вам на пальцах показали, что это не так. А вы вместо того, чтобы признать ошибочность данного высказывания, начинаете вилять пятой точкой.
Ну а черт в виртуальном пространстве вы можете рисовать сколько угодно. Толку то.
yleo
09.09.2021 18:28+3Вы не владеете темой, но продолжаете изображать специалиста и гнуть свою линию, неся при этом ерунду.
1. Эксплуатация Spectre/Meltdown требует локального доступа. А на Эльбрусах дополнительно еще и возможности конструировать нативный исполнимый код (в памяти или в файлах), так как JIT-ов примерно нет.
2. Уязвимости связанные с выходом за пределы буфера и использованием ROP могут эксплуатировать удаленно достаточно часто. Но на Эльбрусах вероятность их эксплуатации кардинально ниже из-за двойного стека. Причем это без учета возможности использования защиты «тегами», которая может быть использована только в процессах подверженных рискам атаки.
3. Соответственно, на Эльбусах относительно легко защититься от Spectre/Meltdown просто адекватным системным администрированием (например, хотя-бы убрать компиляторы и запретить взводить eXecute бит у файлов). Вероятность же удаленной эксплуатации Spectre/Meltdown через ROP стремиться к нулю. Причем всё это без учета противодействия Spectre/Meltdown со стороны ядра ОС.
Поэтому, я действительно вижу отдельные недостатки, но не вижу принципиальных проблем с безопасностью Эльбрусов, особенно в сравнении с x86, ARM, MIPS и болден-RISC (aka RISC-V).
amartology
09.09.2021 19:11+13. У RISC-V как ISA нет значимых технических/технологических преимуществ при переходе в сегмент высокопроизводительных ЦПУ.
Недостатков по сравнению с другими RISC тоже нет, а значит процессоры на ней тоже можно делать.
Отдельно, кстати, хочу заметить, что тон, которым вы говорите о RISC-V, вообще не способствует восприятию вас как человека, способного к конструктивной дискуссии. Дешевое хамство вообще никому не делает чести, а вы даже великое слово «болген» не утруждаетесь правильно писать)
neonkainside
10.09.2021 09:37Думается мне дело в том, что в последние месяцы благодаря поднятому МЦСТ сотоварищи шуму по поводу проекта изменения 719 постановления RISC-V обрел в глазах скажем так патриотической общественности ореол чего-то вражеского.
Вот тут можно глянуть пример такой натурально пропаганды. В прочем не советую, напрасно потраченный час времени.
yleo
10.09.2021 18:14«болген» - это, конечно, просто одна из опечаток (привык к высокому разрешению и мелкому шрифту, а зрение уже подводит - не замечаю).
Что касается тона и термина "Болден-RISC", то в этой шутке есть доля правды. Конечно, с одной стороны, хорошо что есть открытые ISA, IP и целые ядра. Но нас ждет зоопарк ядер не меньший чем зоопарк дистрибутивов Linux, и проблема зависимостей (приветnmp), как по IP, так и по программному коду.
Открытость ISA, расширяемость и доступность готовых IP, приводит к появлению массы как стартапов, так и отделов разработки собственных ЦПУ со "стартаперским духом" — когда важно быстро-быстро показать первый результат, а какие-то неудобные вопросы/проблемы замести под ковер с обещанием "потом всё порешаем, когда доплывём".Среди таких вопросов — небезопасность RISC-V. Конечно RISC-V нельзя назвать более дырявым чем другие ISA в своих сегментах. Но для меня несколько странно/неожиданно, что в RISC-V бережно сохранено всё необходимо для эксплуатации всех традиционных ошибок/дыр.
Да, пожалуй, у меня есть определенное "профессиональное искажение". Тем не менее, свободно-бесплатная раздача ISA и ядер с явными (бережно сохраненными) проблемами с безопасностью — всё-таки начинает выглядеть как сыр в мышеловке.
При этом я (пока) не встречал человека на позиции ЛПР, который-бы понимал все сложности и проблемы связанные с управлениями этими зависимостями, и уже планировал бизнес-процессы и жизненный цикл устройств/продукции с учетом необходимости отслеживания ошибок/проблем/уязвимостей и (соответственно) необходимости обновлений и замены/отзыва проблемных устройств.
Так вот, совокупность всего вышеописанного, вместе с создаваемым хайпом, позволяю себе называть "Болден-RISC".
(думаю стоит написать статью с освещением всех этих вопросов).amartology
10.09.2021 18:53+1Тем не менее, свободно-бесплатная раздача ISA и ядер с явными (бережно сохраненными) проблемами с безопасностью — всё-таки начинает выглядеть как сыр в мышеловке.
Так идея состоит в том, что если вам важна скорость — вы садитесь и пишете свое быстрое ядро RISC-V, а если важна безопасность — то садитесь и пишете безопасное. И в том, и в другом случае вы получите и нужные вам свойства, и совместимость с широким пулом софта.
Открытость экосистемы, разумеется, имеет свои минусы, но какой-то конкурент ARM нужен, и вот такой способ его создать оказался самым лучшим — в отличие от не справившихся с задачей MIPS, SPARC и иже с ними.
Кроме того, бОльшая открытость как раз дает доступ к ловле дыр бОльшему количеству людей, что тоже в конечном итоге хорошо.yleo
10.09.2021 19:25+1Немного смешались мухи и котлеты.
Вы говорите об «опциональной» безопасности конкретных реализаций ядер. В частности, например, о выключении/блокировании спекулятивной загрузки для предотвращения Spectre/Meltdown. Понятно что «так можно делать», в том числе решать/выбирать для каждого конкретного ядра (модели ЦПУ).
А я писал про проблемы ISA как таковой — сохранено всё необходимое для ROP и эксплуатации записи за границы буфера. Здесь нельзя реализовать каких-либо эффективных мер/механизмов без нарушения бинарной совместимости с ISA (Intel делал несколько подходов).
Хотя, теоретически, можно «форкнуть» и сделать RISC-6, поправив Spectre и остальные недопеределки (вот, если-бы Yando взялось, то я бы помог...).
yleo
14.09.2021 02:43+3Коллега посоветовал уточнить/пояснить "пару моментов" в моём обосновании небезопасности/нелюбви к RISC-V и фразе «бережно сохранено всё необходимое для ROP». Не думаю, что этот комментарий прочитает больше чем несколько человек, но считаю написать стоит.
Суть в том, что в RISC-ах в явном виде в аппаратуре нет стека "как на x86". Стек специфицируется/реализуется на уровне ABI посредством назначения ролей регистрам и соглашения о вызове функций, а инструкции
push,pop,callиretотсутствуют на уровне аппаратуры в явном виде и являются макросами и/или псевдоиструкциями. Программное обеспечение может реализовать поверх ISA один, два или сколько угодно стеков. Поэтому предъявлять претензии к набору команд RISC-V по поводу одного стека необоснованно — вроде-бы всё верно, но...Собственно говоря, программно реализовать два стека, т.е. отделить данные (и потенциально уязвимые буфера на стеке) от адресов возврата, можно на всех архитектурах (имеющих косвенную адресацию), включая x86, ARM, MIPS и т.д. Принципиально ничего невыполнимого нет (но будут нюансы), разница только в объеме накладных расходах, трудоёмкости и (не)привязке к возможностям и/или контролю аппаратуры.
Если возможно программно реализовать два стека на чуть менее чем любой архитектуре ЦПУ и это, прежде всего, связано со сменой ABI, то «количество стеков» — это атрибут ABI? Либо ABI (может именно этот аспект) является какой-то значимой частью архитектуры как экосистемы?
Говоря что у RISC-V один стек, я знаю о возможности его разделить сугубо программно сменой ABI. Однако, если смотреть на «экосистему архитектуры» RISC-V:
представлен только «одностековый» вариант ABI и всей экосистемы;
явно определено
reg(sp) == reg(x2), push/pop в/из RAS дляjalr;нет упоминания о втором
spдля передачи большого кол-ва аргументов и хранения локальных данных, отдельно от RAS;для разделения стеков требуется специфицировать ABI, поправить компилятор(ы)/toolchain и доперепортировать софт.
Поэтому я критикую RISC-V как одно-стековую архитектуру подверженную ROP: не предусмотрено какое-либо разрешение/запрещения переходов/возвратов к командам, нет само-синхронизации кодирования команд переменной длины.
С другой стороны, на x86 тоже можно сменить ABI, разделить стек, многократно снизив этим риск эксплуатации уязвимостей. Подобное разделение приведёт к некоторой потери плотности кода, в основном из-за заметы
pushнаmov [reg + offset]при подготовке/передачи аргументов. Но для рынка это давно табу из-за слома совместимости и необходимости допиливать тонны софта.AMD разрабатывали AMD64 как расширение ISA более 20 лет назад, думая о time-to-market и минимизации непохожести с x86_32. Ожидаемо, что тогда не думали про два стека. Но с RISC-V принципиально иначе: потеря эффективности минимальная (занимаем один регистр), а слома ABI вообще могло не быть.
Поэтому мне не ясны (не очевидны) причины, по которым для RISC-V специфицировано только «одностековое» ABI и «бережно сохранено всё необходимое для ROP и эксплуатации традиционных ошибок выхода за пределы буфера на стеке».
Armmaster Автор
14.09.2021 03:20+1Поэтому мне не ясны (не очевидны) причины, по которым для RISC-V специфицировано только «одностековое» ABI и «бережно сохранено всё необходимое для ROP и эксплуатации традиционных ошибок выхода за пределы буфера на стеке»
Ответ достаточно очевиден на мой взгляд - это не является такой проблемой, как вы пытаетесь представить. У вас профессиональная девиация, вы думаете, что проблема переполнения это такая супер важная вещь, но индустрия в целом смотрит на это несколько иначе. И переусложнять всю инфраструктуру, чтобы менеджить 2 стэка ради достаточно призрачных бенефитов никто особого смысла не видит.
Давайте я спрошу простую вещь - чем 2 стэка лучше решения, когда у нас весь код в исполняемом файле замаплен с аттрибутами rx, а стэк выделен как rw ?
В зависимости от вашего ответа я могу подробнее ответить на более частные вопросы.
yleo
14.09.2021 04:16... индустрия в целом смотрит на это несколько иначе...
Индустрия занимающаяся обеспечением безопасности, либо вынужденная ей заниматься, имеет мнение отличное от прочих «индустрий».
https://www.securitylab.ru/news/519772.php и т.д. и т.п.Давайте я спрошу простую вещь - чем 2 стэка лучше решения, когда у нас весь код в исполняемом файле замаплен с аттрибутами rx, а стэк выделен как rw ?
Если стек адресов возврата отделен от стека используемого для передачи параметров и размещения локальных данных функции (автоматических переменных в терминах С), то ошибка приводящая к записи за пределы локального буфера не позволит переписать адрес возврата (если только не переписать всю память между стеками и т.п.). Аналогично нет возможности непосредственно подготовить в стека адресов возврата массив адресов для ROP.
При использовании ROP код в памяти не переписывается (может быть только для чтения). Инструкции с адресов стека не выполняются (NX не имеет значения). ALSR может быть не эффективен, если через "читающее переполнение" удаётся прочитать кадры стека до генерации ROP-инъекции и т.д. и т.п.
Но это не даёт гарантии, ибо (в общем случае) возможны более сложные многоэтапные атаки, начинающиеся с перезаписи указателей на стеке и/или других данных в других места. Тем не менее, разделение стеков существенно (в разы) затрудняет доведение атак до финала и снижает риски эксплуатации уязвимостей.
В зависимости от вашего ответа я могу подробнее ответить на более частные вопросы.
Давать мне какие-либо ответы и/или пояснения не надо.
amartology
14.09.2021 10:14Индустрия занимающаяся обеспечением безопасности, либо вынужденная ей заниматься, имеет мнение отличное от прочих «индустрий».
Эта индустрия существенно меньше «прочих индустрий», поэтому ее потребности разработчики удовлетворяют не в первую очередь. Вполне обычная ситуация. Тем более, вы сами описали несколько способов обхода проблемы, а значит вам не критично, чтобы эти проблемы решала за вас система команд процессора.
yleo
14.09.2021 12:25Уж извините, но не пишите если не в теме.
Эта индустрия существенно меньше «прочих индустрий»
Относительно небольшой размер индустрии безопасности == Относительно небольшое количество пожарных.
поэтому ее потребности разработчики удовлетворяют не в первую очередь.
Снижение рисков эксплуатации уязвимостей являются потребностью потребителей/пользователей, а не "разработчиков" в индустрии ИБ (для ИБ как-раз наоборот, чем больше потенциальных дыр/угроз, тем больше бюджет).
...вы сами описали несколько способов обхода проблемы,
Не обхода проблемы, а потенциального/гипотетического обхода защиты при наличии других ошибок/недостатков в ПО и/или железе.
Если же под одним из "способов обхода проблемы" подразумеваете смену ABI, то это примерно равнозначно повторному портированию ПО. Соответственно, это должно быть сделано до начала широкого использования архитектуры, либо станет невозможным как в случае с x86.
а значит вам не критично, чтобы эти проблемы решала за вас система команд процессора.
Не "нам", а для безопасности данных/процессов/пользователей.
Не "не критично", а существенно снижает риски, но не даёт полной гарантии, ибо её нельзя дать из-за ненулевой вероятности реализации сложной атаки с участием других ошибок/уязвимостей/недостатков.
Не "решала за нас проблемы", а чтобы система команд не имела очевидных брешей в безопасности, которые в случае с RISC-V заботливо сохранены.
---В целом похоже на ситуацию с прививкам. Озвучиваем "так небезопасно, нужна <прививка>", а в ответ весь набор аргументов антиваксеров.
Armmaster Автор
14.09.2021 15:04+1Давать мне какие-либо ответы и/или пояснения не надо.
Непонятно, зачем тогда вы тут всё это пишите. Тем более спустя столько времени. Ну хорошо, раз вам ответов не надо, я тогда закончу свою мысль, начатую в прошлом посте, а дальше уже сами разбирайтесь.
Собственно, это то, что я ожидал от вас услышать:
Но это не даёт гарантии, ибо (в общем случае) возможны более сложные многоэтапные атаки, начинающиеся с перезаписи указателей на стеке и/или других данных в других места. Тем не менее, разделение стеков существенно (в разы) затрудняет доведение атак до финала и снижает риски эксплуатации уязвимостей
Т.е. разделение стэков усложняет возможность атаки, но не даёт гарантий всё равно. Но точно также работают современные схемы защиты с запретом на исполнение стэка, например. Т.е. они тоже существенно усложняют такого рода атаки. А т.к. они проще в реализации, их и используют, ибо зачем городить огород с разделением стэков, если принципиально это ситуацию не меняет.
И коли на то уж пошло, в Эльбрусе точно также нет полной гарантии от атаки переполнения стэка. Т.к. так или иначе любая машина может считывать данные из стэка данных, которые могут потом попасть в IP. Например, я могу нарисовать схему хоть и трудно исполнимой, но в принципе вполне реальной атаки с переполнением стэка для Эльбруса. Можете поупрожняться и попробовать придумать такую атаку сами.
yleo
14.09.2021 16:53+1Непонятно, зачем тогда вы тут всё это пишите.
Может показаться, что я специально провоцирую Вас выставлять напоказ некомпетентность и "умение" притягивать аргументы за уши (примерно как в вашем крайнем ответе).
Но на самом деле, я даю пояснение к своей позиции/тезисам и отвечаю на те вопросы, которые, как мне кажется, этого заслуживают.
Armmaster Автор
21.09.2021 01:54А почему начиная с Itanium Poulson число инструкций увеличили с 6 до 12 Doubled issue width (from 6 to 12 instructions per cycle) ?
Для повышения перформанса, вестимо. Больше операций в такт - больше потенциальный перф
Начиная с Эльбруса 16С, делают точно тоже самое
Вроде там не меняли количество ALU
В среднем по статистике в коде все равно нет больше 6 инструкций между условными переходами. Это им что-то даст
Это в среднем, а на плавучих циклах это не так. Плюс переходы можно сливать под предикатом в теории
Хотя все равно при компиляции lcc -O4 -fast -march=elbrus-v6, я не вижу в ассеблере широких инструкций больше чем по 6
Ну так там 6 ALU, поэтому и нет больше
Armmaster Автор
21.09.2021 02:3748 это про векторные инструкции. Т.е. они считают 6 fma по 4 операции в векторе: 6x2x4 = 48
Armmaster Автор
21.09.2021 02:40Итаниум намного более продвинутая архитектура, чем Эльбрус. МЦСТ аналог Итаниума будет ещё лет 20 делать, если их деньгами залить. Но даже Итаниум по итогу оказался провальным, т.к. стало понятно, что он проигрывает ОоО по сумме факторов.
neonkainside
10.09.2021 09:33+1а в участники RISC-V (видимо) вообще не считают это проблемой.
А должны? Это головная боль тех, кто делает конкретную реализацию микроархитектуры, а не авторов ISA.
У RISC-V как ISA нет значимых технических/технологических преимуществ при переходе в сегмент высокопроизводительных ЦПУ.
Она в целом не лучше и не хуже остальных RISC ISA. 64-разраядное расширение есть, векторные тоже. А учитывая что внутри даже x86 в некотором роде RISC то проблема становится совсем уж какой то надуманной.
sabaca
09.09.2021 09:16+3первый же конкурент - компания Байкал Электроникс, которая имела нулевой опыт создания процессоров, но зато имела сложности с лицензиями, финансированием, управлением из-за проблем владельца, набила кучу шишек первого продукта, за несколько лет выдала чип, который конкурентен чипам от МЦСТ.
Но ведь Байкал не разрабатывал микроархитектуру, а просто купил готовые ядра. Так что сравнение некорректно.
amartology
09.09.2021 09:47+3Почему некорректно? Результаты работы вполне сравнимы. И там, и там — процессор. А если кто-то решил пойти более сложным путем, а на выходе получил примерно такой же результат — разве это проблема конкурентов?
sabaca
12.09.2021 10:44И там, и там — процессор.
Если так рассуждать, то можно сразу купить готовый процессор. Результат тот же.
А если кто-то решил пойти более сложным путем, а на выходе получил примерно такой же результат — разве это проблема конкурентов?
Здесь уже вопрос целеполагания. Если цель просто любым путем получить процессор то, очевидно, самый короткий и оптимальный путь это купить готовое серийное изделие. Если цель в разработке технологии и получения компетенций в разработке процессоров, то нужно проектировать их самостоятельно, ядро уж точно нужно делать самим, а остальное, на первое время можно и покупать, если на все сразу не хватает ресурсов.
amartology
12.09.2021 22:25Если цель в разработке технологии и получения компетенций в разработке процессоров,
Навыки не могут быть целью. Конечная цель — всегда какой-то продукт. Цель импортозамещения — получить продукты в ситуации, когда «самый короткий и оптимальный путь это купить готовое серийное изделие» не работает по политическим причинам.ядро уж точно нужно делать самим, а остальное, на первое время можно и покупать, если на все сразу не хватает ресурсов.
Так наоборот — именно ядро надо первое время покупать, пока на все сразу не хватает ресурсов
GarretThief
09.09.2021 11:43Я программирую на питоне, поэтому архитектура процессора и компилятор его сишного интерпретатора для меня очень далеки. Но узнать, есть ли разница в скорости исполнения какого-нибудь рандомного скрипта на питоне на эльбрусах, байкалах и тех же интелах похожих характеристик - вот это интересно. Есть ли такие таблички с результатами тестов?
amartology
09.09.2021 12:35+5Для тех, кому лень кликать
Результаты Python на Эльбрусах в сравнении с Core i7 2600 3.4 ГГц:
Эльбрус 2С+ в 30 раз медленнее на 1 поток
Эльбрус 1С+ в 12,5 раз медленнее на 1 поток
Эльбрус 4С в 15,5 раз медленнее на 1 поток
Эльбрус 8С в 9 раз медленнее на 1 поток
Эльбрус 8СВ в 7,8 раз медленнее на 1 поток
Эльбрус 2С+ в 58 раз медленнее на всех потоках
Эльбрус 1С+ в 25 раз медленнее на всех потоках
Эльбрус 4С в 13,5 раз медленнее на всех потоках
Эльбрус 8С в 4,2 раза медленнее на всех потоках
Эльбрус 8СВ в 3,8 раза медленнее на всех потоках
Civil
09.09.2021 13:13+1Плюс на x86 иногда можно взять вместо cpython'а pypy и получить небольшой прирост скорости, а вот на Эльбрус его никто не портировал. Да, юз-кейс не очень распространенный, но тем не менее местами в production'е используется (соответственно разницу можно еще примерно на 10 умножать если брать pypy @ x86 и cpython на эльбрусе).
Suor
10.09.2021 04:47Pypy почти никогда взять не получается, ибо какие-то зависимости на нем работать не будут. Мне вот интересно можно ли cython использовать с Эльбрусом? И какой прирост будет?
Civil
10.09.2021 11:39+1Pypy почти никогда взять не получается, ибо какие-то зависимости на нем работать не будут.
У меня опыт обратный, почти что ни имело смысл брать - все работало адекватно и местами давало нужное время чтобы сделать более правильное решение. Так что скорее зависит от области и конкретных задач.
Мне вот интересно можно ли cython использовать с Эльбрусом?
Cython же, если я все еще правильно помню, это чуть ли не путь по-умолчанию для создания C-extention'ов для питона и тот же SciPy на нем (а еще все биндинги к сишным библиотекам, которые народ делал до рассвета cffi)? Так что если я помню правильно то было бы странно видеть проблемы в этом месте и было бы еще страннее заявлять наличие работающего питона если cython не работает.
Arioch
10.09.2021 16:14Тогда уж портировать HotSpot JVM и jython
Кроме того, надо помнить, что у CPython используется One True Single Global Lock на все мало-мальски чувствительные операции.
При этом как минимум два человека делали многопоточный Питон с раздельными "маленькими" блокировками. Но это портило производительность на малопоточных программах и их правки откатывали.
Учитывая же VLIW - блокировка конвейера на глобальном локе блокирует сразу все "мини-инструкции" всех "широких бандлов". В отличие от OoO, где команды "узкие" и даже среди них можно найти хотя бы некоторые, независящие от этого лока, которые можно пропустить "вперёд очереди".
И вообще интересно, как будет в случае Эльбруса смотреться спинлок-цикл, и его взаимодействие с такими же спинлок-циклами по тому же барьеру на соседних ядрах? Если ядро не способно просто само для себе вовремя загрузить значение из памяти, без помощи nop'ов от компилятора, тот как можно надеяться на эффективное разруливание конкуренции за атомарный барьер нескольких ядер/потоков?Вообще, интересно даже стало, как там в целом у VLIWов с атомарными инструкциями...
Warchylde
10.09.2021 11:39а мне кажется достаточно одной статьи про эльбрус, большего не нужно,
учитывая распространенность и востребованность...
byman
10.09.2021 12:44+2Я бы с удовольствием узнал, что ОоО ядро от Синтакор делает цикл
.L13: lw a4,-4(a5) ble a4,a3,.L17 sw a4,0(a5) sw a3,-4(a5) addi a5,a5,-4 bne a0,a5,.L13не хуже Эльбруса и Интела. Думаю у будущей надежды российской электроники есть хотя бы одно рабочее ядро чтобы проверить эту горе-сортировку :)
amartology
10.09.2021 12:56+2Зачем вам ждать милости от Синтакора? У вас в Миландре свои RISC-V есть, на них и проверяйте)
byman
10.09.2021 13:03Отличная мысль. Если у Миландра есть ОоО ядро , то и их результат тоже было бы приятно увидеть :)
byman
10.09.2021 13:11Все RISC/CISC архитектуры по сути своей одинаковы. Вопрос только в том, хватит ли технических компетенций у конкретного коллектива разработчиков, чтобы решить эту задачу.
мне понравилась эта ваша мысль т.к. я склонен считать, что не только выбор архитектуры имеет значение, но и прикрепленный к архитектуре человек :) Отсюда и желание поскорее увидеть результат других работников.
Armmaster Автор
10.09.2021 13:19Это безусловно, но это общий принцип, работающий в любой области человеческой деятельности. Мы всё же обсуждаем здесь процессорную специфику. А поскорее пощупать результаты работы других коллективов конечно же хочется. Даёшь больше отечественных процессоров, хороших и разных!))
byman
10.09.2021 15:30+7В качестве начальной точки отсчета могу предложить результат работы собственного варианта RISC-V. Обычный in-order , 1 или иногда 2 команды за такт. 9 ступеней конвейера. R32GC. 30 человеко дней работы коллектива из одного человека в течение новогодних и майских каникул в рамках расширения кругозора и собственной компетенции. Затраты - 0 рублей 0 копеек.
Результат работы цикла сортировки 5 тактов на цикл. Стандартный компилятор. -О2. Лучше чем у Эльбруса, если неправильно подбирать ему опции компиляции :) Временная диаграмма работы прилагается. Кто обгонит - тому проставляю чай.
Brak0del
10.09.2021 15:54+3Кто обгонит
Ну я в деле, как раз risc-v на hdl планирую и по тем же причинам :) А ваши результаты где-то можно детальнее глянуть (получившиеся частоты, занятые ресурсы, модель плис, если это на плис и т.д.), чтоб было к чему стремиться?
Armmaster Автор
21.09.2021 00:49+3МЦСТ пользовалось тем, что 20 лет они были де факто единственными, кто делал процы с прицелом на гражданский high-end рынок (а коллектив там пришёл с ИТМиВТ, т.е. это ещё несколько десятилетий опыта). 10 лет назад появился Байкал и первые же их процессоры уже составили конкуренцию. Сейчас появились Syntacore, Ядро, Cloudbear и вой пошёл на всю Россию - спасите, хулиганы рынка решают. Вот и вся история.
Civil
21.09.2021 00:51Не просто "хулиганы рынка лишают", а явные попытки дискредитировать идеи конкурентов на базе вырванных из контекста цитат (там товарищ Трушкин в телеграмме мини-опус в формате "ну вы понимаете" писал как раз недавно, про OpenPower и risc-v, такой что за это прям стыдно)
Armmaster Автор
21.09.2021 00:57Ну они довыступались до того, что мне пришлось взяться за перо. Настолько их заявления не этичны и непрофессиональны.
Civil
21.09.2021 01:16Люди в принципе, пусть и не очень много, но влияют на то что происходит. Поэтому чем больше правильных вопросов задается ко всем, тем больше шанс что чаша весов качнется в сторону более технически адекватного решения.
Civil
21.09.2021 12:28Вопрос кстати спорный. Коммерческие компании более жизнеспособны за счет большего рынка сбыта, например. А госконтракты вообще палка о двух концах и не всегда компании рады что в них ввязываются.
Тем более сейчас как раз идет речь о создании процессоров для импортозамещения и борьбы за госконтракты.
Civil
21.09.2021 02:07Может конечно, но также и не со стартапом, а с компанией которая не очень взлетает.
Civil
21.09.2021 01:18Не совсем понимаю как Гипотеза Коллатца относится к развитию решений, если честно.
А про продукт - так они и развивают собственно говоря. Просто как продукты стали достаточно взрослые и о них начали говорить, то другая сторона решила что ей надо начать защищать свои контракты (интересно, с чего бы это, если у них такие сильные позиции?)
amartology
21.09.2021 12:12Если сами Syntacore и Cloudbear уверенны в своем продукте, то пусть берут кредит в банке и развиваются.
Они собственно так и делают. Но как только они об этом объявили, на них пошла волна «да ничего они не сделают никогда» и «да ваш риск5 — неспособное говно».Civil
21.09.2021 12:30Но как только они об этом объявили, на них пошла волна «да ничего они не сделают никогда» и «да ваш риск5 — неспособное говно».
Сейчас дно упорно пробивают новой риторикой: "да это все для инклюзивности, ну вы понели, да?" (последний на текущий момент пост в официальном телеграмм-канале МЦСТ)
JerleShannara
21.09.2021 16:05+1Собственно с мишками пообщался на ЧипЭкспо, у ребят вполне себе готовая и живая IP корка, которая для текущей реализации на FPGA вполне неплохо крутила линукс и кваку, при том, что они её не планировали под такое использование вообще.
Civil
21.09.2021 00:31Имея IP ядра от Cloudbear, этого не получиться.
Не менее чем с Эльбрусами. Собственно шансов у Syntacore и Cloudbear чуть больше на практике. По сути они за пару лет сделали то, на что МЦСТ потратили 30 лет, это, кажется, о чем-то да говорит.
anonymous
00.00.0000 00:00Armmaster Автор
20.09.2021 22:31+1С этим,я думаю, никто не спорит. Суть обсуждения в том, каким он должен быть.
Далее:
В России ограниченный ресурс для разработки микроархитектуры с динамическим распараллеливанием инструкций, Россия просто не потянет и никогда не сможет отладить такой процессор,
Это не так. Это вполне подъёмная задача.
или свой VLIW процессор принципиально в 5 раз медленне с непонятным для людей ассемблером и вечной ручной оптимизацией приложений, или ничего
Это ложная дихотомия. Как я уже сказал, нет никаких принципиальных проблем сделать нормальный ОоО проц.
прийдется разрабатывать свою микроархитектуру с динамическим распараллеливанием инструкций, что в свою очередь невозможно - см. пункт 2.
Это возможно и более того, уже делается.
Купить лицензию на ARM с уже готовой микроархитектурой с динамическим распараллеливанием инструкций (как у Apple), не хватит денег
Эта лицензия легко продаётся. У Байкала она есть, например.
Проблема в том, что МЦСТ закрыл все, что только можно закрыть, не раздает компиляторы и эмуляторы, не продает машины
Это уже большой отдельный разговор - методы ведения бизнеса от МЦСТ. Очевидно, что даже при отсутствии технических проблем, такой подход оставляет мало шансов для широкого распространения процессора Эльбрус.
Если это не измениться, то эльбрус умрет, так и не родившись
Он уже умер. Мои статьи никак на этот факт не влияют, а лишь объясняют - почему.
anonymous
00.00.0000 00:00Civil
20.09.2021 23:18+1Мнение интересное, но есть пара фактических ошибок:
В России ограниченный ресурс для разработки микроархитектуры с динамическим распараллеливанием инструкций, Россия просто не потянет и никогда не сможет отладить такой процессор
Эльбрус на текущий момент чуть ли не более сложный, чем многие OoO процессоры. Там в общем свои проблемы возникают чтобы архитектура как-то масштабировалась, и это все решается не так чтоб просто. Посмотрите на принципиальную его схему. В общем нету там "в 100 раз проще". Увы. К тому же людей способных написать уникальный быстрый компилятор очень не факт что больше, чем тех кто способен разработать быстрый процессор.
то все равно, чтобы быть на хорошем уровне производительности, прийдется разрабатывать свою микроархитектуру с динамическим распараллеливанием инструкций, что в свою очередь невозможно - см. пункт 2. Купить лицензию на ARM с уже готовой микроархитектурой с динамическим распараллеливанием инструкций (как у Apple), не хватит денег, не позволит гордость, и это уже не будет своим процессором - противоречит пункту 1.
Посмотрите на Cloudbear с их OoO risc-v, посмотрите на то что в презентациях показывал Syntacore в 2018 году.
Чтобы в типичных юзерских задачах обогнать Эльбрус не нужна мегапроизводительность, достаточно иметь что-то уровня Cortex-A72 на той же частоте, а это очень достижимо (а проблемы в плавучке решались бы хорошо проработанным внешним акселератором, раз уж все равно руками оптимизировать, который, кстати, был бы как раз относительно простым).
Касательно же ARM и лицензирования - производительности Apple M1 у них конечно нет, но Neoverse N1/N2 лицензировать вполне по силам и по кошельку было бы. Собственно у Байкала следующие продукты будут на Cortex-A73 и позже на A75, они конечно помедленее, но если выйдут в срок то отставание по микроархитектуре от текущего bleeding edge сильно сократят. Впрочем посмотрите сравнение результатов Эльбруса с теми же A73 или A75 в имеющихся известных тестах. Там опять же не так все плохо.
и никаких перепалок не будет.
Перепалки идут в первую очередь от неверного позиционирования. Процессор для военных? Да пожалуйста, никого не волнует ни закрытость, ни скорость (это проблемы заказчика). А вот как только он пошел в "да мы сейчас все импортозаместим на него" так начинаются проблемы, потому что он в пользовательских задачах уступает телефону 5-и летней давности.
Vedomir
21.09.2021 12:43+1Вот кстати интересный вопрос по поводу тактовой частоты — Itanium на 32нм достиг 2.66 ГГц не говорит ли это о большем частотном потенциале VLIW чем указано в статье?
Civil
21.09.2021 13:15Не говорит. На том же самом 32нм техпроцессе Core i7 EE достигали 4 ГГц (не-HEDT Core i7 достигали 3.9 ГГц, Xeon'ы - 4.0 если E3, 3.9 если E5)
Vedomir
21.09.2021 15:27Тем не менее разрыв уже гораздо меньше чем у Эльбрус с его 1.5. А рост тактовой частоты с тех пор сильно замедлился, если вообще не остановился, у тех же Epyc на 7 нм максимальная частота те же 4 ГГц, а базовая в районе 2-3. У Intel на 14 нм чуть повыше но не принципально.
Armmaster Автор
21.09.2021 15:42+2Я же для этого специально привёл табличку в самой первой статье, где процы VLIW/не VLIW от одних производителей и на одних нанометрах. И там видно, насколько vliw'ы проигрывают. Та же МЦСТшная серия R (Спарковских процессоров) частоту имеет бОльшую, хотя это гадкий утёнок всегда был, пилили вполноги, а основные силы шли в Эльбрус. Там есть достаточно фундаментальные проблемы, почему это так, но без глубоких специальных знаний это непросто воспринять. Поэтому мне кажется такая табличка по факту намного показательнее для не экспертов в области
Vedomir
21.09.2021 16:09+1Ну собственно из нее тоже видно что у VLIW 2,66 против 3,1 на всех ядрах у аналогичного по ядрам x86 (3.8 насколько я понимаю в разгоне на одно ядро). Настолько ли это принципиальное отличие? И поравдывает ли это утверждение из статьи «Я могу оценить эту цифру в диапазоне 2.5-3 ГГц.» Ведь если VLIW перевести допустим на 7 нм то и частота тоже повысится с этих 2,66 на 32 нм. Отставание конкретно Эльбруса тут вполне можно объяснить нехваткой ресурсов его разработчиков.
Не то что бы я был сторонником или фанатом Эльбрусов и VLIW, скорее наоборот, мне это привели как аргументы в другом месте и я задумался об обоснованности конкретно этого пункта статьи.Armmaster Автор
21.09.2021 17:09+2что у VLIW 2,66 против 3,1 на всех ядрах у аналогичного по ядрам x86 (3.8 насколько я понимаю в разгоне на одно ядро)
Тут важный момент в том, что ядро x86 разгоняется до 3.8, а на 3.1 для всех ядер чип работает из-за ограничений по пауэру. В то же время для Итаниума 2.66 это максимум, который выжали инженеры, т.е. там не в пауэр упирались.
Ведь если VLIW перевести допустим на 7 нм то и частота тоже повысится с этих 2,66 на 32 нм
Частота сейчас просто так уже не повышается с переходом на новый техпроцесс. Это видно на примере стагнации роста частоты на тех же x86.
Отставание конкретно Эльбруса тут вполне можно объяснить нехваткой ресурсов его разработчиков
Это универсальная отмазка, которой можно объяснить любые недостатки.
Можно перейти к обсуждению чуть более технических моментов, объясняющих, почему на Эльбрусе частота принципиально ниже. Например, там 8 стадий конвейера (и это нельзя поменять без полной переделки архитектуры). А в современных ОоО процессорах порядка 20. Почему во втором случае частота получается в среднем выше, надеюсь, понятно.
shcher
21.09.2021 17:218 стадий конвейера - очередной миф, почему-то активно всеми распространяемый. Для целочисленной операции 13 стадий и вряд ли найдётся операция с меньшим числом. Вот официальный источник: http://mcst.ru/files/60f6d2/1adece/616a5e/eb0728/tvgi.431281.028re.pdf
Armmaster Автор
21.09.2021 17:49Да, тут с замечанием согласен. Просто в куче презентаций (от того же Бабаяна, например) и даже учебных материалах говорится про 8-ми стадийный конвейер, поэтому мне эта цифра в память запала. Но сейчас пригляделся - 8-тактов это до E0 , а дальше идут стадии для своих пайплайнов.
Но сути проблемы это не меняет. Т.е. увеличивать количество стадий нельзя просто так. Проблема кучи портов для передачи результатов через байпассы тоже остаётся (и насколько я понимаю, она ключевая для роста тактовой частоты)
Vedomir
21.09.2021 18:24+1Тут важный момент в том, что ядро x86 разгоняется до 3.8, а на 3.1 для всех ядер чип работает из-за ограничений по пауэру. В то же время для Итаниума 2.66 это максимум, который выжали инженеры, т.е. там не в пауэр упирались.
Вот это момент, который явно нуждается в гораздо более подробном раскрытии. Так у Itanium энергопотребление даже больше чему у Xeon (170 против 150) и невольно возникает вопрос — может он тоже просто по энергопотреблению зашкалил?
Я не специалист по проектированию процессоров, но краткая логика из статьи про «У Эльбрус 1,5ГГц на 28 нм и следовательно больше 2,5 — 3 быть не может» не выглядит убедительной для стороннего наблюдателя. Если у Эльбрусов теоретический предел в два раза выше результата на 32 нм, то почему у VLIW вообще теоретический предел не может быть выше в два раза результата Itanium на 32 нм?
И особенно с учетом того что 5ГГц на x86 — это результат для одного ядра, а при загрузке всех ядер получаются цифры близкие к 3-3,5.
Я предполагаю, что скорее всего вы что-то иное имели в виду и там какие-то технические обоснования, но со стороны для неподготовленного читателя выглядит именно так.Civil
21.09.2021 18:33+1Я попробовал примерно обрисовать проблемы в соседней ветке. Не совсем точно но все таки (повторю оттуда - точное объяснение это около трети курса цифровой схемотехники и еще немного знаний из смежных областей, впрочем можете попробовать приобрести какую-то часть самостоятельно - для этого хватит FPGA и желания поедалть на нем всякого разного, например попроходить курсы по дизайну микросхем, благо их в открытом доступе полно)
К тому же про 3-3.5 ГГц на все ядра вы не совсем правы (я тоже пояснил почему не стоит смотреть на базовую частоту у современных процессоров). Хотя тут повторюсь - вот у меня Ryzen 3900X в десктопе, у него базовая 3.8, буст 4.6. На все ядра он работает на 4.2 и на практике до базовой никогда не опускается. Без какого либо разгона и модификаций (если заморочится можно поднять частоту на все ядра еще чуть-чуть). У интелов современных также - у десктопных i9-10900k официальный all-core boost - 4.9 ГГц, при Turbo в 5.3, а базовая при этом 3.7 (такие параметры если мат плата умеет в thermal velocity boost и вся система имеет хорошую систему охлаждения)
Параметр базовой частоты в первую очередь важен для систем лимитированных чем-либо внешним (например системой охлаждения, притом как процессора, так и системы питания на мат плате или просто зарезанными лимитами на общее энергопотребление системы). И второй момент тут юридический - падение частоты под нагрузкой ниже базовой являются гарантийным случаем, в то время как Turbo частота в 5.3 ГГц жарким летом в плохопроветриваемом помещении на штатном кулере - не гарантируется.
Armmaster Автор
21.09.2021 18:36+1Вот это момент, который явно нуждается в гораздо более подробном раскрытии
Ну да. Я много раз про это написал, что тут надо углубляться в технику. Причём хорошо бы это уже сделал человек, непосредственно занимавшийся вытягиванием частоты у VLIW. Всё же мой стек компетенций лежит выше, я не настолько хорошо понимаю эту проблему, чтобы подробно объяснять её другим.
но краткая логика из статьи про «У Эльбрус 1,5ГГц на 28 нм и следовательно больше 2,5 — 3 быть не может»
Всё же в статье нет такой логики. В статье логика в том, что мы сравниваем аналогичные VLIW и RISC/CISC системы и видим, что VLIW по частоте уступает. На базе этого (и со сссылкой на нераскрытые технические причины этого) делается утверждение, что по частотам VLIW проигрывает.
Civil
21.09.2021 17:31+2Тем не менее разрыв уже гораздо меньше чем у Эльбрус с его 1.5.
Тут тоже есть своя цена - вы не забывайте о том что TDP Itanium'а практически вдвое больше (170 Вт против ~90-100 у Эльбруса). Это как минимум. Во вторых тут опыт и умение инженеров Intel, которые архитектуру вылизывали максимально.
если вообще не остановился, у тех же Epyc на 7 нм максимальная частота те же 4 ГГц, а базовая в районе 2-3
Не очень понятно почему Вы взяли не более близкий по параметрам Ryzen 5950X (с его теоретической частотой в 4.9 и практическими 5.05-5.1 на 1 ядро без разгона со стороны пользователя), а Epyc? Ну или почему не посмотрели на тот же Xeon W-1390P (5.3 GHz - альтернативно можно взять Core i9-10900k, если конечно хочется) как доказательство того, что частота меняется не сильно?
По поводу частоты важным является ответ на вопрос "что же ее ограничивает?" - к сожалению тут полноценный ответ это примерно треть курса цифровой схемотехники с хорошим шансом влезть в соседствующие разделы физики (физики полупроводников, например, но не только). Очень упрощенно - ограничивающими факторами являются и тепловыделение и дизайн схем. Не любая схема у которой есть пространство по TDP сможет разогнаться до больших частот (простым языком можно сослаться на английскую вики).
И в связи с этим начинаются приколы (очень упрощенно) - время выполнения инструкции будет ограничено самым медленным куском команды (в то время как OoO процессор теоретически может загрузить), чем более параллельная схема тем больше сложности идет в шедулер, тем меньше получится частота (1 цикл работы для всей схемы будет занимать больше времени), длинное слово повышает тербования к подсистеме кэша и памяти (чем менее плотный код будет, тем важнее будет подсистема памяти), большой кэш тоже сложнее масштабировать по частоте (притом первого уровня сложнее). И чем больше проблем из списка ты будешь решать тем ближе придешь к OoO RISC процессору.
В то же время для x86 у тебя ограничение по питанию (кстати не очень верно брать просто базовую частоту, у каждого CPU своя формула в зависимости от типов нагрузки и типа процессора - некоторые десктопные могут держать буст частоту на всех ядрах при достаточном охлаждении, или могут сбрасывать частоты только в каких-то определенных задачах, например SIMD нагрузка, но обычно тоже не до базовой частоты).
Vedomir
21.09.2021 18:28Не очень понятно почему Вы взяли не более близкий по параметрам Ryzen 5950X (с его теоретической частотой в 4.9 и практическими 5.05-5.1 на 1 ядро без разгона со стороны пользователя), а Epyc? Ну или почему не посмотрели на тот же Xeon W-1390P (5.3 GHz — альтернативно можно взять Core i9-10900k, если конечно хочется) как доказательство того, что частота меняется не сильно?
Сравнивать одноядерную загрузку с многоядерной тоже не совсем корректно. Со стороны можно задаться вопросом — если Эльбрус ограничен архитектурой в 3ГГц (цифра из статьи) а x86 ограничен уже тепловыделением на многоядерную загрузку в районе 3,5 то так ли велика разница?
Само собой это не касается других проблем VLIW, это уже отдельный разговор.Civil
21.09.2021 18:44+1а x86 ограничен уже тепловыделением на многоядерную загрузку в районе 3,5 то так ли велика разница?
Вы делаете мне грустно тем, что проигнорировали важные вопросы и примерно 3/4 комментария, в том числе на этом фокусирующихся.
Перечитайте еще раз, пожалуйста, что я написал. Более того - я совсем не понимаю откуда вы берете упорно 3.5 ГГц, когда для Intel'а есть понятия Single core boost, All Core boost, AVX2 Boost, AVX512 Boost и все это даст разный набор множителей в разных ситуациях, притом ни в одной из них он не опустится до base.
OpenA
21.09.2021 20:11-3Высокие тактовые частоты достигаются более детальным уровнем проектирования микросхемы (full custom design). Никакие архитектуры здесь вообще непричем. На примере процессоров ARM нетрудно заметить что на тех же 16nm типичные частоты у них ~2Ггц, на 7-5нм уже подобрались к 3Ггц. И эльбрус и доступные на рынке ARM процессоры делаются из стандартных ячеек/блоков фабрики, а так высоких частот не достичь.
Civil
21.09.2021 20:40+1Никакие архитектуры здесь вообще непричем
Кажется, тут нужно предоставить доказательство этому утверждению.
Vedomir
21.09.2021 20:46Ну ARM делаются под совершенно другое энергопотребление, раз так в 10 ниже как минимум.
Странно что здесь никто не вспомнил новые процессоры от IBM с базовой частотой 5ГГцOpenA
23.09.2021 08:32-1ARM делаются под совершенно другое энергопотребление, раз так в 10 ниже
Они это достигают размером самого ядра, которое даже на крошечном по десктопным меркам кристалле 10% занимает если не меньше. В армах нет сложных технологий отключения кэшей/конвееров как в интелах, и этим они с эльбрусом одинаковые, у них есть рабочие частоты и рабочее напряжение 0.8-1.2V, которое даже на старых 45нм интелах позволяло работать на 1,5-3,0Ггц а на армах и эльбрусах только 800-1500Мгц на более тонких техпроцессах. Мотивация впрочем у них разная, у эльбрусов маленькие бюджеты и сроки, можно сказать чисто чтоб люди на работу ходили, студентов в средах проектирования работать учили, и раз в год-два чем то отчитывались сдавали "изделие" которое положат на полку и дадут задание на новое. У армов же рыночек порешал что дешевые массовые чипы за 10-20 долларов предпочтительнее более проработанных за 40-60 долларов. Вот и всё.
никто не вспомнил новые процессоры от IBM с базовой частотой 5ГГц
Еще в бородатые времена читал на Tom's Hardware (а может кстати и на хабре, не помню уже) что наращивание частоты упирается в скорость переключения транзисторов, 5Ггц для них предел и IBM работает над созданием новых которые позволят наращивать дальше вплоть до 10Ггц.
Но в статье пишут про 7nm Samsung так что врядли это та самая революция которую нам обещали. Ну и конечно же 960Мб L4 и 256Мб L3 впечатляет.Civil
23.09.2021 10:49Вот и всё.
Когда утверждаете что-то, расходящееся с общепринятым пониманием, неплохо бы приводить доказательства собственным словам. Впрочем вы еще про прошлый пост не ответили про независимость частот от архитектур мне и соседнему комментатору про готовые блоки.
Armmaster Автор
23.09.2021 14:57+1наращивание частоты упирается в скорость переключения транзисторов, 5Ггц для них предел
Для силиконовых транзисторов скорость переключения составляет десятки, а то и за сотню Гигагерц (в зависимости от). А всякие SiGe вообще дают ещё больше, но это будем считать экзотика. Наращивание частоты упирается не только в скорость переключения, а сложность логики и как следствие количество этих самых переключений, которые надо надёжно осуществить за такт. И с этим как раз у VLIW проблема - есть критические цепи, которые не позволяют увеличивать частоту
Я же постоянно привожу простой вопрос "на подумать" - почему Мцстшный спарк с первого раза на 28нм 2ГГц, а Эльбрус на тех же 28нм 1.5ГГц, и это со второго раза (с первого 1.2 ГГц) ? Вот именно поэтому
OpenA
24.09.2021 09:02-1у VLIW проблема - есть критические цепи, которые не позволяют увеличивать частоту
АМД видимо не знали про критические цепи, поэтому у их видеокарт на VLIW частоты были раза этак в 2-3 выше чем у конкурента. И это же не значит что у нвидиа архитектура не позволяла сделать частоты выше, им теплопакет не позволял и жирный размер субядер (у амд под 500-1k на кристалл влазило, у нвидии сотня, максимум две). Пример АМД показателен еще и тем, что первые поколения этой архитектуры (R2000/3000) не давали впечатляющих результатов мягко говоря, но амд продолжала работать дорабатывать архитектуру, кодогенератор, пока в итоге не оказалось что middle-end радеон на уровне или даже обгоняет топ нвидии, и разрыв этот сохранялся вплоть до перехода на GCN. От влив ушли потому что для GPGPU старые ядра не подходили, создавать новый VLIW писать под него и добавлять поддержку в свободное ПО это конечно весело и увлекательно, но амд живет в условиях рынка который диктует свои правила.
Я же постоянно привожу простой вопрос "на подумать" - почему Мцстшный спарк с первого раза на 28нм 2ГГц,
Ну он во первых относится к поколению Э-8СВ на что как бы намекает контроллер памяти DDR4-2400 и дата выхода 2019г. Ну а в пятых-десятых это гораздо более простой и дохленький процессор уровня какого нибудь Cortex-A53 в китайфонах если не проще, при этом 1600Мгц версия 25Вт, а 2Ггц 35Вт вот и весь секрет. Кстати о кортексах - а какие критические цепи байкалу помешали сделать нормальные частоты "не как у эльбруса"? Сослаться на экономию энергии не выйдет ибо 8ядер и 10Гбит эзернет явно не для планшетов решение. Про обещаный серверный 2Ггц RISC-V на 16нм через пять лет вообще промолчу.
amartology
24.09.2021 11:13АМД видимо не знали про критические цепи, поэтому у их видеокарт на VLIW частоты были раза этак в 2-3 выше чем у конкурента.
Вы же понимаете, что у видеокарты гораздо более предсказуемый поток инструкций, и там вероятность сброса длинного конвейера радикально меньше, чем у процессора общего назначения? В видеокарте-VLIW наращивать глубину конвейера действительно ничего не мешает.Про обещаный серверный 2Ггц RISC-V на 16нм через пять лет вообще промолчу.
А в чем проблема? Такие штуки наверное пять или шесть стартапов по всему миру собираются сделать к этому времени.
Вот буквально вчера пришли новости от том, что европейский университетский серверный проект получил первые сэмплы RISC-V чипов на 1 ГГц на 28 нм процессе.
Civil
24.09.2021 12:22Вы же понимаете, что у видеокарты гораздо более предсказуемый поток инструкций, и там вероятность сброса длинного конвейера радикально меньше, чем у процессора общего назначения? В видеокарте-VLIW наращивать глубину конвейера действительно ничего не мешает.
Там человек фактически неправ даже (есть разница в 2 раза, но в пользу RISC чипа от nVidia, а не как он пытается выставить). Так что и дальше аргументы у него все такого же уровня, к сожалению.
Civil
24.09.2021 11:51АМД видимо не знали про критические цепи, поэтому у их видеокарт на VLIW частоты были раза этак в 2-3 выше чем у конкурента.
Вы доказательство то приводите, а то я открыл табличку с характеристиками карт и вижу что R2900 XTX - по Core Clock'ам обгоняли на 10%, а по Shader Clock'у отставали в 2 с небольшим раза от GeForce 8800 Ultra (напомню что VLIWовость в первую очередь относилась к унифицированным шейдерным ядрам, а не к TMU и прочей обвязке, а тут у nVidia в те времена частоты были 1.5 ГГц, в то время как у AMD частота была 743 МГц), имея при этом более современный техпроцесс (80нм TSMC против 90нм TSMC у nVidia).
Отлистываю потом в последнее поколение - fermi у нвидии (GTX 580) 772 МГц частоту ядра имел (по прежнему для шейдерных процессоров нужно было умножать на 2, то есть 1544 МГц в итоге), у AMD их Terascale - 880 МГц (6970). Как-то, извининте, на 2-3 раза совсем не тянет. Так что, извольте, не вводить людей в заблуждение. В последнем поколении техпроцесс был одинаковый - 40 нм и там и там.
Пример АМД показателен еще и тем, что первые поколения этой архитектуры (R2000/3000) не давали впечатляющих результатов мягко говоря, но амд продолжала работать дорабатывать архитектуру, кодогенератор, пока в итоге не оказалось что middle-end радеон на уровне или даже обгоняет топ нвидии, и разрыв этот сохранялся вплоть до перехода на GCN
Тут Вы фактически тоже не правы. AMDшный 6970 который был одночиповым топом, отставал почти во всех играх где была высокая шейдерная нагрузка от GTX 580 (не сильно, процентов на 5, но тем не менее).
Почитайте тесты тех (к сожалению на ixbt графики на флеше, но выводы те же что у anandtech) времен. Его плюс был цена - которая была между GTX 570 и GTX 580, но при этом карта позиционировалась как топ, а на топ она недотягивала (не забываем что в моде были еще и двухчиповые топы в те времена, но на них можно не смотреть в контексте разговора про частоты)
Про Compute вы тоже не совсем правы. В OpenCL средние карты от AMD обгоняли топы nVidia, это как раз одна из причин почему nVidia поработала позже над Kepler и Maxwell именно в разрезе Compute производительности. Но вот реализовать пиковые 2.7 ТФлопс на амдшках было крайне сложно и в реальном мире получалось как попало все (были тесты как по ссылке где AMD рвали нвидию в клочья и где производительность была близка к теоретически достижимой, но в ряде тестов эффективность архитектуры заметно падала и они начинали резко отставать от нвидии).
Давайте Вы все таки возьмете за правило давать доказательства своих слов, ладно? А то пока что вы тотально ошибаетесь в каждом посте за последние несколько дней.
что у нвидиа архитектура не позволяла сделать частоты выше
Опять же - кажется это Ваша задача доказать что это так. Пока у всех Tesla/Fermi частоты были порядка 600-800 МГц (удвоенные для шейдерных процессоров соответственно) и даже разгон не позволял прям принципиально поменять картину: игнорируя TDP стабильная работа была возможна на 850-860 МГц при хорошем охлаждении и без повышения напряжения на чипе. В свете этого - мне кажется нужно доказательство что архитектура позволяла больше.
От влив ушли потому что для GPGPU старые ядра не подходили
От VLIW ушли потому что на бумаге он был крут, и если разработчик действительно заморочился и писал на AMD IL то получался хороший результат (по сути ручная оптимизация кода так как ближе к железу чем AMD IL не было возможности опуститься). Но людям хотелось портируемости решений, а значит языки более высокого уровня, а вот код просто скомпилированный выполнялся почему-то не очень эффективно, особенно если там было много ветвлений (а это как раз то время когда начался активный переход на DX 10 и 11, с более сложными шейдерами, в том числе и появление вычислительных шейдеров в DirectX сказалось на развитии карт). То есть причины те же что автор озвучивает в статье против General Purpose CPU для VLIWов - без ручной оптимизации получается фигня какая-то.
amartology
22.09.2021 09:44+2Высокие тактовые частоты достигаются более детальным уровнем проектирования микросхемы (full custom design). Никакие архитектуры здесь вообще непричем.
Высокие тактовые частоты делаются не кастомным дизайном, а более длинным конвейером, который вполне себе имеет отношение к микроархитектуре и к тому, что загрузить длинный конвейер командами в RISC довольно просто, а во VLIW гораздо сложнее. Именно поэтому делать очень длинные конвейеры во VLIW бессмысленно, и поэтому же не получается поднять тактовую частоту.И эльбрус делаются из стандартных ячеек/блоков фабрики
погодите, так они что же, покупают у фабрики RTL-код своих ядер? Вам самому не смешно такое писать?
Gordon01
На одном дыхании. Просто великолепно.
Одно беспокоит: про неудачи в космосе говорить запретили, как бы после таких статей не запретили говорить о неудачах в процессорах.
redlynx
Интересно другое - если @alexanius настолько не разбирается в теме обсуждения - зачем он вообще писал на такую горячую тему.
Armmaster Автор
Далеко не всегда люди могут адекватно оценить свой уровень компетентности. Дело в том, что в МЦСТ большинство сотрудников не имеют опыта работа где-либо, кроме МЦСТ. Это приводит к крайне узкому восприятию реальности. Алексей просто не имеет серьёзного опыта работы с современными OoO процессорами. Поэтому по сути вся его статья - это рассуждения про Эльбрус. Но я же писал не просто про Эльбрус, а про то, что такой подход заведомо хуже RISC/CISC. А насколько такой подход лучше Алексей просто не осознал ещё - банально не сталкивался. Кстати надеюсь, данная статья в этом поможет
SerjV
Бери шире - запретить говорить о любых неудачах в импортозамещении!
С них, блин, станется действовать по принципу "если о проблеме никто не говорить, значит - её нет"!
zhellion
Для большинства так и есть. Я вот, например, только из статей могу узнать о проблеме. А если статей не будет, я с этим не работаю, для меня проблем не будет, пока эту технологию повсеместно не введут и не придется глотнуть по полной...
MisterN
Где запретили говорить о неудачах в космосе?
amartology
Проект указа ФСБ «Об утверждении Перечня сведений в области военной, военно-технической деятельности Российской Федерации, которые при их получении иностранным государством, его государственными органами, международной или иностранной организацией, иностранными гражданами или лицами без гражданства могут быть использованы против безопасности Российской Федерации», являющегося подзаконным актом к закону о просветительской деятельности.
Пока только проект, но все шансы быть подписанным у него есть.
MisterN
Это касается работников Роскосмоса, или сторонние наблюдатели не могут опубликовать статью по сведениям из Роскосмосом лично открытых источников?
amartology
Это касается кого угодно. В том числе нельзя будет делать перепосты официальной информации от Роскосмоса, если они содержат «Сведения о проблемах, в том числе финансово-экономических, сдерживающих развитие»
wataru
Ну, у нас же судят за разглашение государственной тайны не имеющих к ней допуска людей? Так и тут. Роскосмос спокойно что-то напишет, а потом какого-нибудь несчастного, перепечатывающего эту новость во вконтактике, осудят. Палки-то фсб-шникам тоже надо как-то зарабатывать. Плюс лишний способ всяких недовольных гонять.
tsypanov
Если вы про Грабовского, то он, будучи сотрудником Центра геодезии и картографии по меньшей знал, чтО он продаёт. И справедливости ради, суд учёл, что карты попали к поисковику, а не за рубеж, поэтому срок был условным.
amartology
Все, указ официально принят и опубликован. Номер 379 от 28.08.2021
Теперь нельзя говорить о проблемах Роскосмоса, космической ядерной энергетике, квантовых и AI-технологиях и длинном ряде других вещей. В том числе по ряду пунктов указа нельзя распространять сведения, уже находящиеся в открытом доступе.
Civil
Теперь о роскосмосе либо хорошо, либо никак? (не удержался от такого комментария)
Но вообще печально конечно.
amartology