Ему ориентироваться на предсказатель ветвлений и генерировать код где этот предсказатель покажет всю свою силу милое дело.
jit компилятор не пишет код он его компилирует, вся разница в том что у него на руках есть статистика исполнения, он видит сколько у циклов итераций, в какой бранчь вообще никогда не переходят итп и может применять очень агрессивные оптимизации, разворачивать, выкидывать, заменять. Бранчпредиктор как раз при прыжках из неоптимизованного кода в отимизованный и обратно только мешается.
Процессору поступает самый обычный нативный код. Байткод обрабатывается компилятором. При чем тут процессор непонятно.
Байткод исполняется в виртуальной машине (виртуальном процессоре) который рабортает поверх настоящего, это такая схема работы. А эльбрусу надо полностью всю программу снизу доверху, а то еще и из дополнительных файлов, и строить оптимальное исполнение
Нужно "всего лишь" написать оптимальный jit комплятор под Эльбрус.
Проблема в том джиты для языков уже написаны, ты можешь только в них добавить поддержку своей архитектуры, но качественно поддержать все возможности эльбруса в них не получится так как изменения сумарно потянут на отдельный джит. Представляешь себе V8 в котором 100мб исходников для всех архитектур и 100мб персоонально для эльбруса. Врядли такое произойдет, надо либо держать форк согласованый с основной веткой либо написать свой отдельный vm/jit не связанный с конкретным языком а во все проекты протолкнуть поддержку его представления.
Предсказатель ветвлений это костыль предугадывающий инструкции из какого бранча готовить прежде чем вообще дойдет до инструкции вызова или перехода. Программисту на него нельзя никак вообще опираться, так как это чисто аппаратная хреновина, программисты наоборот чаще его пытаются обойти всякими уродливыми ухищрениями, если в коде поджидают явные или частые ошибки предсказания.
У эльбруса проблемы с джитом из за своей процедурной безопасности и стековости. Джит подразумевает что безопасность обеспечивается его рантаймом, а машине безопасной быть не нужно, так как это тоже забирает эффективность/скорость. В принципе у них же есть небезопасный режим для совместимости с интелом, не знаю почему они его не хотят использовать для рантайм языков а заставляют портировать в обычный режим с его защищенными стеками, либо может там дофига делов с тем что бы увязать все это в ядре ОС.
Ну и еще проблема с байткодами виртуальной машины, там посути поток команд для виртуального процессора, а эльбрусу надо чтоб ему код раздербанили на задачи.
Товарищь профессионал форумов и клавиатуры, маневры от отрицания до придирок к каким то якобы не правильным терминам я могу проигнорировать, но обвинения меня в мантрах и тут же мне зачитать мантру про то что в эльбрусе там все уже что можно сделано и все , не на что тут смотреть это просто ни в какие ворота уже. С чего ты это взял вообще, ты в глаза не видел кто и на чем его разрабатывает и такие заявы делаешь.
Я обычный человек и говорю так как понятно мне и таким же как я. Под физ.дизайном я в данном контексте подразумеваю дизайн транзисторных блоков/элементов а не какой то логики. То что это в какой то там среде проектировщиков считается оскарблением меня не касается, завтра придет дядя вася с паяльником и скажет что ФИЗ это когда ты вот руками берешь травишь, паяешь, дорожки чертишь и у них в мастерской за такие ошибки вообще убивают сразу же.
Ещё в первой статье выше (которая якобы про фпга), содержит раздел про Analog-Digital Mixed дезигн - оно? Как бы там нибыло я подразумеваю разработку специальных блоков под разные устройства, не может это не давать прирост.
Вон мцст сделали кастом дизайн кешей у них поместилось 1мб L2 на ядро вместо прежних 512к. Сразу же вспоминаются интел и амд середины нулевых, у амд и полноценный четырехядерник и мму в кристалле но кэш 300кб на ведро и слив интелу с кэшами полтора три мегабайта.
Это что, шутка? Кто вообще на серьезных щах будет доказывать что кремний лучше чем фпга.
Полагал ты скажешь что нибудь типа реклама компаний которые на кастомных блоках бабки дела делают но отрицания вообще не ожидал. https://www.asicnorth.com/offerings/
ASIC North will work with your design team to create and verify a custom Intellectual Property (IP) block design. We have years of experience developing IP blocks such as biomedical sensor interfaces, voltage references, multiple A/D and D/A converters architectures, RFID circuits, IoT components and more.
We will also generate a complete set of IP deliverables (*.v, *.lib, *.lef, etc) which allow you to easily integrate the IP into your ASIC design.
А под светлым знаменем risc-v пролетарии всех стран объединятся и пойдут в светлое будущее. Уже тысячи компаний обратили на него свой пристальный взор и нет никаких сомнений, товарищи, что это будущее вот вот наступит. Нет, мы уже в нем живем, прямо сейчас. Предлагаю единогласно проголосовать "ЗА". Похлопаем.
для моторолы68k в дебиане наверное пакетов еще больше и что? либреофис запущеный на "правильном процессоре" майкрософт офисом не станет. Эльбрус лучше потому что мцст контролирует систему команд, патенты с ней связанные, систему прерываний, всю платформу. Имеет ядерщиков, библиотечников и компиляторщиков. Охват базового стека софта и полный контроль железа приблежает на одну ступеньку к таким компаниям как интел и нвидиа, про которых кто бы что не говорил но их железо ставят в серьезные системы, а в амд только школьники гоняют в киберпанк и майнят. Тот же майор может позвонить в мцст и сказать: "на ведомственном сайте ок а на котиках вконтакте проседает производительность в браузере сделайте что нибудь" и мцст выделит специалиста заниматься этим делом либо знает кому передать на аутсорс, а что скажет байкал или синтакор? "пишите в мазилу в багзиллу или nekonekonyan -у в гит ижуи, мы к софту который на нашем железе работает не имеем отношения"? Сопровождение нужного тебе софта и помощь от сообщества ты не получишь нахаляву, все равно требуется чью то еще отдельно покупать. Свободное от патентов ISA - это не спо и не свободное железо даже, его нельзя взять себе как нельзя взять себе питон или с++, это стандарт только языка железа. я не слышал аргументов в духе "зачем делать раст если есть го", или "зачем делать свифт если есть котлин". или вот зачем эплу понадобился Obj-c вместо плюсов? Да потому что у них было иное виденье ООП и оно лучше реализовывало те задачи, которые эпл реализовали в своей ос и ее api. Примут ли в риск-5 расширения касающиеся ускорения российских криптоалгоритмов, или там тензорных для росатома или двигателистов? Никогда, а вот aes или sha1024 я уверен вполне. Про безопасные режимы даже говорить бессмысленно, нужна ли нам не удобная под наши задачи, а некая "стандартизированная" какими то джонами система команд? Я не вижу в этом плюсов, одни минусы. Отпортировать весь стек СПО и протолкнуть арч в апстримы это дело наживное, хоть и не простое в случае с эльбрусами тупо в силу того что это в первую очередь теговая и стековая архитектура, что создает проблемы в адаптации низкоуровневых приложений, ну и влив мешает портированию компиляторов. Но зато все знают что е2k это е2k, семейство процессоров с конкретной архитектурой а не подмножество с вольным набором расширений.
Ты в барнауле живешь, ау. Причем здесь эпл или гравитон?
Риск-5 это система команд, простая, последовательная, сама она дает только бинарную совместимость (с кое как портированным на нее спо, лол) все что нужно для ее эффективного исполнения необходимо разрабатывать с нуля. Хотя бы на уровне кортексов не самых новых, а уж что бы их переплюнуть и подобраться ближе к интел/амд надо перейти на кастомный физ. дизайн. Уверен в 2ггц 12нм восьмиядернике все будет и физдизайн и кокаин и шлюхи. И все на частные деньги - 18млрд даст частная компания ростех а 5млрд ядро возьмет кредитом во внешэкономбанке у шувалова, и на госзакупках в школы и куда то там еще отобъют, все честно рыночно, интел напрягся.
Цимес в том что весь перечисленный зоопарк не обладает стеком унникального софта как intel и arm, они все вместе с эльбрусом могут рпассчитывать максимум на открытое ПО под линукс и ПО от отечественных разработчиков, никакой риск-5 который по скорости будет максимум как эльбрус, не поможет, никто на него не перенесет ни кады ни сапры его самого будут проектировать на интеле а путину чемезов представит очередной планшет, только уже с третьегномом если его к тому времени портируют с полноценной графикой. Это максимум что будет через 5лет, очередной никому не нужный процессор без софта.
Надо все силы киидать в софт, переносить всё необходимое спо под эльбрус, допиливать трансляцию x86, чтоб где это безальтернативно, он мог интел заменить.
Байкалу дать по репе и привести их в чуства, у нас огромный спрос на арм/мипс устройства, мультимедийные системы типа яндекс авто, сеилфиш ос она же аврора, роутеры всякие, кассы станки, они компьютеры на линуксе собирают никому не нужные и лезут в госзакупки по квотам, и еще серверы собираются так же толкать, они или не нормальные или кто-то там пилит бабло тупо.
Элвису пусть делает ускорители потокового видео и прочего, модуль тензорные ядра и всех объеденить в группу чтоб использовали наработки друг друга и свободно лицензировались.
Даже если в твоем интеле супернавороченный предиктор, который запоминает интервалы между входом в бранчь, пароли от банковских карт и в какой папке хранится цп, то все равно он это выучит не сразу, а у твоих пользователей интел может быть не такой крутой и новый, или вовсе неинтел. Так то надо это тоже учитывать.
Компилятор в случае с амд атлоном с дедовским предсказателем, может развернуть цикл на несколько итераций вперед чтоб хотя бы помочь суперскаляру загрузки/сравнения запускать параллельно, так как он видит что они ни от чего не зависят. В случае с эльбрусом компилятор вовсе знает сколько длится подготовки переходов и загрузки, пока готовится конвеер с функцией принт, он может сравнить уже заранее подгруженный a[i] > 0, запустить загружаться a[i+1] условно выполнить подготовленный print ? p1 и перейти в следующую итерацию.
Бранчпредиктор - это умный лифт который пытается угадать на каком этаже ловить пассажира и подоспеть чтоб он как можно меньше ждал, подготовки - это два лифта с кнопками, один поедет за твоим другом наверх, второй поедет к тебе, и должно получится так что когда твой друг спустится приехал уже грузовой лифт куда вы вдвоем погрузите диван и поедете на первый этаж, чтоб никто никого не ждал.
явное количество итераций цикла, это само по себе большой простор для оптимизаций вплоть до инлайн подстановки заранее посчитанного результата, во вторых твой код как раз заставляет дристать под себя предсказатель переходов и рекламирует условное исполнение через флаги или через предикаты (без разницы) которые целиком ориентированы на подстановку компилятором.
void ex(int arr[], const int idx[], const int isz)
{
for (int n = 0; n < isz; n++)
arr[idx[n]] += n;
}
Поздравляю, мы не можем статически предсказать куда проходит запись может быть все пишут в один элемент массива а может быть в один элемент тут несколько раз запись проходит, и поэтому мы не можем спекулятивно (заранее) загружать значения из arr, а это значит что надо ждать пока загрузится idx[n] и потом только arr[ idx] и причем мы не можем параллельно итерации обрабатывать, так как вдруг следующая пишет туда же.
логически мы можем обрабатывать этот алгоритм только последовательно, тогда как в рантайме у нас на руках есть реальные данные и внеочередное исполнение может видеть что зависит а что нет, что можно обработать параллельно, а что нет.
Но даже в этом случае умный компилятор+адекватный программист эффективнее внеочередных костылей. Компилятор видит что ничего не мешает пихнуть указатели на один и тот же массив и картина обработки массива резко меняется, и можно подготовить код на оба случая если программист не запретил рассматривать такие случаи всякими там рестриктами и ассертами. Можно ловить пересечения сравнивая адреса и сопоставляя предикаты, в конце концов программист видя что компилятор слишком замороченый код генерит, разделит циклы, отсортирует сгруппирует а компилятору останется только развернуть итерации.
Один писал эмулятор команд суперскаляра для эльбруса пришел к выводу что раз в ассемблере х86 микрокода и пайплайна не видно значит там такой проблемы нет, а декодируется исполняется,конвейризируется и инлайнится там все так же как в компиляторе и все за один такт а то и меньше.
Второй поверх суперскаляра городил явно управляемую машину и пришел почему то к выводу что на целевой машине тоже при переходах все откидывается и берется со стека, а порядок исполнения интеловский ассемблер не позволяет нарушать и поэтому это проблема эльбруса что он не позволяет силами x86 isa реализовать какие то свои причуды с порядком исполнения действий с операндами. А пайплайн это что то из мифологии и 6 тактов подготовка просто потому что глупые люди делали надо просто прыжок делать за один такт и всё, как на умных интелах.
Все ровно наоборот - в Itanium первого поколения (Marced вроде) бы аппаратный энджин для х86 и работало это просто позорно, где то на уровне 386го или даже ниже. В Itanium II его выкинули и сделали бинарную трансляцию как в эльбрусе и крузо, стало хотя бы как равночастотный пень3, что кстати до сих пор демонстрирует эльбрус и это очень печально. Если бы интел, трансмета и мцст не пилили бы свои проприетарные поделки каждый в своем темном углу а вносили бы общий вклад открывая свои поделия, дело бы гораздо дальше продвинулось за 20 то лет.
Не знаю синхронизовано ли это было с покупкой интелом бабаяновской команды, но так же во втором итаниуме появились конвейризованные циклы (такие же как на эльбрусе), а в x86 появился nX-bit - по сути безопасный режим с тегом исполняемости реализованый трансметой в рамках ограничений ia32 и лицензированный интелом.
Так что да, обмен шел активный, жаль только не в сфере ПО, потому что jit-ы, компиляторы, кодеморфинги пилившиеся под итаниум и трансметовские процессоры все похерены.
Я с ваами сам отупел уже, думаю про волшебную коробочку где чик брик все за один такт исполняется и напрочь забыл про конвейер.
Прыжки на начало цикла без подготовок работают только в loop_mode инструкциях, просто потому что (не знаю как это работает) они в конвеере не опустошаются а мотаются бесконечно пока не переключишься. В иных случаях после каждого вызова/перехода надо готовить конвейер заного, но это не значит что нельзя сделать подготовку ДО потом прыгнуть в цикл вызвать подготовленный CALL вернуться и тут же его опять начать готовить вместе со сложением и прочим до возврата в начало цикла, так как это все в рамках одной процедуры которая задается процедурным окном о каких таких исключениях речь я не понимаю.
У интела пайплайн в два три раза длиннее кстати, какой там нахрен один такт при переходах.
Ну и алу все конечно тоже конвейризованные, конечно можно r0 на считывание всем заюзать, тут я тупанул.
Это статический компилятор сделает в компаил тайме, тупо тебе принты с нужными патернами в стопочку напишет и все.
В динамических языках как правило работа с массивом переменной длинны и вызовом юзерской функции переданной аргументом и все это jit в рантайме ловит и оптимизирует в том числе используя инлайн.
Э нет, уважаемый, подготовка перехода происходит ДО входа в цикл, а попутно еще надо проверить условие вообще входа в цикл, в самом цикле подготовку каждую итерацию не делают, уж если не хватило конвеера для функции (хотя как раз три то и хватает - цикл+функция+выход из цикла) проще непосредственный бранч/вызов делать.
А вызовы он не может делать только в конвейризованных циклах (loop mode) - это специальный аппаратный режим необходимый прежде всего что бы вращаемые регистры по базе автоматически сдвигалить, ну и плюс там счетчики автоинкриментировались и прочее.
У оутофордеров нет такого режима, у них бранч - раз инструкция - два инструкция - сравнение каких-то операндов - хоп джамп в тот же бранч, процессор даже не знает что он в цикле работает, эльбрус делает так же в самых глухих случаях типа while (ptr1 != NULL) он не отличается (с точки зрения процессора) от обычной процедуры и вызовы из нее делаются хоть куда. У интела будет колл и мов константы у эльбруса подготовленный кол и add литерал с r0, хочешь показать пример на котором эльбрус обсирается так хоть у знающих людей спрашивай совета перед тем как что то объяснять на глупых примерах. В данном примере эльбрус скорее потому что его компилятор будет этот цикл оптимизировать, тогда как гцц на*уй выкинет вообще и вставит загрузку константы.
>Если в данном цикле вызов функции get_int_val по какой-то причине не заинлайнится компилятором, то для RISC/CISC архитектуры с OoO итерация цикла будет занимать ~1 такт, не отличаясь принципиально от случая, если инлайн сработал. В то же время на Эльбрусе одна итерация данного цикла будет занимать порядка 17 тактов.
Начнем с того что с высокой долей вероятности компилятор для интела (clang/gcc) подставит вместо этого цикла константу, не то что что-то синлайнит. Во вторых хотелось бы какие то замеры увидеть куда интел денет вызов? Я понимаю бранчь предиктор сгладит это всё но сам вызов и ожидание из функции никуда не денется, и цикл сам по себе не развернется, процессор будет делать все вызовы и переходы. На эльбрусе нет бранчпредиктора, но там просто вызовы и переходы тупо явно подготавливаются в доп.конвеер (коих три у него) и переключаются за один такт. Но это не значит что итерация будет занимать такт, такт занимало бы простое сложение чисел, но никак не с вызовом чего то.
r0 нельзя использовать в одной ШК сразу для трех операций, второй пример ассемблера демонстрирует так называемый конвейризованный цикл - аппаратную фичу эльбруса которая позволяет обращаться к массиву данных минуя кэш не используя обычные лоады/сторы а используя мувы из буфера подкачки.
Конечно без инлайна функции это не работает так как вызовы в конвейризованных циклах не допускаются и будет обычный цикл как на интеле с прыжком наверх - и чё? В чем недостаток, я не понял.
Как и не понял что там и где у тебя в коде нельзя проанализировать, где в чем тупик.
Понял только что ассемблер сложный-нипанятный а в документацию посмотреть хотя бы перед написанием статьи мы не умеем.
В общем статья уровня школьник для школьников пересказал какие то тезисы из интернета и приправил своей безграмотной отсебятиной.
Обычно под "64битный процессор" понимают размер указателей, все современные процессоры поддерживают адресацию через 32/64бит указатель эльбрус ещё умеет 128битные указатели, но сам размер адресуемых данных по такому указателю - 32бит там и команды загрузки по 32битному и 128и разрядному одинаковые используются.
Что касается регистров, то еще в mmx были 64битные регистры, в sse уже ввели 128и битные, а в avx 256 битные. А считается это так - либо ты 2 QP(128)/такт посчитаешь, либо 4 DP(64) либо 8 SP(32) за один такт. У эльбруса регистры 64 битные (на самом деле 80битные но не суть) в грядущих 8св/16с уже 128и битные. Но зато все 256, а не только какие то там специальные xmm0/ymm0/zmm0 как на интеле
Ну да там подумаешь циклик какой то ничтожный по пикселям/сжимаемым данным блоками ходит, архиватор/либа входные данные - вжик за полсекунды и где там энтот симд успел поработать пойди найди под микроскопом, кода то вон сколько.
jit компилятор не пишет код он его компилирует, вся разница в том что у него на руках есть статистика исполнения, он видит сколько у циклов итераций, в какой бранчь вообще никогда не переходят итп и может применять очень агрессивные оптимизации, разворачивать, выкидывать, заменять. Бранчпредиктор как раз при прыжках из неоптимизованного кода в отимизованный и обратно только мешается.
Байткод исполняется в виртуальной машине (виртуальном процессоре) который рабортает поверх настоящего, это такая схема работы. А эльбрусу надо полностью всю программу снизу доверху, а то еще и из дополнительных файлов, и строить оптимальное исполнение
Проблема в том джиты для языков уже написаны, ты можешь только в них добавить поддержку своей архитектуры, но качественно поддержать все возможности эльбруса в них не получится так как изменения сумарно потянут на отдельный джит. Представляешь себе V8 в котором 100мб исходников для всех архитектур и 100мб персоонально для эльбруса. Врядли такое произойдет, надо либо держать форк согласованый с основной веткой либо написать свой отдельный vm/jit не связанный с конкретным языком а во все проекты протолкнуть поддержку его представления.
Предсказатель ветвлений это костыль предугадывающий инструкции из какого бранча готовить прежде чем вообще дойдет до инструкции вызова или перехода. Программисту на него нельзя никак вообще опираться, так как это чисто аппаратная хреновина, программисты наоборот чаще его пытаются обойти всякими уродливыми ухищрениями, если в коде поджидают явные или частые ошибки предсказания.
У эльбруса проблемы с джитом из за своей процедурной безопасности и стековости. Джит подразумевает что безопасность обеспечивается его рантаймом, а машине безопасной быть не нужно, так как это тоже забирает эффективность/скорость. В принципе у них же есть небезопасный режим для совместимости с интелом, не знаю почему они его не хотят использовать для рантайм языков а заставляют портировать в обычный режим с его защищенными стеками, либо может там дофига делов с тем что бы увязать все это в ядре ОС.
Ну и еще проблема с байткодами виртуальной машины, там посути поток команд для виртуального процессора, а эльбрусу надо чтоб ему код раздербанили на задачи.
Товарищь профессионал форумов и клавиатуры, маневры от отрицания до придирок к каким то якобы не правильным терминам я могу проигнорировать, но обвинения меня в мантрах и тут же мне зачитать мантру про то что в эльбрусе там все уже что можно сделано и все , не на что тут смотреть это просто ни в какие ворота уже. С чего ты это взял вообще, ты в глаза не видел кто и на чем его разрабатывает и такие заявы делаешь.
Я обычный человек и говорю так как понятно мне и таким же как я. Под физ.дизайном я в данном контексте подразумеваю дизайн транзисторных блоков/элементов а не какой то логики. То что это в какой то там среде проектировщиков считается оскарблением меня не касается, завтра придет дядя вася с паяльником и скажет что ФИЗ это когда ты вот руками берешь травишь, паяешь, дорожки чертишь и у них в мастерской за такие ошибки вообще убивают сразу же.
Ещё в первой статье выше (которая якобы про фпга), содержит раздел про Analog-Digital Mixed дезигн - оно? Как бы там нибыло я подразумеваю разработку специальных блоков под разные устройства, не может это не давать прирост.
Вон мцст сделали кастом дизайн кешей у них поместилось 1мб L2 на ядро вместо прежних 512к. Сразу же вспоминаются интел и амд середины нулевых, у амд и полноценный четырехядерник и мму в кристалле но кэш 300кб на ведро и слив интелу с кэшами полтора три мегабайта.
Это что, шутка? Кто вообще на серьезных щах будет доказывать что кремний лучше чем фпга.
Полагал ты скажешь что нибудь типа реклама компаний которые на кастомных блоках бабки дела делают но отрицания вообще не ожидал. https://www.asicnorth.com/offerings/
И чтоб совсем уж поставить точку в вопросе:
https://www.eng.uwo.ca/people/wwang/ece616a/616_extra/notes_web/1_dintro.pdf
О, кастомный дизайн - лженаучный миф капитализма https://www.electronicdesign.com/technologies/analog/article/21807187/11-myths-about-custom-silicon
А под светлым знаменем risc-v пролетарии всех стран объединятся и пойдут в светлое будущее. Уже тысячи компаний обратили на него свой пристальный взор и нет никаких сомнений, товарищи, что это будущее вот вот наступит. Нет, мы уже в нем живем, прямо сейчас. Предлагаю единогласно проголосовать "ЗА". Похлопаем.
для моторолы68k в дебиане наверное пакетов еще больше и что? либреофис запущеный на "правильном процессоре" майкрософт офисом не станет. Эльбрус лучше потому что мцст контролирует систему команд, патенты с ней связанные, систему прерываний, всю платформу. Имеет ядерщиков, библиотечников и компиляторщиков. Охват базового стека софта и полный контроль железа приблежает на одну ступеньку к таким компаниям как интел и нвидиа, про которых кто бы что не говорил но их железо ставят в серьезные системы, а в амд только школьники гоняют в киберпанк и майнят. Тот же майор может позвонить в мцст и сказать: "на ведомственном сайте ок а на котиках вконтакте проседает производительность в браузере сделайте что нибудь" и мцст выделит специалиста заниматься этим делом либо знает кому передать на аутсорс, а что скажет байкал или синтакор? "пишите в мазилу в багзиллу или nekonekonyan -у в гит ижуи, мы к софту который на нашем железе работает не имеем отношения"? Сопровождение нужного тебе софта и помощь от сообщества ты не получишь нахаляву, все равно требуется чью то еще отдельно покупать. Свободное от патентов ISA - это не спо и не свободное железо даже, его нельзя взять себе как нельзя взять себе питон или с++, это стандарт только языка железа. я не слышал аргументов в духе "зачем делать раст если есть го", или "зачем делать свифт если есть котлин". или вот зачем эплу понадобился Obj-c вместо плюсов? Да потому что у них было иное виденье ООП и оно лучше реализовывало те задачи, которые эпл реализовали в своей ос и ее api. Примут ли в риск-5 расширения касающиеся ускорения российских криптоалгоритмов, или там тензорных для росатома или двигателистов? Никогда, а вот aes или sha1024 я уверен вполне. Про безопасные режимы даже говорить бессмысленно, нужна ли нам не удобная под наши задачи, а некая "стандартизированная" какими то джонами система команд? Я не вижу в этом плюсов, одни минусы. Отпортировать весь стек СПО и протолкнуть арч в апстримы это дело наживное, хоть и не простое в случае с эльбрусами тупо в силу того что это в первую очередь теговая и стековая архитектура, что создает проблемы в адаптации низкоуровневых приложений, ну и влив мешает портированию компиляторов. Но зато все знают что е2k это е2k, семейство процессоров с конкретной архитектурой а не подмножество с вольным набором расширений.
Ты в барнауле живешь, ау. Причем здесь эпл или гравитон?
Риск-5 это система команд, простая, последовательная, сама она дает только бинарную совместимость (с кое как портированным на нее спо, лол) все что нужно для ее эффективного исполнения необходимо разрабатывать с нуля. Хотя бы на уровне кортексов не самых новых, а уж что бы их переплюнуть и подобраться ближе к интел/амд надо перейти на кастомный физ. дизайн. Уверен в 2ггц 12нм восьмиядернике все будет и физдизайн и кокаин и шлюхи. И все на частные деньги - 18млрд даст частная компания ростех а 5млрд ядро возьмет кредитом во внешэкономбанке у шувалова, и на госзакупках в школы и куда то там еще отобъют, все честно рыночно, интел напрягся.
Цимес в том что весь перечисленный зоопарк не обладает стеком унникального софта как intel и arm, они все вместе с эльбрусом могут рпассчитывать максимум на открытое ПО под линукс и ПО от отечественных разработчиков, никакой риск-5 который по скорости будет максимум как эльбрус, не поможет, никто на него не перенесет ни кады ни сапры его самого будут проектировать на интеле а путину чемезов представит очередной планшет, только уже с третьегномом если его к тому времени портируют с полноценной графикой. Это максимум что будет через 5лет, очередной никому не нужный процессор без софта.
Надо все силы киидать в софт, переносить всё необходимое спо под эльбрус, допиливать трансляцию x86, чтоб где это безальтернативно, он мог интел заменить.
Байкалу дать по репе и привести их в чуства, у нас огромный спрос на арм/мипс устройства, мультимедийные системы типа яндекс авто, сеилфиш ос она же аврора, роутеры всякие, кассы станки, они компьютеры на линуксе собирают никому не нужные и лезут в госзакупки по квотам, и еще серверы собираются так же толкать, они или не нормальные или кто-то там пилит бабло тупо.
Элвису пусть делает ускорители потокового видео и прочего, модуль тензорные ядра и всех объеденить в группу чтоб использовали наработки друг друга и свободно лицензировались.
Даже если в твоем интеле супернавороченный предиктор, который запоминает интервалы между входом в бранчь, пароли от банковских карт и в какой папке хранится цп, то все равно он это выучит не сразу, а у твоих пользователей интел может быть не такой крутой и новый, или вовсе неинтел. Так то надо это тоже учитывать.
Компилятор в случае с амд атлоном с дедовским предсказателем, может развернуть цикл на несколько итераций вперед чтоб хотя бы помочь суперскаляру загрузки/сравнения запускать параллельно, так как он видит что они ни от чего не зависят. В случае с эльбрусом компилятор вовсе знает сколько длится подготовки переходов и загрузки, пока готовится конвеер с функцией принт, он может сравнить уже заранее подгруженный a[i] > 0, запустить загружаться a[i+1] условно выполнить подготовленный print ? p1 и перейти в следующую итерацию.
Бранчпредиктор - это умный лифт который пытается угадать на каком этаже ловить пассажира и подоспеть чтоб он как можно меньше ждал, подготовки - это два лифта с кнопками, один поедет за твоим другом наверх, второй поедет к тебе, и должно получится так что когда твой друг спустится приехал уже грузовой лифт куда вы вдвоем погрузите диван и поедете на первый этаж, чтоб никто никого не ждал.
явное количество итераций цикла, это само по себе большой простор для оптимизаций вплоть до инлайн подстановки заранее посчитанного результата, во вторых твой код как раз заставляет дристать под себя предсказатель переходов и рекламирует условное исполнение через флаги или через предикаты (без разницы) которые целиком ориентированы на подстановку компилятором.
Поздравляю, мы не можем статически предсказать куда проходит запись может быть все пишут в один элемент массива а может быть в один элемент тут несколько раз запись проходит, и поэтому мы не можем спекулятивно (заранее) загружать значения из arr, а это значит что надо ждать пока загрузится idx[n] и потом только arr[ idx] и причем мы не можем параллельно итерации обрабатывать, так как вдруг следующая пишет туда же.
логически мы можем обрабатывать этот алгоритм только последовательно, тогда как в рантайме у нас на руках есть реальные данные и внеочередное исполнение может видеть что зависит а что нет, что можно обработать параллельно, а что нет.
Но даже в этом случае умный компилятор+адекватный программист эффективнее внеочередных костылей. Компилятор видит что ничего не мешает пихнуть указатели на один и тот же массив и картина обработки массива резко меняется, и можно подготовить код на оба случая если программист не запретил рассматривать такие случаи всякими там рестриктами и ассертами. Можно ловить пересечения сравнивая адреса и сопоставляя предикаты, в конце концов программист видя что компилятор слишком замороченый код генерит, разделит циклы, отсортирует сгруппирует а компилятору останется только развернуть итерации.
Да вижу.
Один писал эмулятор команд суперскаляра для эльбруса пришел к выводу что раз в ассемблере х86 микрокода и пайплайна не видно значит там такой проблемы нет, а декодируется исполняется,конвейризируется и инлайнится там все так же как в компиляторе и все за один такт а то и меньше.
Второй поверх суперскаляра городил явно управляемую машину и пришел почему то к выводу что на целевой машине тоже при переходах все откидывается и берется со стека, а порядок исполнения интеловский ассемблер не позволяет нарушать и поэтому это проблема эльбруса что он не позволяет силами x86 isa реализовать какие то свои причуды с порядком исполнения действий с операндами. А пайплайн это что то из мифологии и 6 тактов подготовка просто потому что глупые люди делали надо просто прыжок делать за один такт и всё, как на умных интелах.
Так и живем.
Все ровно наоборот - в Itanium первого поколения (Marced вроде) бы аппаратный энджин для х86 и работало это просто позорно, где то на уровне 386го или даже ниже. В Itanium II его выкинули и сделали бинарную трансляцию как в эльбрусе и крузо, стало хотя бы как равночастотный пень3, что кстати до сих пор демонстрирует эльбрус и это очень печально. Если бы интел, трансмета и мцст не пилили бы свои проприетарные поделки каждый в своем темном углу а вносили бы общий вклад открывая свои поделия, дело бы гораздо дальше продвинулось за 20 то лет.
Не знаю синхронизовано ли это было с покупкой интелом бабаяновской команды, но так же во втором итаниуме появились конвейризованные циклы (такие же как на эльбрусе), а в x86 появился nX-bit - по сути безопасный режим с тегом исполняемости реализованый трансметой в рамках ограничений ia32 и лицензированный интелом.
Так что да, обмен шел активный, жаль только не в сфере ПО, потому что jit-ы, компиляторы, кодеморфинги пилившиеся под итаниум и трансметовские процессоры все похерены.
Я с ваами сам отупел уже, думаю про волшебную коробочку где чик брик все за один такт исполняется и напрочь забыл про конвейер.
Прыжки на начало цикла без подготовок работают только в loop_mode инструкциях, просто потому что (не знаю как это работает) они в конвеере не опустошаются а мотаются бесконечно пока не переключишься. В иных случаях после каждого вызова/перехода надо готовить конвейер заного, но это не значит что нельзя сделать подготовку ДО потом прыгнуть в цикл вызвать подготовленный CALL вернуться и тут же его опять начать готовить вместе со сложением и прочим до возврата в начало цикла, так как это все в рамках одной процедуры которая задается процедурным окном о каких таких исключениях речь я не понимаю.
У интела пайплайн в два три раза длиннее кстати, какой там нахрен один такт при переходах.
Ну и алу все конечно тоже конвейризованные, конечно можно r0 на считывание всем заюзать, тут я тупанул.
Это статический компилятор сделает в компаил тайме, тупо тебе принты с нужными патернами в стопочку напишет и все.
В динамических языках как правило работа с массивом переменной длинны и вызовом юзерской функции переданной аргументом и все это jit в рантайме ловит и оптимизирует в том числе используя инлайн.
Э нет, уважаемый, подготовка перехода происходит ДО входа в цикл, а попутно еще надо проверить условие вообще входа в цикл, в самом цикле подготовку каждую итерацию не делают, уж если не хватило конвеера для функции (хотя как раз три то и хватает - цикл+функция+выход из цикла) проще непосредственный бранч/вызов делать.
А вызовы он не может делать только в конвейризованных циклах (loop mode) - это специальный аппаратный режим необходимый прежде всего что бы вращаемые регистры по базе автоматически сдвигалить, ну и плюс там счетчики автоинкриментировались и прочее.
У оутофордеров нет такого режима, у них бранч - раз инструкция - два инструкция - сравнение каких-то операндов - хоп джамп в тот же бранч, процессор даже не знает что он в цикле работает, эльбрус делает так же в самых глухих случаях типа while (ptr1 != NULL) он не отличается (с точки зрения процессора) от обычной процедуры и вызовы из нее делаются хоть куда. У интела будет колл и мов константы у эльбруса подготовленный кол и add литерал с r0, хочешь показать пример на котором эльбрус обсирается так хоть у знающих людей спрашивай совета перед тем как что то объяснять на глупых примерах. В данном примере эльбрус скорее потому что его компилятор будет этот цикл оптимизировать, тогда как гцц на*уй выкинет вообще и вставит загрузку константы.
>Если в данном цикле вызов функции get_int_val по какой-то причине не заинлайнится компилятором, то для RISC/CISC архитектуры с OoO итерация цикла будет занимать ~1 такт, не отличаясь принципиально от случая, если инлайн сработал. В то же время на Эльбрусе одна итерация данного цикла будет занимать порядка 17 тактов.
Начнем с того что с высокой долей вероятности компилятор для интела (clang/gcc) подставит вместо этого цикла константу, не то что что-то синлайнит. Во вторых хотелось бы какие то замеры увидеть куда интел денет вызов? Я понимаю бранчь предиктор сгладит это всё но сам вызов и ожидание из функции никуда не денется, и цикл сам по себе не развернется, процессор будет делать все вызовы и переходы. На эльбрусе нет бранчпредиктора, но там просто вызовы и переходы тупо явно подготавливаются в доп.конвеер (коих три у него) и переключаются за один такт. Но это не значит что итерация будет занимать такт, такт занимало бы простое сложение чисел, но никак не с вызовом чего то.
![]()
![]()
r0 нельзя использовать в одной ШК сразу для трех операций, второй пример ассемблера демонстрирует так называемый конвейризованный цикл - аппаратную фичу эльбруса которая позволяет обращаться к массиву данных минуя кэш не используя обычные лоады/сторы а используя мувы из буфера подкачки.
Конечно без инлайна функции это не работает так как вызовы в конвейризованных циклах не допускаются и будет обычный цикл как на интеле с прыжком наверх - и чё? В чем недостаток, я не понял.
Как и не понял что там и где у тебя в коде нельзя проанализировать, где в чем тупик.
Понял только что ассемблер сложный-нипанятный а в документацию посмотреть хотя бы перед написанием статьи мы не умеем.
В общем статья уровня школьник для школьников пересказал какие то тезисы из интернета и приправил своей безграмотной отсебятиной.
Обычно под "64битный процессор" понимают размер указателей, все современные процессоры поддерживают адресацию через 32/64бит указатель эльбрус ещё умеет 128битные указатели, но сам размер адресуемых данных по такому указателю - 32бит там и команды загрузки по 32битному и 128и разрядному одинаковые используются.
Что касается регистров, то еще в mmx были 64битные регистры, в sse уже ввели 128и битные, а в avx 256 битные. А считается это так - либо ты 2 QP(128)/такт посчитаешь, либо 4 DP(64) либо 8 SP(32) за один такт. У эльбруса регистры 64 битные (на самом деле 80битные но не суть) в грядущих 8св/16с уже 128и битные. Но зато все 256, а не только какие то там специальные xmm0/ymm0/zmm0 как на интеле
Ну да там подумаешь циклик какой то ничтожный по пикселям/сжимаемым данным блоками ходит, архиватор/либа входные данные - вжик за полсекунды и где там энтот симд успел поработать пойди найди под микроскопом, кода то вон сколько.