Обычно под "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 а не продукт. Поэтому имеем что имеем.
По теме данного дистрибутива и его пакетов.
В описании написано что пакеты монолитные, то есть они собраны так что либы в бинарник входят или как? Пояснить почему так сделано (я примерно понимаю почему, но чтоб для всех), с какого размера либы не имеет смысла пихать в бинарник или при любом размере лучше монолит, или это от частоты обращения зависит (например в либе тяжелый вычислительный код и ее функции в разных тредах запускаются имеет ли смысл ее в один фаил включать?). И нет ли мыслей прикладное ПО отделить вообще от дистрибутива, если оно все с собой несет
Так как это пособие является практическим, описание совмещения блокировок компилятором и про-
становки маловероятных чтений в спекулятивный режим будет пропущено.
И как без описания понять что это такое? Про линейные участки и префетчь хоть понятно примерно, а вот что такое "совмещение блокировок" да еще каким то программным способом — непонятно.
И это еще быстрее. А VLIW сложил два числа и ждет соседний load.
Конвейризованные архитектуры так не работают, там команда за командой запускается каждый такт и никто никого не ждет, но если у тебя следующая команда оперирует теми же регистрами на которых ты в предыдущем такте сложение или лоад запустил, то она будет ждать пока регистры не будут готовы. Арифметика имеет фиксированное число стадий исполнения поэтому легко предугадывается в коде, и до нее можно еще пихнуть команд. Ну а нечего пихнуть можно выровнять нопами.
Другое дело лоад, при котором неизвестно где данные окажутся и первая же команда которая обращается к этому регистру, заблокирует конвеер на ожидании готовности. У оут-оф-ордера есть преимущество — он может отложить все операции которые зависят от лоада. Вот только тут тоже есть вопросы: у интела конвееры в 14 или даже больше стадий, когда данные загрузятся он опять все эти команды через все стадии прогонит получается. Не получится ли так что влив который постоял/покурил подождал подготовки регистров, засчет своей ширины и готовности конвеера по времени догонит то что интел наисполнял между задержками, пока он опять загоняет команды в конвеер, к тому же они все полностью или частично все равно зависимые.
Так что преимущество не очевидно так как ОоО тоже далек от идеала.
если Вы представили идеальный простой VLIW-процессор, то сравнивайте с идеальным простым обычным процессором
Я представил существующий в железе и работающий эльбрус, и можно его же представить в виде обычного риск процессора, просто выписав все инструкции из широких команд в линеечку — декодер будет такой же, просто во вливе он широкий параллельный а в риске маленький на одну инструкцию.
а как у эльбруса обрабатывается обращение к памяти, вызвавшее промах кэша? ЕМНИП, тормозится исполнение всего потока команд.
Никак, да, боль и унижение. Хотя вообще то мог бы на другом конвеере что то исполнять в таких случаях, у него их там несколько штук для подготовки колов/переходов.
процессор с SMT в таком случае может пока исполнять задания из параллельного потока.
Если у тебя две задачи запущены на одном ядре, то одно не заблокирует другое вот и все. Но так же оно у тебя и на физических ядрах не заблокируется, а больше ничего SMT и не дает, скорее как раз отнимает интерфейс памяти у одного потока, так бы он мог несколько загрузок сделать и что то уже посчитать пока тут на регистры загружается, а так у тебя другой поток каналы чтения записи в кэш забрал и отнять их теперь нельзя.
ИМХО правильнее делать суперскалярность на основе потока мелких команд с явно прописанными зависимостями, условно говоря, как в makefile
Еще один плюс VLIW на нем наглядней видно как все работает и гораздо быстрее все усваивать. Процессоры устроены немного сложней
Обычно под "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 а не продукт. Поэтому имеем что имеем.
хрюкни
Уныло, я думал на эльбрусе так гораздо быстрей, тогда создавать и поддерживать свой дистрибутив имело бы больше смысла.
А там кроcскомпилятор в дистре есть или опять не положили?
Перестать оправдываться перед всеми и начать жить. Не предложение а просто совет мимокрока.
По теме данного дистрибутива и его пакетов.
В описании написано что пакеты монолитные, то есть они собраны так что либы в бинарник входят или как? Пояснить почему так сделано (я примерно понимаю почему, но чтоб для всех), с какого размера либы не имеет смысла пихать в бинарник или при любом размере лучше монолит, или это от частоты обращения зависит (например в либе тяжелый вычислительный код и ее функции в разных тредах запускаются имеет ли смысл ее в один фаил включать?). И нет ли мыслей прикладное ПО отделить вообще от дистрибутива, если оно все с собой несет
И как без описания понять что это такое? Про линейные участки и префетчь хоть понятно примерно, а вот что такое "совмещение блокировок" да еще каким то программным способом — непонятно.
Конвейризованные архитектуры так не работают, там команда за командой запускается каждый такт и никто никого не ждет, но если у тебя следующая команда оперирует теми же регистрами на которых ты в предыдущем такте сложение или лоад запустил, то она будет ждать пока регистры не будут готовы. Арифметика имеет фиксированное число стадий исполнения поэтому легко предугадывается в коде, и до нее можно еще пихнуть команд. Ну а нечего пихнуть можно выровнять нопами.
Другое дело лоад, при котором неизвестно где данные окажутся и первая же команда которая обращается к этому регистру, заблокирует конвеер на ожидании готовности. У оут-оф-ордера есть преимущество — он может отложить все операции которые зависят от лоада. Вот только тут тоже есть вопросы: у интела конвееры в 14 или даже больше стадий, когда данные загрузятся он опять все эти команды через все стадии прогонит получается. Не получится ли так что влив который постоял/покурил подождал подготовки регистров, засчет своей ширины и готовности конвеера по времени догонит то что интел наисполнял между задержками, пока он опять загоняет команды в конвеер, к тому же они все полностью или частично все равно зависимые.
Так что преимущество не очевидно так как ОоО тоже далек от идеала.
Я представил существующий в железе и работающий эльбрус, и можно его же представить в виде обычного риск процессора, просто выписав все инструкции из широких команд в линеечку — декодер будет такой же, просто во вливе он широкий параллельный а в риске маленький на одну инструкцию.
Если у тебя две задачи запущены на одном ядре, то одно не заблокирует другое вот и все. Но так же оно у тебя и на физических ядрах не заблокируется, а больше ничего SMT и не дает, скорее как раз отнимает интерфейс памяти у одного потока, так бы он мог несколько загрузок сделать и что то уже посчитать пока тут на регистры загружается, а так у тебя другой поток каналы чтения записи в кэш забрал и отнять их теперь нельзя.
Еще один плюс VLIW на нем наглядней видно как все работает и гораздо быстрее все усваивать. Процессоры устроены немного сложней