Продублировал на Compiler Explorer: matmul C matmul C++ Оба по времени исполнения выдают практически идентичный результат, правда на C++ куда то целая часть из результата пропадает и нету желания разбираться.
Upd: с плюсами разобрался забыл что там линии по несколько раз проходятся и надо += (суммировать). Закономерно производительность упала в 4 раза по сравнению с Си. Только с -O3 код на плюсах становится на ровне с Си, вот вам и двумерные массивы.
JIT компиляторы так и делают, а сишный компилятор у него нет рантайм-информации он скомпилировал и выдал, какие еще проверки? Я поэтому и говорю что если нет понимания или желания понимать что статик-тайм-компаил и особенно с ручным управлением памятью требует активного участия со стороны программиста в построении оптимального потока данных и кода для их обработки, то лучше отложить си в сторону и идти писать на питоне с jit компилятором или хотя бы на расте где фронтенд и safe-семантика контролируют все еще на этапе написания кода.
В конкретном примере matmul.c предполагается что размер матрицы может быть определен из аргументов командной строки (что в данной реализации приводит к непредсказуемому поведению в случае запуска через time ./matmul):
int main(int argc, char *argv[])
{
int n = 1500;
double **a, **b, **c;
if (argc > 1) n = atoi(argv[1]);
}
То есть двумерный массив никак не оптимизировать, и вместо того что бы написать макрос который вычисляет сдвиг по оси Х подкинули еще цикл который режет массив на куски. Потом какой нибудь студент вася заметит что вконце очищается только mat[0] подумает непорядок и засунет цикл который "все" отрезки чистит, программа сегфолт выкидывает ну и ладно главное результат печатет.
double **mat_alloc(int n_row, int n_col)
{
double **mat, *a;
int i;
a = (double*)calloc(n_row * n_col, sizeof(double));
mat = (double**)malloc(n_row * sizeof(void*));
for (i = 0; i < n_row; ++i)
mat[i] = &a[i * n_col];
return mat;
}
выделяется массив матрицы, выделяется память под массив указателей, массив матрицы записывается указателями построчно и возвращается из функции.
Как вот это компилятору оптимизировать? Сказано выделить память через malloc, если этого не делать программа может быть неработоспособной. Никаких прагм и статиков никаких подсказок компилятору нет, он исходит из пессимистичного сценария.
Как я уже выше сказал надо отучать писать код на Си в наших институтах и вузах, пусть пишут на языках (например на зиге, расте или питоне) где вместо работы с памятью высунута языковая абстракция, и не надо выделять куски памяти какие то указатели пихать шоб просто в коде двумерный массив показать красивый.
Там проблема не в плавучке а в обработке массива. там длинный массив разрезают на небольшие учаски и кладут в массив указателей. Компилятор Си не может превратить это в обработку линейного массива так как у него нет понимания куда в рантайме все это будет указывать, а процессор не может использовать быструю подкачку для каких то рандомно разбросанных в памяти данных ни префетчем аля интел, ни array-префетчем аля эльбрус. Как минимум надо собирать с профилировкой что бы компилятор увидел, что на самом деле массив линейный, просто его разбивают что бы типа удобнее было обращаться к его элементам. А как максимум придется компилятор дорабатывать что бы он научился выявлять такие вещи с ходу.
На расте и питоне, в силу того что там программист как таковой исключен из этапа организации данных в памяти, там это все выявляется само собой.
$ gcc -O1 matmul_old.c
$ time $(./a.out)
-143.500167: команда не найдена
real 0m6,309s
user 0m6,229s
sys 0m0,075s
$ gcc -O1 matmul_new.c
$ time ./a.out
matrix size: 1500x1500
result: -143.500167
real 0m2,394s
user 0m2,350s
sys 0m0,044s
Наверняка если в функции mat_mul сделать проход по матрицам более линейным (то есть убрать вот этот промежуточный цикл), то можно еще в несколько раз быстрее сделать примерно на уровне функции mat_gen.
Главное не забывать что цель кода запускаться и что-то мерить. И расчесывать его до такого состояния что компилятор просто прочитает и подставит результат, будет просто бессмысленной тратой времени.
Хотя в данном случае (заглянул таки в код) бенчмарк лишний раз подтверждает что в НИИ и вузах надо убирать си и вообще низкий уровень, там только и делают что плодят тормозной код и UB
У них фортран просто транслируется в Си лапшу с goto и компилируется как си. Все силы они вкладывают как раз в С/С++ ну и вот на Rust с LLVM тоже в последнее время ресурсы бросили.
кроссплатформенная реализация корутин с поддержкой Эльбруса.
Только вот эта поддержка ограничивается простой оберткой над системными вызовами, ассемблерной реализации там нет, по понятным причинам.
Но, если я правильно понял предысторию, никакой корутинной библиотеки изначально небыло, была просто реализация ucоntext для разных архитектур в коде игры TaiseyProject. И именно из за того что контекст свитч на эльбрусе устроен иначе, грамотным выходом из ситуации было написание высокоуровневого api, что портировавший и сделал. Ну и ее в итоге приняли в менлайн
В целом я со всем согласен, самому приходили в голову мысли что Qt на фоне современных плюсов выглядит довольно таки устаревшим, а QML дико неудобным на фоне современных CSS+HTML. И я тоже мечтаю вот бы кто нибудь запили фреймворк как Qt только на чистых плюсах + HTML.
Только вот я не вижу смысла требовать это от разработчиков авроры, по крайней мере не на этом этапе их существования. Есть ли у них столько опытных разработчиков что бы создать такое в кратчайшие сроки и главное стабильно поддерживать и развивать его? Я что-то вот не уверен.
Классно, правим адрес на стеке и у нас процессор из процедуры возвращается это так по вашему работает?
Сложные аппаратные механизмы никуда не делись. Микро/макрофьюжен никуда не делся.
Все есть только вот планировщика нет и кто распределяет инструкции по устройствам - непонятно, а то что у "ROB-а" ровно столько же (19) входов-выходов за такт это конечно же совпадение. А если серьезно то этот "ROB" это конвеер на птицефабрике - по конвееру катаются коробки для яиц, женщина-декодер их фасует, на другом конце их вместо того что бы просто грузить в газель (как на vliw) перегружают в другую тару по номерам, и если каким то место не нашлось они уезжают на повторный круг и так пока аргументы не подготовятся. Тут другого варианта просто не придумать, все упирается в отсутствие общего планировщика.
Общеизвестно что страус прячет голову в песок, хотя в реальности страус никогда так не делает.
Вы курсе, в какой версии архитектуры Эльбруса они смогли прикрутить предсказатель, и как хорошо он работает?
Я в курсе. Предсказатель в эльбрус не стали вводить просто потому что Бабаян их не любит. Кстати в обозначеном Эльбрусе-Б так же никакого предсказателя не предполагается. В целом микроархитектура эльбруса от Бабаяновского концепта стала отходить только с 8СВ опираясь уже не на убеждения создателя, а на реальные задачи.
Но причина нелюбви г-на Бабаяна к предсказателям в том, что это по большому счету костыль пытающийся спасти конвеер от простоев. Единственный показатель его эффективности это количество ошибочности предсказаний на N запусков, и чем меньше он обсирается тем как бы лучше, но не ошибаться он не умеет и ускорять он ничего не ускоряет.
Реальная эксплуатация эльбруса показала что подготовки переходов очень хороши, но их всего три и у каждого есть еще своя специализация, например только ctpr2 умеет делать те самые конвейризованые циклы и когда оно используется, нельзя переключать конвееры, поэтому часто можно увидеть в таких циклах используется непосредственный переход типа ibranch. ну а если в коде нет пространства для подготовок (лапшекод) то вот эти подготовки начинают играть в минус, так как занимают две команды вместо одного перехода/вызова и все это плюсом к штрафу конвеера.
Теперь у каждой подготовленной команды будет непосредственный аналог - icall iret ibranch с возможностью условного исполнения и предсказанием, что позволит во первых исполнять обычные циклы с возвратом и лапшевызовами примерно с эффективностью на уровне арм/интел, А во вторых подготовки никуда не делись и бранчпредиктору не надо будет предсказывать такие сложные вещи как возможный возврат из цикла в предыдущую процедуру (если конечно компилятор справится). Интел же возвраты откуда угодно делать не умеет ему надо прыгать в конец процедуры к команде ret, а бранчпредиктору надо предсказывать три возможные путя на каждой итерации. Но как это все в реальности покажут только реальные тесты реальных процессоров, которых еще нет в железе, поэтому говорить о том как это работает рановато.
Уже давно не 2-3. Впрочем Интел не является хорошим примером.
M4 может выполнить 19 микроопераций за такт.
Обращаю внимание что на блок-схеме отсутствует классический re-order buffer и переименование регистров (обязательный атрибут OoO), вместо них некая очередь с таблицей переотображения регистров.
Я полагаю работает это так: 1) микрокод декодирует 19 команд и распределяет их по ячейкам (как в ШК) так как у процессора нет общего планировщика, а определенный тип операций должен как то попасть на свое устройство. 2) На следующем такте (или скорей всего на 6-9ом) это все доходит до передачи в конвейер устройств. Так как целочисленная и вещественная+векторная группа алу подключены к своим регистровым файлам нужна таблица переназначения регистров которая работает похожим на базированные регистры эльбруса образом. 3) Если для микроопа не готовы аргументы тогда ШК с застрявшими в ней микроопом едет на длинный круг в +10 тактов. Всего в очереди 19 широких команд (361=19шк*19моп).
Так же бросается в глаза что у M4 аж три устройства перехода, в их наличии нет никакого практического смысла кроме одного - выполнить три перехода под условиями. Как раз подходит для вышеописанной ситуации с выходом из цикла и тремя вариантами выхода перехода. Это конечно не похоже эльбрус, но зато похоже на
типичный западный VLIW
к которому прикрутили фронтенд. И эпл тут далеко не первопроходец так как уже был NVIDIA Denver с похожими решениями.
В любом случае мы видим живой пример как эпл с 2012г пыталсясь создать свой OoO суперскаляр (на первых блок схемах буфер перестановки есть) сделал в итоге VLIW-подобие без этих ваших сложных аппаратных механизмов.
А для ДСП оверхэд не критичен? В дсп то памяти дохрена, не знают куда девать.
Все остальные аргументы отражают реальность примерно так же (никак):
Любой суперскаляр без предсказателя или с плохим предсказателем будет захлебываться на лапшекоде. То есть это не проблема VLIW
Любой новый интел что бы использовать все его новые возможности, требует сборки специально под него. Но никто этого не делает потому как у бедного школьника из уганды с pentium dual-core не будет возможности пользоваться свободным ПО вроде дебиана. А это не допустимо, поэтому сборка софта ведется под дженерик архитектуру с минимумом расширений. Что бы обойти такие ограничения программы типа libavc или 7z используют автодетект набора инструкций и вызывают оптимизированные под тот или иной набор функции, почему для vliw нельзя то же самое - непонятно.
Ну и да код от всех этих функций знатно распухает, в том же ffmpeg может достигать +100мб. Так же он распухает когда пишешь производительный код на интел и компиляторы пытаются разворачивать циклы потому что это как бы дает лучшее ускорение обработки данных. В то же время на эльбрусе компилятор наоборот пытается свернуть цикл в как можно меньшее количество команд на итерацию (в идеале - в одну) т.к. у эльбруса есть аппаратная поддержка циклов которая автоматом развернет эту команду на всю длину конвейера, таким образом получается наоборот vliw способствует лучшей компактности для производительного когда и в отличии от того что выше это именно заслуга vliw так как широкая команда позволяет подпихнуть в нее что угодно, и таким образом подсказать фронтенду в рантайме что происходит в потоке.
Ну а что касается реальных проблем эльбруса (не vliw): Это в первую очередь защищеные стеки которые обеспечивают ему с одной стороны хорошую контекстную безопасность, так вот ломануть эльбрус как сломали PS2 не выйдет, с другой стороны она оборачиваются нагрузкой на ядро через системные вызовы если приложение что то хочет делать со своим стеком. Это довольно таки неприятный момент для виртуальных машин.
Другая проблема эльбруса, которая вроде как будет частично решена - это прокачка данных в кэш. Неважно насколько классно и плотно удалось натромбовать широкие команды, даже на всю ширину векторов, если цикл использует лоад/стор то это приговор для производительности. Даже обычное скалярное побайтовое последовательное сложение+умножение с подкачкой данных через array-префетчер уделает вот те команды на самом же эльбрусе раза так в четыре. Но арей-префетчер можно использовать только в конвейризованых циклах и с выравненными массивами, а другой подкачки на эльбрусе просто нет.
В седьмой версии вроде как завезут и бранчпредиктор для лапшекода и префетчер, и останется проблема только с безопасными стеками и как их подружить с прикладным ПО.Ну а конкретно с VLIW подходом проблем нету никаких вообще, программы компилируются и работают, все как на любом обычном процессоре.
Я понимаю что есть еще обширные теоритические притензии, мол вся вот эта куча устройств с конвеерами большую часть времени тупо стоит, и это мол неэффективное использование а на интеле хоть их и два-три зато они постоянно в работе, но тут нужно какое то научное исследование о том насколько это действительно обосновано так с точки зрения трудозатрат и конечной энергоэффективности.
Как мы знаем из нашей истории инженер Глушко выбрал многокамерную схему ракетных двигателей потому что в четырех маленьких камерах проще добиться стабильности горения чем в одной большой, и не прогадал хотя это вроде как неэффективно с точки зрения удельного веса и всего такого. Другой пример - центрифуги для обогощения урана. Чем больше (выше/толще) центрифуга тем лучше производительность и эффективней резделение изотопов, однако современные росатомовские центрифуги размером с пятилитровый термос, потому что это упрощает их обслуживание их раскрутку до высоких скоростей итд. итп. Так что эффективность в теории ничего не стоит.
берешь ALC эльбруса распиливаешь их на отдельные, каждому даешь свой небольшой локальный регистровый файл получаются отдельные кластеры, которые в отличии от эльбруса обычного могут работать асинхронно так как нет широкой команды.
Причем ведь были и свои разработки: от железа (например, легендарный «Эльбрус») до ПО (застал заведующего кафедрой — директора по науке НИИУМС: их разработки "с нуля" были вполне уровне, пусть и специфичные)
Российское импортозамещение напоминает театральную постановку: актёры в костюмах «патриотов» разыгрывают пьесу о технологической независимости.
Тут дело в том что министерства (минцифры итд) которые всю эту движуху инициируют, им самим это все не нужно, в том смысле что никаких IT отделов и серверов у них нет. Таким образом получается ситуация когда, человек которого это все не касается (ни прямо ни косвенно) предписывает другому как и на чем ему работать. Довольно абсурдно, но по факту так и есть.
Логика конечно подсказывает что министерство наоборот как бы должно быть максимально на стороне госзаказчиков и чихвостить участников, но на деле у нас министерство взяло на себя роль няньки, а IT-бизнес воспринимает как сироток которые надо гос-сиськой кормить иначе он умрет. Ну а госзаказчик он как бы мужик и потерпит. Проблема в том что под "сиротками" как правило скрываются ветераны сосания бюджетов которые очень отчаяно защищают свою кормушку от конкурентов. За примером далеко лазить не буду, инди-разработчики известные по RTC Syrian Warfare, когда решили получить финансирование от гос-фонда созданного вроде как для поддержки игр, столкнулись с тем что с них начали требовать бухучеты и документу по госту о выполненных работах. Для чего это сделано - вполне понятно, для того что бы такие залетные в гостему даже не совались, а правильные люди будут теперь раз в трехлетку делать Смуты, Сталинграды, и рекламировать по первому каналу в новостях.
Они не бесплатные, нужна все равно какая-то компания которая будет собирать из исходников и тестировать версии на совместимость. И огромный плюс СПО как раз в том что это может делать любая, достаточно компетентная компания. Тогда как закрытый софт это собственность компании-разработчика и только она его билдит и сопровождает. Можно ли считать "интеллектуальную собственность" пусть даже российских компаний общенациональной - это большой вопрос.
По мне так нельзя, пока она не выложит код под свободной лицензией.
Сравниваем 1 Байкал-С с 4-мя Э16С и делаем вывод, что т.к. 1 не обгоняет 4-х (кстати, обгоняет), то он проиграл.
Сравниваю серверные процессоры. Один штатно может в многопроцессорную конфигурацию и ему для этого не нужно никаких контроллеров и прочего, с чего бы это не учитывать? Это базовая вещь для серверного процессора. Для байкала заявлен CCIX но оно вроде как не для объединения процессоров на общей памяти, а для интерконекта со всякое фигней типа модуля NeuroMatrix, и опять таки в глаза бросается то что у байкала на сайте:
Интерконнект:Три интерфейса CCIX x16, каждая полоса работает со скоростью 16 Гбит/с. Интерфейсы ввода/вывода:80 линий PCIe Gen 4.0 (48 линий общие для CCIX-интерфейса);
как бы все правильно это обычная паропускная способность PCIe yj в документации к стандарту CCIX речь идет про GT/s (миллиарда транзакций в секунду) потому что суть интерфейса как раз в том что бы не гонять данные туда сюда (с чем справляется обычный PCIe), а что бы расшарить общую память для ускорителей при этом да используя тот же PCIe.
Зачем так написано? Затем что у эльбрусов написано 16гбит/с в каждую сторону ? Ну так там то как раз данные пересылаются между процессорами.
В общем и целом имеем очередное "поделие" для пускания пыли в глаза чиновникам, процессор для облачных сервисов (например облачной нейросети с ускорителями) который на серьезных щах подают как серверный процессор для СХД, то есть повторяется ситуация как с таволгой куда сунули процессор для embadded в качестве десктопного. Так что проблема не в Т-Платформах и не в Опанасенко, а в самой этой компании Байкал Электроникс, которая не ориентирована на то что бы создавать востребованный рынком продукт, а на то что бы пилить бабло на госзакупках и некомпетентности чиновников.
Я с
-O1что-то не наблюдаю такого:Продублировал на Compiler Explorer:
matmul C
matmul C++
Оба по времени исполнения выдают практически идентичный результат, правда на C++ куда то целая часть из результата пропадает и нету желания разбираться.
Upd:
с плюсами разобрался забыл что там линии по несколько раз проходятся и надо += (суммировать).
Закономерно производительность упала в 4 раза по сравнению с Си. Только с -O3 код на плюсах становится на ровне с Си, вот вам и двумерные массивы.
На xmm регистрах интел считает плавучку, это не векторизация.
JIT компиляторы так и делают, а сишный компилятор у него нет рантайм-информации он скомпилировал и выдал, какие еще проверки? Я поэтому и говорю что если нет понимания или желания понимать что статик-тайм-компаил и особенно с ручным управлением памятью требует активного участия со стороны программиста в построении оптимального потока данных и кода для их обработки, то лучше отложить си в сторону и идти писать на питоне с jit компилятором или хотя бы на расте где фронтенд и safe-семантика контролируют все еще на этапе написания кода.
В конкретном примере matmul.c предполагается что размер матрицы может быть определен из аргументов командной строки (что в данной реализации приводит к непредсказуемому поведению в случае запуска через
time ./matmul):То есть двумерный массив никак не оптимизировать, и вместо того что бы написать макрос который вычисляет сдвиг по оси Х подкинули еще цикл который режет массив на куски. Потом какой нибудь студент вася заметит что вконце очищается только
mat[0]подумает непорядок и засунет цикл который "все" отрезки чистит, программа сегфолт выкидывает ну и ладно главное результат печатет.В matmul -е есть, вот этот код:
выделяется массив матрицы, выделяется память под массив указателей, массив матрицы записывается указателями построчно и возвращается из функции.
Как вот это компилятору оптимизировать? Сказано выделить память через malloc, если этого не делать программа может быть неработоспособной. Никаких прагм и статиков никаких подсказок компилятору нет, он исходит из пессимистичного сценария.
Как я уже выше сказал надо отучать писать код на Си в наших институтах и вузах, пусть пишут на языках (например на зиге, расте или питоне) где вместо работы с памятью высунута языковая абстракция, и не надо выделять куски памяти какие то указатели пихать шоб просто в коде двумерный массив показать красивый.
Там проблема не в плавучке а в обработке массива. там длинный массив разрезают на небольшие учаски и кладут в массив указателей. Компилятор Си не может превратить это в обработку линейного массива так как у него нет понимания куда в рантайме все это будет указывать, а процессор не может использовать быструю подкачку для каких то рандомно разбросанных в памяти данных ни префетчем аля интел, ни array-префетчем аля эльбрус. Как минимум надо собирать с профилировкой что бы компилятор увидел, что на самом деле массив линейный, просто его разбивают что бы типа удобнее было обращаться к его элементам. А как максимум придется компилятор дорабатывать что бы он научился выявлять такие вещи с ходу.
На расте и питоне, в силу того что там программист как таковой исключен из этапа организации данных в памяти, там это все выявляется само собой.
Вот так: https://ce.mentality.rip/z/84r59E
Сишный matmul становится побыстрее
Наверняка если в функции mat_mul сделать проход по матрицам более линейным (то есть убрать вот этот промежуточный цикл), то можно еще в несколько раз быстрее сделать примерно на уровне функции mat_gen.
Главное не забывать что цель кода запускаться и что-то мерить. И расчесывать его до такого состояния что компилятор просто прочитает и подставит результат, будет просто бессмысленной тратой времени.
Хотя в данном случае (заглянул таки в код) бенчмарк лишний раз подтверждает что в НИИ и вузах надо убирать си и вообще низкий уровень, там только и делают что плодят тормозной код и UB
У них фортран просто транслируется в Си лапшу с goto и компилируется как си. Все силы они вкладывают как раз в С/С++ ну и вот на Rust с LLVM тоже в последнее время ресурсы бросили.
Скорость обращения к памяти тоже надо мерить, так что наверное нужная.
Только вот эта поддержка ограничивается простой оберткой над системными вызовами, ассемблерной реализации там нет, по понятным причинам.
Но, если я правильно понял предысторию, никакой корутинной библиотеки изначально небыло, была просто реализация ucоntext для разных архитектур в коде игры TaiseyProject. И именно из за того что контекст свитч на эльбрусе устроен иначе, грамотным выходом из ситуации было написание высокоуровневого api, что портировавший и сделал. Ну и ее в итоге приняли в менлайн
В целом я со всем согласен, самому приходили в голову мысли что Qt на фоне современных плюсов выглядит довольно таки устаревшим, а QML дико неудобным на фоне современных CSS+HTML. И я тоже мечтаю вот бы кто нибудь запили фреймворк как Qt только на чистых плюсах + HTML.
Только вот я не вижу смысла требовать это от разработчиков авроры, по крайней мере не на этом этапе их существования. Есть ли у них столько опытных разработчиков что бы создать такое в кратчайшие сроки и главное стабильно поддерживать и развивать его? Я что-то вот не уверен.
Классно, правим адрес на стеке и у нас процессор из процедуры возвращается это так по вашему работает?
Все есть только вот планировщика нет и кто распределяет инструкции по устройствам - непонятно, а то что у "ROB-а" ровно столько же (19) входов-выходов за такт это конечно же совпадение.
А если серьезно то этот "ROB" это конвеер на птицефабрике - по конвееру катаются коробки для яиц, женщина-декодер их фасует, на другом конце их вместо того что бы просто грузить в газель (как на vliw) перегружают в другую тару по номерам, и если каким то место не нашлось они уезжают на повторный круг и так пока аргументы не подготовятся. Тут другого варианта просто не придумать, все упирается в отсутствие общего планировщика.
Общеизвестно что страус прячет голову в песок, хотя в реальности страус никогда так не делает.
Я в курсе. Предсказатель в эльбрус не стали вводить просто потому что Бабаян их не любит. Кстати в обозначеном Эльбрусе-Б так же никакого предсказателя не предполагается. В целом микроархитектура эльбруса от Бабаяновского концепта стала отходить только с 8СВ опираясь уже не на убеждения создателя, а на реальные задачи.
Но причина нелюбви г-на Бабаяна к предсказателям в том, что это по большому счету костыль пытающийся спасти конвеер от простоев. Единственный показатель его эффективности это количество ошибочности предсказаний на N запусков, и чем меньше он обсирается тем как бы лучше, но не ошибаться он не умеет и ускорять он ничего не ускоряет.
Реальная эксплуатация эльбруса показала что подготовки переходов очень хороши, но их всего три и у каждого есть еще своя специализация, например только ctpr2 умеет делать те самые конвейризованые циклы и когда оно используется, нельзя переключать конвееры, поэтому часто можно увидеть в таких циклах используется непосредственный переход типа ibranch. ну а если в коде нет пространства для подготовок (лапшекод) то вот эти подготовки начинают играть в минус, так как занимают две команды вместо одного перехода/вызова и все это плюсом к штрафу конвеера.
Теперь у каждой подготовленной команды будет непосредственный аналог -
icall iret ibranchс возможностью условного исполнения и предсказанием, что позволит во первых исполнять обычные циклы с возвратом и лапшевызовами примерно с эффективностью на уровне арм/интел, А во вторых подготовки никуда не делись и бранчпредиктору не надо будет предсказывать такие сложные вещи как возможный возврат из цикла в предыдущую процедуру (если конечно компилятор справится). Интел же возвраты откуда угодно делать не умеет ему надо прыгать в конец процедуры к командеret, а бранчпредиктору надо предсказывать три возможные путя на каждой итерации.Но как это все в реальности покажут только реальные тесты реальных процессоров, которых еще нет в железе, поэтому говорить о том как это работает рановато.
Обращаю внимание что на блок-схеме отсутствует классический re-order buffer и переименование регистров (обязательный атрибут OoO), вместо них некая очередь с таблицей переотображения регистров.
Я полагаю работает это так:
1) микрокод декодирует 19 команд и распределяет их по ячейкам (как в ШК) так как у процессора нет общего планировщика, а определенный тип операций должен как то попасть на свое устройство.
2) На следующем такте (или скорей всего на 6-9ом) это все доходит до передачи в конвейер устройств. Так как целочисленная и вещественная+векторная группа алу подключены к своим регистровым файлам нужна таблица переназначения регистров которая работает похожим на базированные регистры эльбруса образом.
3) Если для микроопа не готовы аргументы тогда ШК с застрявшими в ней микроопом едет на длинный круг в +10 тактов. Всего в очереди 19 широких команд (361=19шк*19моп).
Так же бросается в глаза что у M4 аж три устройства перехода, в их наличии нет никакого практического смысла кроме одного - выполнить три перехода под условиями. Как раз подходит для вышеописанной ситуации с выходом из цикла и тремя вариантами выхода перехода.
Это конечно не похоже эльбрус, но зато похоже на
к которому прикрутили фронтенд. И эпл тут далеко не первопроходец так как уже был NVIDIA Denver с похожими решениями.
В любом случае мы видим живой пример как эпл с 2012г пыталсясь создать свой OoO суперскаляр (на первых блок схемах буфер перестановки есть) сделал в итоге VLIW-подобие без этих ваших сложных аппаратных механизмов.
А для ДСП оверхэд не критичен? В дсп то памяти дохрена, не знают куда девать.
Все остальные аргументы отражают реальность примерно так же (никак):
Любой суперскаляр без предсказателя или с плохим предсказателем будет захлебываться на лапшекоде. То есть это не проблема VLIW
Любой новый интел что бы использовать все его новые возможности, требует сборки специально под него. Но никто этого не делает потому как у бедного школьника из уганды с pentium dual-core не будет возможности пользоваться свободным ПО вроде дебиана. А это не допустимо, поэтому сборка софта ведется под дженерик архитектуру с минимумом расширений. Что бы обойти такие ограничения программы типа libavc или 7z используют автодетект набора инструкций и вызывают оптимизированные под тот или иной набор функции, почему для vliw нельзя то же самое - непонятно.
Ну и да код от всех этих функций знатно распухает, в том же ffmpeg может достигать +100мб. Так же он распухает когда пишешь производительный код на интел и компиляторы пытаются разворачивать циклы потому что это как бы дает лучшее ускорение обработки данных. В то же время на эльбрусе компилятор наоборот пытается свернуть цикл в как можно меньшее количество команд на итерацию (в идеале - в одну) т.к. у эльбруса есть аппаратная поддержка циклов которая автоматом развернет эту команду на всю длину конвейера, таким образом получается наоборот vliw способствует лучшей компактности для производительного когда и в отличии от того что выше это именно заслуга vliw так как широкая команда позволяет подпихнуть в нее что угодно, и таким образом подсказать фронтенду в рантайме что происходит в потоке.
Ну а что касается реальных проблем эльбруса (не vliw):
Это в первую очередь защищеные стеки которые обеспечивают ему с одной стороны хорошую контекстную безопасность, так вот ломануть эльбрус как сломали PS2 не выйдет, с другой стороны она оборачиваются нагрузкой на ядро через системные вызовы если приложение что то хочет делать со своим стеком. Это довольно таки неприятный момент для виртуальных машин.
Другая проблема эльбруса, которая вроде как будет частично решена - это прокачка данных в кэш. Неважно насколько классно и плотно удалось натромбовать широкие команды, даже на всю ширину векторов, если цикл использует лоад/стор то это приговор для производительности. Даже обычное скалярное побайтовое последовательное сложение+умножение с подкачкой данных через array-префетчер уделает вот те команды на самом же эльбрусе раза так в четыре. Но арей-префетчер можно использовать только в конвейризованых циклах и с выравненными массивами, а другой подкачки на эльбрусе просто нет.
В седьмой версии вроде как завезут и бранчпредиктор для лапшекода и префетчер, и останется проблема только с безопасными стеками и как их подружить с прикладным ПО.Ну а конкретно с VLIW подходом проблем нету никаких вообще, программы компилируются и работают, все как на любом обычном процессоре.
Я понимаю что есть еще обширные теоритические притензии, мол вся вот эта куча устройств с конвеерами большую часть времени тупо стоит, и это мол неэффективное использование а на интеле хоть их и два-три зато они постоянно в работе, но тут нужно какое то научное исследование о том насколько это действительно обосновано так с точки зрения трудозатрат и конечной энергоэффективности.
Как мы знаем из нашей истории инженер Глушко выбрал многокамерную схему ракетных двигателей потому что в четырех маленьких камерах проще добиться стабильности горения чем в одной большой, и не прогадал хотя это вроде как неэффективно с точки зрения удельного веса и всего такого. Другой пример - центрифуги для обогощения урана. Чем больше (выше/толще) центрифуга тем лучше производительность и эффективней резделение изотопов, однако современные росатомовские центрифуги размером с пятилитровый термос, потому что это упрощает их обслуживание их раскрутку до высоких скоростей итд. итп. Так что эффективность в теории ничего не стоит.
И в чем уродство?
берешь ALC эльбруса распиливаешь их на отдельные, каждому даешь свой небольшой локальный регистровый файл получаются отдельные кластеры, которые в отличии от эльбруса обычного могут работать асинхронно так как нет широкой команды.
Тут дело в том что министерства (минцифры итд) которые всю эту движуху инициируют, им самим это все не нужно, в том смысле что никаких IT отделов и серверов у них нет. Таким образом получается ситуация когда, человек которого это все не касается (ни прямо ни косвенно) предписывает другому как и на чем ему работать. Довольно абсурдно, но по факту так и есть.
Логика конечно подсказывает что министерство наоборот как бы должно быть максимально на стороне госзаказчиков и чихвостить участников, но на деле у нас министерство взяло на себя роль няньки, а IT-бизнес воспринимает как сироток которые надо гос-сиськой кормить иначе он умрет. Ну а госзаказчик он как бы мужик и потерпит.
Проблема в том что под "сиротками" как правило скрываются ветераны сосания бюджетов которые очень отчаяно защищают свою кормушку от конкурентов. За примером далеко лазить не буду, инди-разработчики известные по RTC Syrian Warfare, когда решили получить финансирование от гос-фонда созданного вроде как для поддержки игр, столкнулись с тем что с них начали требовать бухучеты и документу по госту о выполненных работах. Для чего это сделано - вполне понятно, для того что бы такие залетные в гостему даже не совались, а правильные люди будут теперь раз в трехлетку делать Смуты, Сталинграды, и рекламировать по первому каналу в новостях.
Они не бесплатные, нужна все равно какая-то компания которая будет собирать из исходников и тестировать версии на совместимость. И огромный плюс СПО как раз в том что это может делать любая, достаточно компетентная компания. Тогда как закрытый софт это собственность компании-разработчика и только она его билдит и сопровождает. Можно ли считать "интеллектуальную собственность" пусть даже российских компаний общенациональной - это большой вопрос.
По мне так нельзя, пока она не выложит код под свободной лицензией.
Сравниваю серверные процессоры. Один штатно может в многопроцессорную конфигурацию и ему для этого не нужно никаких контроллеров и прочего, с чего бы это не учитывать? Это базовая вещь для серверного процессора. Для байкала заявлен CCIX но оно вроде как не для объединения процессоров на общей памяти, а для интерконекта со всякое фигней типа модуля NeuroMatrix, и опять таки в глаза бросается то что у байкала на сайте:
Интерконнект:Три интерфейса CCIX x16, каждая полоса работает со скоростью 16 Гбит/с.Интерфейсы ввода/вывода:80 линий PCIe Gen 4.0 (48 линий общие для CCIX-интерфейса);как бы все правильно это обычная паропускная способность PCIe yj
в документации к стандарту CCIX речь идет про GT/s (миллиарда транзакций в секунду) потому что суть интерфейса как раз в том что бы не гонять данные туда сюда (с чем справляется обычный PCIe), а что бы расшарить общую память для ускорителей при этом да используя тот же PCIe.
Зачем так написано? Затем что у эльбрусов написано 16гбит/с в каждую сторону ? Ну так там то как раз данные пересылаются между процессорами.
В общем и целом имеем очередное "поделие" для пускания пыли в глаза чиновникам, процессор для облачных сервисов (например облачной нейросети с ускорителями) который на серьезных щах подают как серверный процессор для СХД, то есть повторяется ситуация как с таволгой куда сунули процессор для embadded в качестве десктопного. Так что проблема не в Т-Платформах и не в Опанасенко, а в самой этой компании Байкал Электроникс, которая не ориентирована на то что бы создавать востребованный рынком продукт, а на то что бы пилить бабло на госзакупках и некомпетентности чиновников.