Но у Байкала же энергопотребление в 3 раза ниже? Плюс Байкал-М это очень старое ядро ARM Cortex-A57 2012 года, и в принципе ничего не мешает взять более новые и быстрые ARM-ядра (особенно если поднять энергопотребление до сравнимых величин).
Как только они это сделают, сразу будем сравнивать.
Там десятикратное отставание в JavaScript например (и двухкратное от Байкала), пятикратное в Java и схожее в .Net. Это ли не проблемы все той же оптимизации и кто ей будет заниматься?
JIT'ы - это вообще отдельная песня, т.к. они не характеризуют производительность процессора, а характеризуют на сколько хорошо был портирован сам jit. Т.е. если хотим сравнивать производительность - добро пожаловать в нативные тесты. Если хотим сравнивать качество jit'ов, то давайте сравнивать их в отрыве от общей производительности.
Ну т.е. да, сейчас их производительность оставляет желать лучшего, но это скорее вопрос финансов и трудозатрат.
Как уже замечали в комментариях тот же Apple вышел и система совместимости с x86 у них тоже есть.
А мы в контексте имопртозамещения собрались ставить процессоры Apple? Кстати, тот факт что они это сделали не делает возможность бинарной трансляции менее уникальным явлением.
Для Эльбрусов цифры peak, для Байкалов 2006 - base, 2017 - peak (как они сами опубликовали, так и выложил). 20% относительно чего? У Вас есть аналогичный base замер?
2010 года, если быть точным. У того Итаниума было 2 процессора по 4 ядра, так что не совсем корректное сравнение, но действительно цифры близкие. Если вытянуть частоту, то по плавучке обгоним, а по интам - нет. Но тут я бы сказал что это у Итаниума очень хороший результат даже среди интелов :)
Не думаю что я могу сказать что-нибудь по данной ситуации кроме того что я уже сказал. Я считаю что конкуренция сама по себе - это хорошо, и нужно. А вот вставлять палки в колёса и менять правила под себя неконкурентными методами - плохо и неправильно.
И почему ваши коллеги когда топят против RISC-V приводят смешной аргумент что сообщество опенсорс может внезапно создать новую ветку и всё придётся переделывать?
Не очень понял мысль, но лучше спросите у тех коллег.
Запилите уже JIT? По идее, он и инлайнить что угодно может, и распределение команд по VLIW-ядрам сделает под нужный процессор.
Стандартные jit'ы (js, jvm, mono) уже есть довольно давно.
Если говорить про jit вместо нативного кода, то пилим. Но это действительно сложно, и непонятно, даст ли это выигрыш в общем случае.
Не похоже, что это так. Я всегда включал lto и всегда получал другой размер бинарника, чем до включения lto.
Там включается урезанная версия "thin lto". Когда Вы включаете руками, то там включается версия flat lto, которая работает с бОльшей областью видимости.
false: Performs "thin local LTO" which performs "thin" LTO on the local crate only across its codegen units. No LTO is performed if codegen units is 1 or opt-level is 0.
Для юр. лиц это можно очень давно, физ. лица как-то тоже умудряются (знаю о нескольких таких случаях, но без документации). Если говорить про импортозамещение, то основной клиент - это гос. корпорации, т.е. физические лица в данном случае не рассматриваются как клиенты. Нормальная b2b модель.
Документация никогда не была гос. тайной. Более того, относительно недавно было опубликовано руководство по платформе. Если компилятор в состоянии собрать ядро, то это уже очень высокая степень совместимости ;)
б) Есть примерно два места в статье. Первое - это в самом начале. Я долго сомневался и надеялся что это был просто несвоевременный крик души, но весь дальнейший диалог и развитие событий только убедили меня в обратном. Второе - это вопрос, касающийся измерения производительности. Вы отлично знаете почему синтетические тесты не показывают производительность даже близко, и почему индустрия использует SPEC (либо несколько других тестов, но они гораздо менее репрезентативны). Так что тут я Вас за язык не тянул, а раз решили идти на такие некорректные сравнения, извольте получить ответ.
Вырывать цитаты из контекста некрасиво. Моя фраза начиналась с перечисления других российских микропроцессорных архитектур и не говорила, что Эльбрус, чем-то плох.
На протяжении всего обсуждения вы сравнивали Эльбрусы (точнее VLIW) то с паровозом, который никто не производит, то с жигулями, предлагая вместо этого производить нормальные машины, то с натягиванием совы на глобус в контексте универсальности архитектуры. Так что нет, ничего из контекста не вырвано.
И нет, фраза про "агрессивный маркетинг" не имела контекста сравнения с другими разработками. Вы эту выдуманную Вами же и несоответствующую действительности идею выражали и раньше. У меня, как у человека, которому в своё время не дали 120 тыс. руб. в год (или в квартал, не помню) на корпоративный аккаунт хабра с формулировкой что это дорого, а смысла мало, эта выдумка ничего кроме удара ладонью о лицо не вызывает.
Но в вашей исключительно предвзятой картине мира только в МЦСТ работают достойные инженеры, а все остальные российские микроэлектронщики так, для мебели.
Ни в коем случае, даже напротив. Даже разработчиков Байкала, которых я немного потыкал, я очень уважаю. В контексте импортозамещения процессоров общего назначения я бы с радостью рассказал о любой из перечисленных Вами фирм если бы кто-либо мог (и стремился) составить конкуренцию в этом направлении. Возможно у Вас есть какие-то более свежие данные по результатам SPEC CPU от упомянутых разработчиков, я с радостью добавлю их в статью.
У e2k код «рыхлый» потому что для оптимизации необходимо делать много подстановок функций, а также иметь много версий одного цикла и много вариаций кода для предикатного режима (if-conversion). Тем не менее, обычно в горячих участках код получается нормальным, а «рыхлость» — это среднее по больнице.
Более того, раскрутка — далеко не единственный метод оптимизации цикла, если это возможно, то к нему будет применена программная конвейеризация, которая обладает аппаратной поддержкой. Это, разумеется, не взаимоисключающая с раскруткой оптимизация, и их часто следует применять вместе, но размер кода она экономит сильно по сравнению с только раскруткой.
Компилятор довольно сильно заботится о размере кода. Так, например в режиме -O3 действует специальная система СНОП, которая при возможности понижает линейку оптимизации для экономии времени компиляции и размера. Но сам по себе -O3 подразумевает что размер кода не является главной целью сборки.
Из моего опыта собесов, там сразу рассказывают про собственный компилятор. То что у Эльбрусов компилятор собственный чуть ли не из каждого утюга слышно всем кто темой интересуется. Вы интересоваться не обязаны, но тогда и заявлений таких делать не стоит.
Юридические вопросы решаются в установленном порядке. Если хотите моё личное мнение - мы в серой зоне, и надеюсь рано или поздно из неё выйдем.
Как только они это сделают, сразу будем сравнивать.
JIT'ы - это вообще отдельная песня, т.к. они не характеризуют производительность процессора, а характеризуют на сколько хорошо был портирован сам jit. Т.е. если хотим сравнивать производительность - добро пожаловать в нативные тесты. Если хотим сравнивать качество jit'ов, то давайте сравнивать их в отрыве от общей производительности.
Ну т.е. да, сейчас их производительность оставляет желать лучшего, но это скорее вопрос финансов и трудозатрат.
А мы в контексте имопртозамещения собрались ставить процессоры Apple? Кстати, тот факт что они это сделали не делает возможность бинарной трансляции менее уникальным явлением.
Об этом.
Для Эльбрусов цифры peak, для Байкалов 2006 - base, 2017 - peak (как они сами опубликовали, так и выложил). 20% относительно чего? У Вас есть аналогичный base замер?
2010 года, если быть точным. У того Итаниума было 2 процессора по 4 ядра, так что не совсем корректное сравнение, но действительно цифры близкие. Если вытянуть частоту, то по плавучке обгоним, а по интам - нет. Но тут я бы сказал что это у Итаниума очень хороший результат даже среди интелов :)
Не думаю что я могу сказать что-нибудь по данной ситуации кроме того что я уже сказал. Я считаю что конкуренция сама по себе - это хорошо, и нужно. А вот вставлять палки в колёса и менять правила под себя неконкурентными методами - плохо и неправильно.
Не очень понял мысль, но лучше спросите у тех коллег.
Стандартные jit'ы (js, jvm, mono) уже есть довольно давно.
Если говорить про jit вместо нативного кода, то пилим. Но это действительно сложно, и непонятно, даст ли это выигрыш в общем случае.
Там включается урезанная версия "thin lto". Когда Вы включаете руками, то там включается версия flat lto, которая работает с бОльшей областью видимости.
Там написано что включён урезанный вариант lto:
lto = falsefalse: Performs "thin local LTO" which performs "thin" LTO on the local crate only across its codegen units. No LTO is performed if codegen units is 1 or opt-level is 0.Не беспокойтесь, о том чтобы заставить лично Вас купить что-либо речи никогда не шло. Ни среди разработчиков, ни на министерском уровне!
Для юр. лиц это можно очень давно, физ. лица как-то тоже умудряются (знаю о нескольких таких случаях, но без документации). Если говорить про импортозамещение, то основной клиент - это гос. корпорации, т.е. физические лица в данном случае не рассматриваются как клиенты. Нормальная b2b модель.
Документация никогда не была гос. тайной. Более того, относительно недавно было опубликовано руководство по платформе. Если компилятор в состоянии собрать ядро, то это уже очень высокая степень совместимости ;)
Согласен с Вами, надеюсь что компания поймёт почему так.
Полностью разделяю Ваше возмущение, и рад что удалось их опубликовать, пусть даже и под таким соусом.
Максим, всегда пожалуйста!
а) С удовольствием послушаю
б) Есть примерно два места в статье. Первое - это в самом начале. Я долго сомневался и надеялся что это был просто несвоевременный крик души, но весь дальнейший диалог и развитие событий только убедили меня в обратном. Второе - это вопрос, касающийся измерения производительности. Вы отлично знаете почему синтетические тесты не показывают производительность даже близко, и почему индустрия использует SPEC (либо несколько других тестов, но они гораздо менее репрезентативны). Так что тут я Вас за язык не тянул, а раз решили идти на такие некорректные сравнения, извольте получить ответ.
На протяжении всего обсуждения вы сравнивали Эльбрусы (точнее VLIW) то с паровозом, который никто не производит, то с жигулями, предлагая вместо этого производить нормальные машины, то с натягиванием совы на глобус в контексте универсальности архитектуры. Так что нет, ничего из контекста не вырвано.
И нет, фраза про "агрессивный маркетинг" не имела контекста сравнения с другими разработками. Вы эту выдуманную Вами же и несоответствующую действительности идею выражали и раньше. У меня, как у человека, которому в своё время не дали 120 тыс. руб. в год (или в квартал, не помню) на корпоративный аккаунт хабра с формулировкой что это дорого, а смысла мало, эта выдумка ничего кроме удара ладонью о лицо не вызывает.
Ни в коем случае, даже напротив. Даже разработчиков Байкала, которых я немного потыкал, я очень уважаю. В контексте импортозамещения процессоров общего назначения я бы с радостью рассказал о любой из перечисленных Вами фирм если бы кто-либо мог (и стремился) составить конкуренцию в этом направлении. Возможно у Вас есть какие-то более свежие данные по результатам SPEC CPU от упомянутых разработчиков, я с радостью добавлю их в статью.
Более того, раскрутка — далеко не единственный метод оптимизации цикла, если это возможно, то к нему будет применена программная конвейеризация, которая обладает аппаратной поддержкой. Это, разумеется, не взаимоисключающая с раскруткой оптимизация, и их часто следует применять вместе, но размер кода она экономит сильно по сравнению с только раскруткой.
Компилятор довольно сильно заботится о размере кода. Так, например в режиме -O3 действует специальная система СНОП, которая при возможности понижает линейку оптимизации для экономии времени компиляции и размера. Но сам по себе -O3 подразумевает что размер кода не является главной целью сборки.
Я уж не знаю были ли Вы действительно на собеседовании, но учитывая первое высказывание у меня есть некоторые сомнения.