А под светлым знаменем 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 как на интеле
Ну да там подумаешь циклик какой то ничтожный по пикселям/сжимаемым данным блоками ходит, архиватор/либа входные данные - вжик за полсекунды и где там энтот симд успел поработать пойди найди под микроскопом, кода то вон сколько.
Здесь уже давно уровень дискуссий как на дваче каком нибудь.
>грубо говоря, 20% TDP, но при этом ускоряет работу программы в 2 раза
Так он каждый долбаный раз на ускорение этой программы 20% тратит, на перестановку того самого лоада наверх, что спокойно компилятором выявляется как ты сам же и написал, и компилятору можно запретить использовать спекулятивность, там даже специальная опция есть (-fwno-spec или как то так) которую они рекомендуют врубать для отладки. Будет немного медленней, зато без спекулятивных делений на ноль и загрузок по нульпоинтеру. А можно ли интелу вот так вот его аппаратную отрубить? Врядли, и быстродействие на интеле давно уже не засчет каких то там аппаратных ОоО, а засчет хорошей поддержки в ПО, укладывания алгоритмов в simd -ы которые сам процессор в рантайме задействовать не умеет, а умеет подставлять только компилятор, и совместимость с процессорами которые не имеют данных расширений тоже ломается, в общем все как у vliw. А на чистом OoO без SIMD один фильм в av1 будет 10лет будет кодироваться. Так что с быстродействием вопрос давно закрытый на самом деле, нет другого пути кроме программного распараллеливания на уровне комманд и потоков, суперскаляр физически не может взять и векторизовать какой то код, и ibm cell который там аппаратно пытался на потоки распараллеливать обкакался и сдох.
И если как раз сравнивать avx/sse4+ с эльбрусами то у эльбруса максимум 2фма над даблами в такт, и при том длятся они там как если просто сложить а затем умножить, поэтому он и сосет в тестах.
Ну и до кучи у интела восемь портов, 170 регистров , в конвейере стадий 20 а то и больше, но это все надо посмотреть померить как это влияет, а вот в эльбрусе не надо мерить, там полюбому ток жрет что на простоях (читай на пустом коде) что под нагрузкой, разницы нет, ага.
Тебе про энергоэффективность говорят, а ты все одно про спекулятивность и наполненность комманд/производительность на такт - ты зомби или аутист?
Интел буквально каждый раз один и тот же код анализирует в рантайме. Тысячу раз одну и ту же функцию будет анализировать и переупорядочивать в ней инструкции абсолютно одинаковым образом, с каждого запуска потеряный (образно) микроват энергии, а за сутки работы уже сотни ватт истраченных на повторяющиеся действия которые можно было сделать один раз при компиляции. И если на десктопах это ещё не так критично, то на серверах где одно приложение годами крутится да ещё под постоянной нагрузкой это будет очень ощутимо.
Эльбрус ничего не анализирует в рантайме, он просто тупо исполняет инструкцию за инструкцией, а система команд и фишки в процессоре позволяют переупорядочивать инструкции один раз в компаил тайме. Набитые они операциями под потолок или пустые, с точки зрения энергоэффективности абсолютно побарабану, пустые инструкции не нагружают все алу вычислениями, как и кстати условные инструкции они не исполняются по факту, значит ничего не жрут, единственное только спекулятивные команды и подготовка переходов могут делать лишнюю работу если у нас условие для них выполняется в 1:1000, но это уже особенность скомпилированной программы а не особенность работы процессора, чинится собиранием профиля программы и перекомпиляции с ним.
Разработчики все никак не могут понять, что VLIW не подходит для процессоров общего назначения
Нет чтоб послушать экспертов из интернета и просто взять и зделоть Ryzen X Black Edition от которого любой код будет ссаться AVXами сам по себе, без программистов.
О, кастомный дизайн - лженаучный миф капитализма 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 как на интеле
Ну да там подумаешь циклик какой то ничтожный по пикселям/сжимаемым данным блоками ходит, архиватор/либа входные данные - вжик за полсекунды и где там энтот симд успел поработать пойди найди под микроскопом, кода то вон сколько.
Здесь уже давно уровень дискуссий как на дваче каком нибудь.
>грубо говоря, 20% TDP, но при этом ускоряет работу программы в 2 раза
Так он каждый долбаный раз на ускорение этой программы 20% тратит, на перестановку того самого лоада наверх, что спокойно компилятором выявляется как ты сам же и написал, и компилятору можно запретить использовать спекулятивность, там даже специальная опция есть (-fwno-spec или как то так) которую они рекомендуют врубать для отладки. Будет немного медленней, зато без спекулятивных делений на ноль и загрузок по нульпоинтеру. А можно ли интелу вот так вот его аппаратную отрубить? Врядли, и быстродействие на интеле давно уже не засчет каких то там аппаратных ОоО, а засчет хорошей поддержки в ПО, укладывания алгоритмов в simd -ы которые сам процессор в рантайме задействовать не умеет, а умеет подставлять только компилятор, и совместимость с процессорами которые не имеют данных расширений тоже ломается, в общем все как у vliw. А на чистом OoO без SIMD один фильм в av1 будет 10лет будет кодироваться. Так что с быстродействием вопрос давно закрытый на самом деле, нет другого пути кроме программного распараллеливания на уровне комманд и потоков, суперскаляр физически не может взять и векторизовать какой то код, и ibm cell который там аппаратно пытался на потоки распараллеливать обкакался и сдох.
И если как раз сравнивать avx/sse4+ с эльбрусами то у эльбруса максимум 2фма над даблами в такт, и при том длятся они там как если просто сложить а затем умножить, поэтому он и сосет в тестах.
Ну и до кучи у интела восемь портов, 170 регистров , в конвейере стадий 20 а то и больше, но это все надо посмотреть померить как это влияет, а вот в эльбрусе не надо мерить, там полюбому ток жрет что на простоях (читай на пустом коде) что под нагрузкой, разницы нет, ага.
Тебе про энергоэффективность говорят, а ты все одно про спекулятивность и наполненность комманд/производительность на такт - ты зомби или аутист?
Интел буквально каждый раз один и тот же код анализирует в рантайме. Тысячу раз одну и ту же функцию будет анализировать и переупорядочивать в ней инструкции абсолютно одинаковым образом, с каждого запуска потеряный (образно) микроват энергии, а за сутки работы уже сотни ватт истраченных на повторяющиеся действия которые можно было сделать один раз при компиляции. И если на десктопах это ещё не так критично, то на серверах где одно приложение годами крутится да ещё под постоянной нагрузкой это будет очень ощутимо.
Эльбрус ничего не анализирует в рантайме, он просто тупо исполняет инструкцию за инструкцией, а система команд и фишки в процессоре позволяют переупорядочивать инструкции один раз в компаил тайме. Набитые они операциями под потолок или пустые, с точки зрения энергоэффективности абсолютно побарабану, пустые инструкции не нагружают все алу вычислениями, как и кстати условные инструкции они не исполняются по факту, значит ничего не жрут, единственное только спекулятивные команды и подготовка переходов могут делать лишнюю работу если у нас условие для них выполняется в 1:1000, но это уже особенность скомпилированной программы а не особенность работы процессора, чинится собиранием профиля программы и перекомпиляции с ним.
Нет чтоб послушать экспертов из интернета и просто взять и зделоть Ryzen X Black Edition от которого любой код будет ссаться AVXами сам по себе, без программистов.
clang и rust у них не через llvm реализованы, а путем добавления в LCC поддержки llvm-овских фронтендов.
Судя по рыхлому ассемблерному выхлопу у вас -O0, вы хоть релиз то с -O3 компилируете?
А то потом тесты выложите где он половину тактов тупо стоит.