Я с ваами сам отупел уже, думаю про волшебную коробочку где чик брик все за один такт исполняется и напрочь забыл про конвейер.
Прыжки на начало цикла без подготовок работают только в 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ами сам по себе, без программистов.
Койси — это персонаж из Touhou Project.
Среди сотрудников мцст кто-то увлекался тохой, он(и) и портировал(и) свободный вариант этой игры — teisei-project с входящей в него данной библиотекой.
Из за того что процессор и дистрибутив "Эльбрус Линукс" созданы на деньги госзаказчика, они не могут просто так передавать кому либо даже исходный код открытых программ.
Например патчи на rust они выложили в публичный репозиторий https://storage.mcst.ru/pub/src/rust/
очевидно потому что его они портировали в инициативном порядке. Так что с выкладыванием у них нет проблем, проблема чисто бюрократическая.
Думаю вся проблема в руководстве МЦСТ которое мыслит очень старыми и очень советскими категориями, примерно такими же как мыслило руководство УВЗ до посещения его путиным в нулевые. Т.е. вот рынки, продукты, сообщество, экосистема это все какие то буржуйские вещи, стране нужен процессор чтоб ковать свой железный ядерный микроэлектронный щит и диктовать свою непреклонную волю всему мировому сообществу.
Шокирован твоим постом. Цель вакцинации не привить всех "авось кто выживет, абы не от болезни", цель в том что бы у самой активной части населения которая постоянно ездит и с кем то встречается, был стойкий продолжительный уммунитет, что бы они не заражались при контакте с короновирусом и не распространяли болезнь дальше. А не изготовить всем по таблетке спасения и побольше их продать.
Ну да, это другое, понимать надо. Сейчас проведут экспертизу и во всем разберутся.
И вообще люди просто старые были и несовместимые по интерфейсам с ультрасовременной суперпрогрессивной вакциной 21го века. Их давно пора было заменить на новых, в общем сами виноваты.
Я не о том, в нынешнем виде эльбрус это не рыночный продукт, а "спецзаказ. изделие" и вечная институтская разработка. Даже бессмысленно говорить о каких то перспективах что то занять на рынке. Тем не менее ARM сегодня занимает ниши от Cortex-M0/3 контроллеров до A57 в телефонах, ноутбуки/серверы арм пытается штурмовать, но пока не особо видно каких то перспектив по причине отсутствия стандартизированного железа и необходимых фичь.
Речь о том что в эльбрусе слишком жирное ядро с кучей алу и устройств, и там чисто архитектурно нельзя вырезать лишнее что бы получился контроллер или маломощный встраиваемый процессор типа arm11. Технически то наверное это можно сделать но под него сразу надо будет не только код перекомпилировать но и менять оптимизации в компиляторе. Когда эту архитектуру в 90х задумывали даже АРМ еще не знал что он будет архитектурой для мобилок, его создавали так же для компьютеров. Но время шло, рынок изменился а эльбрус не особо. Так что чисто концептуально он заточен на большие компьютеры, на которых сегодня доминируют интел/амд.
Ту нишу которую занял арм, эльбрус с текущей его архитектурой занять неспособен.
Его ниша это серваки, пекарни, схд и все что занимает сегодня интел/амд.
Вообще в 2007/8м 4С был бы очень неплохой процессор и нашел бы своего потребителя, в 18/19м надо было уже выкатывать 16C. Но мцст работает на госконтракты им выгоднее делать процессоры для полок Э-S, Э-2C+, Э-1C+, Э-8CB а не продукт. Поэтому имеем что имеем.
Я с ваами сам отупел уже, думаю про волшебную коробочку где чик брик все за один такт исполняется и напрочь забыл про конвейер.
Прыжки на начало цикла без подготовок работают только в 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 компилируете?
А то потом тесты выложите где он половину тактов тупо стоит.
Койси — это персонаж из Touhou Project.
Среди сотрудников мцст кто-то увлекался тохой, он(и) и портировал(и) свободный вариант этой игры — teisei-project с входящей в него данной библиотекой.
Из за того что процессор и дистрибутив "Эльбрус Линукс" созданы на деньги госзаказчика, они не могут просто так передавать кому либо даже исходный код открытых программ.
Например патчи на rust они выложили в публичный репозиторий https://storage.mcst.ru/pub/src/rust/
очевидно потому что его они портировали в инициативном порядке. Так что с выкладыванием у них нет проблем, проблема чисто бюрократическая.
Думаю вся проблема в руководстве МЦСТ которое мыслит очень старыми и очень советскими категориями, примерно такими же как мыслило руководство УВЗ до посещения его путиным в нулевые. Т.е. вот рынки, продукты, сообщество, экосистема это все какие то буржуйские вещи, стране нужен процессор чтоб ковать свой железный ядерный микроэлектронный щит и диктовать свою непреклонную волю всему мировому сообществу.
Шокирован твоим постом. Цель вакцинации не привить всех "авось кто выживет, абы не от болезни", цель в том что бы у самой активной части населения которая постоянно ездит и с кем то встречается, был стойкий продолжительный уммунитет, что бы они не заражались при контакте с короновирусом и не распространяли болезнь дальше. А не изготовить всем по таблетке спасения и побольше их продать.
Ну да, это другое, понимать надо. Сейчас проведут экспертизу и во всем разберутся.
И вообще люди просто старые были и несовместимые по интерфейсам с ультрасовременной суперпрогрессивной вакциной 21го века. Их давно пора было заменить на новых, в общем сами виноваты.
Я не о том, в нынешнем виде эльбрус это не рыночный продукт, а "спецзаказ. изделие" и вечная институтская разработка. Даже бессмысленно говорить о каких то перспективах что то занять на рынке. Тем не менее ARM сегодня занимает ниши от Cortex-M0/3 контроллеров до A57 в телефонах, ноутбуки/серверы арм пытается штурмовать, но пока не особо видно каких то перспектив по причине отсутствия стандартизированного железа и необходимых фичь.
Речь о том что в эльбрусе слишком жирное ядро с кучей алу и устройств, и там чисто архитектурно нельзя вырезать лишнее что бы получился контроллер или маломощный встраиваемый процессор типа arm11. Технически то наверное это можно сделать но под него сразу надо будет не только код перекомпилировать но и менять оптимизации в компиляторе. Когда эту архитектуру в 90х задумывали даже АРМ еще не знал что он будет архитектурой для мобилок, его создавали так же для компьютеров. Но время шло, рынок изменился а эльбрус не особо. Так что чисто концептуально он заточен на большие компьютеры, на которых сегодня доминируют интел/амд.
Ту нишу которую занял арм, эльбрус с текущей его архитектурой занять неспособен.
Его ниша это серваки, пекарни, схд и все что занимает сегодня интел/амд.
Вообще в 2007/8м 4С был бы очень неплохой процессор и нашел бы своего потребителя, в 18/19м надо было уже выкатывать 16C. Но мцст работает на госконтракты им выгоднее делать процессоры для полок Э-S, Э-2C+, Э-1C+, Э-8CB а не продукт. Поэтому имеем что имеем.
хрюкни