в Эльбрус 32 они все таки вставят этот блок и уберут эту простоту
Ничего подобного они не собираются городить. Рантайм оптимизациями будет заниматься компилятор, а процессор будет собирать и выдавать ему статистику. Эта фича заявлена уже для Эльбрус-16С
В Эльбрус-32С хотят добавить предсказатель переходов, но не такой предсказатель как у суперскаляров если коротко это будет предсказатель подготовленных переходов и 7 управляющих регистров (сейчас только 3).
Надеюсь что они учтут так же подготовку предсказания вызовов, потому что текущая реализация не позволяет подготовить заранее два-три вызова и поочереди их дергать.
2. кладет их в двойной регистр (младшую часть квадрорегистра), старшую часть заранее заполнил нулями,
3. и наконец делает над квадрорегистром адресное преобразование командой movtd (mov tag data или что то типа этого).
Скорее всего он создает таки локальный указатель на данные, по типу (StructRGB *){0,0,0,} только с числом, используя arr как переменную. Если это так то упало скорей всего из за + index надо попробовать отставить arr = (int*)start и посмотреть будет ли ссылка на число.
А при чтении массива падать будет все равно потому что безопасный режим не разрешает читать неинициализированные данные надо его перед этим или заполнить или использовать memset(arr, 0 sizeof(int) * n)
Читать плачь про слишком строгие правила работы с указателем было забавно, учитывая что в других языках с ними вообще ничего нельзя делать, кроме как получить или передать. Запустите лучше вот такой код, если вам не сложно. Интересно все таки структура указателя, по ассемблеру получается что при складывании он увеличивает поле size, может расположение не такое просто.
Там принципиальная проблема: в защищенном режиме 128-битовый указатель содержит размер выделенного блока, тэги, адресс начала блока и offset.
В коде часто встречается присвоение целому значению указателя, потом какая-то арифметика над этим целочисленным значением, а потом присвоение нового значения обратно в указатель.
Причина не в 128и битных указателях. В ассемблере адрес все равно ложится в виде числа на регистр, обращение к памяти происходит специальными командами, в том числе поддерживающими обращение по смещению. А вот сохранить на стек в виде указателя то что не является указателем уже нельзя, банально потому что указатель в безопасном режиме - это тип, а у типов строгие правила преобразования в (зависимости от языка).
В данном примере указатель складывается с целым, что по правилам Си дает указатель. Но вообще оказалось что работает и в первом случае, если расставить явные преобразования типов https://ce.mentality.rip/z/PcrYGM
К слову указатель на процедуру отличается, полагаю и работа с ним тоже. В любом случае весь вот этот безопасный режим это просто как аппаратная виртуальная машина для Си привносящая в него безопасность уровня джавы. И это не такой режим как в интеле при переключении 32/64 адресации, он работает как отдельное адресное пространство работа с которыми происходит через специальные команды. Функции из него наверное даже можно из небезопасного режима вызывать с некоторыми ограничениями, надо только в ОС реализовать поддержку.
Основной конвеер на девять (или больше) стадий, но в дополнение к нему есть еще 3 обрубка на 6 стадий. Обрубка в том смысле что в них код не исполняется никак, а лишь заполняется кодом функции или бранча на 6 (широких) команд и останавливается. Подготовка конвеера запускается командой
disp, %ctpr1, malloc
после чего в любом удобном месте процедуры можно вызвать
call %ctpr1
нижние стадии основного конвеера перецепляются к pipe1 после чего он становится основным, а предыдущий отрезается от исполнения и таким образом ждет возврата. Аргументы передаются путем наложения окна вызываемой процедуры на крайние регистры текущей, может это чуть менее эффективно чем наслоение процедур в интеле, но зато с точки зрения безопасности не подкопаешься.
если цикл хотя бы 50 инструкций, то «следующая итерация» начнётся на +50 от текущей инструкции
Ну даже так может оказаться полезно вынести загрузку данных первой итерации из цикла, а в теле цикла разместить обработку этих данных вместе с загрузкой данных для следующей, как бы "открутив" от него.
Компания Google сообщила о внедрении патчей KPTI и retpoline для блокирования атак Meltdown и Spectre на своих Linux-серверах, в том числе обслуживающих поисковую систему, Gmail, YouTube и Google Cloud Platform. Несмотря на то, что теоретически данные патчи приводят к возникновению дополнительных накладных расходов при выполнении системных вызовов, влияние на производительность обоих патчей при реальной нагрузке Google при выполнении большинства задач оценивается как незначительное. Напомним, что в синтетических тестах наблюдалось проседание производительности до 30% и даже до 60%.
В то же самое время есть пример эльбруса в котором malloc можно подгрузить в дополнительный конвеер сильно заранее и вызвать за один такт когда понадобиться. Может это немного и не то по скорости, все таки пока не переключишься, никакие загрузки оттуда вперед не запустятся, но уж всяко быстрей заплаток безопасности и в статике прекрасно планируется. Хотя реализация на эльбрусе не позволяет например два вызова подготовить и поочередно их запустить, можно только подготовить один, вызвать и только после этого можно начать готовить второй.
Про раскрутку я говорил что "в коде или компиляторе" не во время исполнения естественно.
Спекулятивное/внеочередное исполнение не обладает возможностями ментального вызова функций с неизвестными аргументами для выделения памяти и мгновенным обращением к свежесозданному объекту в следующей итерации
Но оно может заранее попытаться подгрузить node->left, node->right, node->body прямо до проверки node->kind , от типа которого в том числе может зависеть и есть ли вообще эти поля как таковые. В том числе проделать это сразу для нескольких итераций путем раскрутки цикла в коде или компиляторе.
у 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нм через пять лет вообще промолчу.
ARM делаются под совершенно другое энергопотребление, раз так в 10 ниже
Они это достигают размером самого ядра, которое даже на крошечном по десктопным меркам кристалле 10% занимает если не меньше. В армах нет сложных технологий отключения кэшей/конвееров как в интелах, и этим они с эльбрусом одинаковые, у них есть рабочие частоты и рабочее напряжение 0.8-1.2V, которое даже на старых 45нм интелах позволяло работать на 1,5-3,0Ггц а на армах и эльбрусах только 800-1500Мгц на более тонких техпроцессах. Мотивация впрочем у них разная, у эльбрусов маленькие бюджеты и сроки, можно сказать чисто чтоб люди на работу ходили, студентов в средах проектирования работать учили, и раз в год-два чем то отчитывались сдавали "изделие" которое положат на полку и дадут задание на новое. У армов же рыночек порешал что дешевые массовые чипы за 10-20 долларов предпочтительнее более проработанных за 40-60 долларов. Вот и всё.
Еще в бородатые времена читал на Tom's Hardware (а может кстати и на хабре, не помню уже) что наращивание частоты упирается в скорость переключения транзисторов, 5Ггц для них предел и IBM работает над созданием новых которые позволят наращивать дальше вплоть до 10Ггц. Но в статье пишут про 7nm Samsung так что врядли это та самая революция которую нам обещали. Ну и конечно же 960Мб L4 и 256Мб L3 впечатляет.
Высокие тактовые частоты достигаются более детальным уровнем проектирования микросхемы (full custom design). Никакие архитектуры здесь вообще непричем. На примере процессоров ARM нетрудно заметить что на тех же 16nm типичные частоты у них ~2Ггц, на 7-5нм уже подобрались к 3Ггц. И эльбрус и доступные на рынке ARM процессоры делаются из стандартных ячеек/блоков фабрики, а так высоких частот не достичь.
Вы уверены, что disp %ctpr1 можно выполнять сразу после операции перехода?
Конечно можно, в чем проблема? Мало тог, оно и выполняется сразу в следующем такте, nop 2 стоит для следующей команды, которая очевидно использует результат ldw,0 %dr10, %dr3, %r0
Это утверждение не соответствует действительности. Писать код долго и дорого. По факту сделать процессор за 500 миллионов дешевле и быстрее
Вы бредите, даже в той же мцст разработкой софта (всего - библиотеки, компиляторы дистрибутив) занимается 20 человек, а железом 200. Во вторых какая бы железка не была, хоть за 100 хоть за 500 миллионов, под нее все равно придется софт портировать и ускорять под новые инструкции, автоматом к процессору ничего не прилогается.
Бабаян там явным образом говорит о несостоятельности VLIW подхода, фразой "Ну мы и решили его попробовать. Ведь мы тогда минусов не знали этой широкой команды…"
Под несостоятельностью "VLIW подхода" он имеет в виду сугубо статичность аппаратуры, это даже не в плане in-order vs out-of-order, а в плане того что как сейчас в эльбрусе все шесть практически универсальных ALC вынуждены вставать на ожиданиях данных или чего то еще дружной командой, синхронно, потому что широкие команды подразумевают такую синхронизацию - вот это он называет под минусом широкой команды.
Но прошу обращаю внимание именно широкую команду он считает плохой а не эльбрус. Вот что он предлагает сейчас: динамические стрендыпо сути те же ALC и каждый стренд в своем кластере с дубликатом регистрового файла (привет эльбрус). Строгое in-order исполнение, никакого бранчпредиктора, код для стрендов готовит компилятор, контекстная безопасность (аkа "Безопасный режим"). Все по сути то же самое, все все что в каком то виде уже было в эльбрусах 1-2-3 - вот тебе развитие, никакого тупика в развитии родных идей Бабаян не видит.
А теперь включи оптимизации как в статье (-O2 или выше), выбери компилятор как в статье (gcc 7.5, а не кланг) и внезапно получишь во-первых ассемблерный листинг как в статье (а не колбасу на 30+ инструкций), а во-вторых - не поверишь, 2-4 такта на итерацию.
Он же ОоО суперскаляр, у него все есть в железе и ему не нужно полагаться на компиляторы как какой нибудь там тупиковый VLIW. Они вон все ненадежные: https://godbolt.org/z/8qe454f4z компиляешь с максимальными оптимизациями -O3 а результат хуже чем с -O2 в два раза - 3.3 такта против 1.75
Гораздо проще и лучше транзисторов еще там сям приляпывать и вообще выкинуть компиляторы как класс на свалку истории. Пользователь только спасибо скажет, раньше одним и тем же процессором приходилось обходится по несколько лет, а теперь скажет с предвкушением откладываю на осенний сезон аппаратных обновлений.
считаю производительность и такты для него с закрытыми глазами
Ты молодец, но ты забываешь что это именно эльбрусовская система команд тебе это позволила сделать. Для интела ты свой навык применять не можешь, ты не видишь микрокод и не знаешь что внутри происходит: https://godbolt.org/z/qaxdEeGo6 10~13 тактов интел тратит, никакие не три. Хватит людям в уши лить.
Кстати, эти три такта, которые он получил тоже будут только в хороших случаях, в общем случае нам понадобится не менее 4 тактов.
Да откуда вы берете эти три такта? Там в цикле 3000 итераций (10000 / 3) замеры выдают 22000 тактов на весь цикл что эквивалентно 7~8 тактов на итерацию.
Конечно это не 17 тактов, но и не один. В 7~8 раз медленней чем могло бы быть при инлайне (причем это самый минимум, так как цикл можно еще развернуть и ускорить в 100+ раз), но зато быстрее эльбруса на заведомо медленном коде в 2.5 раза.
Если сравнивать не с отдельными комплектующими с алиэкспресс/dns а с решениями от вендоров типа HP, то действительно бывает дешевле, например схд на эльбрусе 8с что то около 3,5млн руб обходились за штуку, тогда как у хп в том же формфакторе и за 5млн, а здоровые на 4юнита вовсе за 10.
Другой вопрос что у них железо на порядок производительней.
Шарманщик Карло обидел несчастного сироту Варраву (Barrabas идш). Руководствуясь завистью к чужому успеху заплатил продажным блогерам в колличестве 1 и натравил свои ручные компании да бы они опорочили честное имя предпринимателя и господина министра лично.
Не надо путать глобальный рынок электроники и карман конкретно производителей систем хранения. Крупные закупки подобных систем случаются не часто и ни одна компания не откажется от него откусить что нибудь.
«Приезжала целая делегация Huawei из Гонконга, предлагали $100 млн за «Норси-Транс» полностью. На мой взгляд, они просто хотят, чтобы мы не делали русские серверы, а использовали серверы Huawei. Нам это неинтересно. Потом еще к [Александру] Киму, который делает «Эльбрус», бегали, предлагали какую-то кооперацию, сделать совместное предприятие», — рассказал Сергей Овчинников, владелец компании «Норси-Транс».
Если напрямую на руководство мцст выходили, то понятно почему менеджмент не вкурсе.
Но опять таки "совместное производство", то есть в серверы хуавей ставить эльбрус чтоб попасть в госзакупки, возможно кстати китайцы и лоббируют изменение правил, потому что американские компании не поню чтоб за 7лет какую либо активность проявляли, хотя чиновникам в первую очередь запретили закупать оборудование у hp и dell, мвд пфр и банк россии с 2015г пробуют ibm заместить эльбрусами, ibm палец о палец не ударила чтоб это прекратить, российский рынок американским ит гигантам не интересен, это видно по эпл это видно по всем остальным ( софтверные гуглы, майкрософты не в счет), а вот хуавей очень давно светится в госзакупках.
Что касается технологий, вспоминается ситуация когда китайцы скупили всю российскую мойву которая у нас стоила копейки, а потом эта мойва волшебным образом всплыла в американских школьных столовых.
Китайцы не хотят кусать и не хотят за долага купить васы супелтихналогии они хотят за три копейки купить то на что требуются долгие годы и миллиарды инвестиций. Но что бы купить эльбрус надо купить полностью мцст, воровать или лицензировать эльбрус бессмысленно, софта нет, самим писать/портировать компиляторы библиотеки на порядок сложнее чем для классического процессора вроде их лонг арчь, никакие китайские нововведения в системе команд комьюнити поддерживать не будет, потому что это ломает совместимость с оригиналом и нафиг не упало поддерживать китайские подделки, по опыту их баловства с мипс проверено.
Хуавей насколько помню пытался купить то ли аквариус то ли Норси-Транс "главного производителя систем хранения на эльбрусах для госорганов" если верить сми.
В итоге они купили каких то разрабов jvm, которые на них давно оутсорсили, главного поставщика железа для ведомств им ясное дело не продали, а мцст, по словам самой же мцст никаких предложений от хуавей ниразу не поступало.
Причем по словам тех кого они пытались купить переговоры сводились к тому что они тупо будут производить серверы хуавей что бы видимо хоть так попасть в госзакупки, никакие наши "передовые" технологии и разработки их не интересовали.
Ничего подобного они не собираются городить. Рантайм оптимизациями будет заниматься компилятор, а процессор будет собирать и выдавать ему статистику. Эта фича заявлена уже для Эльбрус-16С
В Эльбрус-32С хотят добавить предсказатель переходов, но не такой предсказатель как у суперскаляров если коротко это будет предсказатель подготовленных переходов и 7 управляющих регистров (сейчас только 3).
Надеюсь что они учтут так же подготовку предсказания вызовов, потому что текущая реализация не позволяет подготовить заранее два-три вызова и поочереди их дергать.
Я ничего не фантазирую а смотрю в ассемблер и на сообщения компилятора.
И он скомпилировал это без каких либо предупреждений, при этом в ассемблере хорошо видно что:
1. он загружает данные размером 32бита
2. кладет их в двойной регистр (младшую часть квадрорегистра), старшую часть заранее заполнил нулями,
3. и наконец делает над квадрорегистром адресное преобразование командой movtd (mov tag data или что то типа этого).
Скорее всего он создает таки локальный указатель на данные, по типу
(StructRGB *){0,0,0,}только с числом, используяarrкак переменную. Если это так то упало скорей всего из за+ indexнадо попробовать отставитьarr = (int*)startи посмотреть будет ли ссылка на число.А при чтении массива падать будет все равно потому что безопасный режим не разрешает читать неинициализированные данные надо его перед этим или заполнить или использовать memset(arr, 0 sizeof(int) * n)
Читать плачь про слишком строгие правила работы с указателем было забавно, учитывая что в других языках с ними вообще ничего нельзя делать, кроме как получить или передать. Запустите лучше вот такой код, если вам не сложно. Интересно все таки структура указателя, по ассемблеру получается что при складывании он увеличивает поле size, может расположение не такое просто.
Если речь про что то типа такого:
То это скорее всего работать не будет, но будет работать вот так:
Причина не в 128и битных указателях. В ассемблере адрес все равно ложится в виде числа на регистр, обращение к памяти происходит специальными командами, в том числе поддерживающими обращение по смещению. А вот сохранить на стек в виде указателя то что не является указателем уже нельзя, банально потому что указатель в безопасном режиме - это тип, а у типов строгие правила преобразования в (зависимости от языка).
В данном примере указатель складывается с целым, что по правилам Си дает указатель. Но вообще оказалось что работает и в первом случае, если расставить явные преобразования типов https://ce.mentality.rip/z/PcrYGM
К слову указатель на процедуру отличается, полагаю и работа с ним тоже. В любом случае весь вот этот безопасный режим это просто как аппаратная виртуальная машина для Си привносящая в него безопасность уровня джавы. И это не такой режим как в интеле при переключении 32/64 адресации, он работает как отдельное адресное пространство работа с которыми происходит через специальные команды. Функции из него наверное даже можно из небезопасного режима вызывать с некоторыми ограничениями, надо только в ОС реализовать поддержку.
Нет, не в кэши, а в конвеер. Устроено это примерно вот так:
Основной конвеер на девять (или больше) стадий, но в дополнение к нему есть еще 3 обрубка на 6 стадий. Обрубка в том смысле что в них код не исполняется никак, а лишь заполняется кодом функции или бранча на 6 (широких) команд и останавливается. Подготовка конвеера запускается командой
disp, %ctpr1, mallocпосле чего в любом удобном месте процедуры можно вызвать
call %ctpr1нижние стадии основного конвеера перецепляются к pipe1 после чего он становится основным, а предыдущий отрезается от исполнения и таким образом ждет возврата. Аргументы передаются путем наложения окна вызываемой процедуры на крайние регистры текущей, может это чуть менее эффективно чем наслоение процедур в интеле, но зато с точки зрения безопасности не подкопаешься.
Ну даже так может оказаться полезно вынести загрузку данных первой итерации из цикла, а в теле цикла разместить обработку этих данных вместе с загрузкой данных для следующей, как бы "открутив" от него.
А может и не начать
В то же самое время есть пример эльбруса в котором malloc можно подгрузить в дополнительный конвеер сильно заранее и вызвать за один такт когда понадобиться. Может это немного и не то по скорости, все таки пока не переключишься, никакие загрузки оттуда вперед не запустятся, но уж всяко быстрей заплаток безопасности и в статике прекрасно планируется. Хотя реализация на эльбрусе не позволяет например два вызова подготовить и поочередно их запустить, можно только подготовить один, вызвать и только после этого можно начать готовить второй.
Про раскрутку я говорил что "в коде или компиляторе" не во время исполнения естественно.
Спекулятивное/внеочередное исполнение не обладает возможностями ментального вызова функций с неизвестными аргументами для выделения памяти и мгновенным обращением к свежесозданному объекту в следующей итерации
Но оно может заранее попытаться подгрузить
node->left, node->right, node->bodyпрямо до проверкиnode->kind, от типа которого в том числе может зависеть и есть ли вообще эти поля как таковые. В том числе проделать это сразу для нескольких итераций путем раскрутки цикла в коде или компиляторе.АМД видимо не знали про критические цепи, поэтому у их видеокарт на VLIW частоты были раза этак в 2-3 выше чем у конкурента. И это же не значит что у нвидиа архитектура не позволяла сделать частоты выше, им теплопакет не позволял и жирный размер субядер (у амд под 500-1k на кристалл влазило, у нвидии сотня, максимум две). Пример АМД показателен еще и тем, что первые поколения этой архитектуры (R2000/3000) не давали впечатляющих результатов мягко говоря, но амд продолжала работать дорабатывать архитектуру, кодогенератор, пока в итоге не оказалось что middle-end радеон на уровне или даже обгоняет топ нвидии, и разрыв этот сохранялся вплоть до перехода на GCN. От влив ушли потому что для GPGPU старые ядра не подходили, создавать новый VLIW писать под него и добавлять поддержку в свободное ПО это конечно весело и увлекательно, но амд живет в условиях рынка который диктует свои правила.
Ну он во первых относится к поколению Э-8СВ на что как бы намекает контроллер памяти DDR4-2400 и дата выхода 2019г. Ну а в пятых-десятых это гораздо более простой и дохленький процессор уровня какого нибудь Cortex-A53 в китайфонах если не проще, при этом 1600Мгц версия 25Вт, а 2Ггц 35Вт вот и весь секрет. Кстати о кортексах - а какие критические цепи байкалу помешали сделать нормальные частоты "не как у эльбруса"? Сослаться на экономию энергии не выйдет ибо 8ядер и 10Гбит эзернет явно не для планшетов решение. Про обещаный серверный 2Ггц RISC-V на 16нм через пять лет вообще промолчу.
Они это достигают размером самого ядра, которое даже на крошечном по десктопным меркам кристалле 10% занимает если не меньше. В армах нет сложных технологий отключения кэшей/конвееров как в интелах, и этим они с эльбрусом одинаковые, у них есть рабочие частоты и рабочее напряжение 0.8-1.2V, которое даже на старых 45нм интелах позволяло работать на 1,5-3,0Ггц а на армах и эльбрусах только 800-1500Мгц на более тонких техпроцессах. Мотивация впрочем у них разная, у эльбрусов маленькие бюджеты и сроки, можно сказать чисто чтоб люди на работу ходили, студентов в средах проектирования работать учили, и раз в год-два чем то отчитывались сдавали "изделие" которое положат на полку и дадут задание на новое. У армов же рыночек порешал что дешевые массовые чипы за 10-20 долларов предпочтительнее более проработанных за 40-60 долларов. Вот и всё.
Еще в бородатые времена читал на Tom's Hardware (а может кстати и на хабре, не помню уже) что наращивание частоты упирается в скорость переключения транзисторов, 5Ггц для них предел и IBM работает над созданием новых которые позволят наращивать дальше вплоть до 10Ггц.
Но в статье пишут про 7nm Samsung так что врядли это та самая революция которую нам обещали. Ну и конечно же 960Мб L4 и 256Мб L3 впечатляет.
Высокие тактовые частоты достигаются более детальным уровнем проектирования микросхемы (full custom design). Никакие архитектуры здесь вообще непричем. На примере процессоров ARM нетрудно заметить что на тех же 16nm типичные частоты у них ~2Ггц, на 7-5нм уже подобрались к 3Ггц. И эльбрус и доступные на рынке ARM процессоры делаются из стандартных ячеек/блоков фабрики, а так высоких частот не достичь.
Конечно можно, в чем проблема? Мало тог, оно и выполняется сразу в следующем такте, nop 2 стоит для следующей команды, которая очевидно использует результат
ldw,0 %dr10, %dr3, %r0Вы бредите, даже в той же мцст разработкой софта (всего - библиотеки, компиляторы дистрибутив) занимается 20 человек, а железом 200. Во вторых какая бы железка не была, хоть за 100 хоть за 500 миллионов, под нее все равно придется софт портировать и ускорять под новые инструкции, автоматом к процессору ничего не прилогается.
Под несостоятельностью "VLIW подхода" он имеет в виду сугубо статичность аппаратуры, это даже не в плане in-order vs out-of-order, а в плане того что как сейчас в эльбрусе все шесть практически универсальных ALC вынуждены вставать на ожиданиях данных или чего то еще дружной командой, синхронно, потому что широкие команды подразумевают такую синхронизацию - вот это он называет под минусом широкой команды.
Но прошу обращаю внимание именно широкую команду он считает плохой а не эльбрус. Вот что он предлагает сейчас: динамические стрендыпо сути те же ALC и каждый стренд в своем кластере с дубликатом регистрового файла (привет эльбрус). Строгое in-order исполнение, никакого бранчпредиктора, код для стрендов готовит компилятор, контекстная безопасность (аkа "Безопасный режим"). Все по сути то же самое, все все что в каком то виде уже было в эльбрусах 1-2-3 - вот тебе развитие, никакого тупика в развитии родных идей Бабаян не видит.
Он же ОоО суперскаляр, у него все есть в железе и ему не нужно полагаться на компиляторы как какой нибудь там тупиковый VLIW. Они вон все ненадежные: https://godbolt.org/z/8qe454f4z компиляешь с максимальными оптимизациями -O3 а результат хуже чем с -O2 в два раза - 3.3 такта против 1.75
Гораздо проще и лучше транзисторов еще там сям приляпывать и вообще выкинуть компиляторы как класс на свалку истории. Пользователь только спасибо скажет, раньше одним и тем же процессором приходилось обходится по несколько лет, а теперь скажет с предвкушением откладываю на осенний сезон аппаратных обновлений.
Ты молодец, но ты забываешь что это именно эльбрусовская система команд тебе это позволила сделать. Для интела ты свой навык применять не можешь, ты не видишь микрокод и не знаешь что внутри происходит: https://godbolt.org/z/qaxdEeGo6 10~13 тактов интел тратит, никакие не три. Хватит людям в уши лить.
Да откуда вы берете эти три такта? Там в цикле 3000 итераций (10000 / 3) замеры выдают 22000 тактов на весь цикл что эквивалентно 7~8 тактов на итерацию.
Конечно это не 17 тактов, но и не один. В 7~8 раз медленней чем могло бы быть при инлайне (причем это самый минимум, так как цикл можно еще развернуть и ускорить в 100+ раз), но зато быстрее эльбруса на заведомо медленном коде в 2.5 раза.
Если сравнивать не с отдельными комплектующими с алиэкспресс/dns а с решениями от вендоров типа HP, то действительно бывает дешевле, например схд на эльбрусе 8с что то около 3,5млн руб обходились за штуку, тогда как у хп в том же формфакторе и за 5млн, а здоровые на 4юнита вовсе за 10.
Другой вопрос что у них железо на порядок производительней.
Шарманщик Карло обидел несчастного сироту Варраву (Barrabas идш). Руководствуясь завистью к чужому успеху заплатил продажным блогерам в колличестве 1 и натравил свои ручные компании да бы они опорочили честное имя предпринимателя и господина министра лично.
Госструктурам какая разница платно или бесплатно, деньги то казенные.
Не надо путать глобальный рынок электроники и карман конкретно производителей систем хранения. Крупные закупки подобных систем случаются не часто и ни одна компания не откажется от него откусить что нибудь.
Там же написано:
Если напрямую на руководство мцст выходили, то понятно почему менеджмент не вкурсе.
Но опять таки "совместное производство", то есть в серверы хуавей ставить эльбрус чтоб попасть в госзакупки, возможно кстати китайцы и лоббируют изменение правил, потому что американские компании не поню чтоб за 7лет какую либо активность проявляли, хотя чиновникам в первую очередь запретили закупать оборудование у hp и dell, мвд пфр и банк россии с 2015г пробуют ibm заместить эльбрусами, ibm палец о палец не ударила чтоб это прекратить, российский рынок американским ит гигантам не интересен, это видно по эпл это видно по всем остальным ( софтверные гуглы, майкрософты не в счет), а вот хуавей очень давно светится в госзакупках.
Что касается технологий, вспоминается ситуация когда китайцы скупили всю российскую мойву которая у нас стоила копейки, а потом эта мойва волшебным образом всплыла в американских школьных столовых.
Китайцы не хотят кусать и не хотят за долага купить васы супелтихналогии они хотят за три копейки купить то на что требуются долгие годы и миллиарды инвестиций. Но что бы купить эльбрус надо купить полностью мцст, воровать или лицензировать эльбрус бессмысленно, софта нет, самим писать/портировать компиляторы библиотеки на порядок сложнее чем для классического процессора вроде их лонг арчь, никакие китайские нововведения в системе команд комьюнити поддерживать не будет, потому что это ломает совместимость с оригиналом и нафиг не упало поддерживать китайские подделки, по опыту их баловства с мипс проверено.
Хуавей насколько помню пытался купить то ли аквариус то ли Норси-Транс "главного производителя систем хранения на эльбрусах для госорганов" если верить сми.
В итоге они купили каких то разрабов jvm, которые на них давно оутсорсили, главного поставщика железа для ведомств им ясное дело не продали, а мцст, по словам самой же мцст никаких предложений от хуавей ниразу не поступало.
Причем по словам тех кого они пытались купить переговоры сводились к тому что они тупо будут производить серверы хуавей что бы видимо хоть так попасть в госзакупки, никакие наши "передовые" технологии и разработки их не интересовали.