Собственно, вы абсолютно правы. В теории, JIT для Эльбруса более перспективен. На практике написать высокопроизводительный JIT для каждого из интерпретируемых языков - это колоссальная работа, вряд ли осуществимая на практике.
Наверное, ARM было бы оптимальным решением. Но там легко могут организовать проблемы с лицензией. Поэтому, в плане открытости и независимости, на данный момент наиболее перспективным выглядит RISC-V. Но с другой стороны, это ещё очень сырая архитектура.
Во-первых постоянные кивания "на заказчика" и рассказы про "обеими руками за"- это, скажем так, не совсем правда.
Во-вторых, суть статьи как раз в том, что это технически неверное направление. Проблемы продвижение, маркетинга, создания экосистеммы и т.д. и т.п. - это вопросы для отдельного, очень большого разговора.
В Эльбрусе с этим ещё хуже. В типовых архитектурах, если бранч предиктор более менее хорошо работает, то дополнительная нагрузка на кэш минимальна. В Эльбрусе же там просто всегда надо исполнять код по обеим веткам по сути (если линейный участок попал под предикат)
В Эльбрусе нет предсказателя переходов (хотя есть статьи, где это пробовали делать).
Но в целом вы правы. Там множество мелких и не очень проблем возникает, просто я не хотел совсем уж в технику уходить, т.к. это заняло бы уйму времени на написание статьи, а технически восприняло бы всё это пара десятков человек.
Как бы я об этом и написал как раз - большинство программистов в ассемблер не лазят. А без этого вы на Эльбрусе перформанса не получите. Что и является большим недостатком. Этому приличная часть статьи посвящена
Здесь нет обсуждения вопроса, как правильно вести бизнес. Только техническая сторона вопроса. Критерий перспективности является то, в каких нишах Эльбрус технически может быть конкурентен. Собственно я показал, что и по абсолютной производительности, и по энергоэффективности процессоры на базе VLIW проигрывают архитектурам RISC/CISC.
Там набор факторов. С одной стороны МЦСТ это де факто - советское НИИ. Т.е. есть объективные проблемы с пониманием того, как работать в нынешних условиях, и желанием работать над продвижением своих продуктов. ОКРы сдаются - и хорошо.
С другой стороны есть понимание, что Эльбрус принципиально проигрывает. Отсюда дополнительный набор действий по наведению тумана.
Идеальный вариант - это вложить силы в разработку нормального RISC/CISC процессора. Теоретически, это могут сами же МЦСТ и сделать. И не мучать несчастных пользователей и не вкладывать деньги туда, куда заведомо понятно что не надо.
Скажем так, на некоторых серверных задачах недостатки Эльбруса становятся минимальными, но при этом всё равно он будет проигрывать топовым RISC/CISC'ам. В HPC, где мы молотим много плавучки и паттерны доступа к памяти несложные - Эльбрус может показывать близкие к максимумам цифры. Но HPC - это лишь часть серверного рынка, причём довольно специфическая, там вообще на GPU переходят часто. А если ваши сервера хостят сайтики - там перформанс Эльбруса будет стремиться ко дну.
У Эльбруса 6 fma в такт. В остальном вы смешали тёплое с мягким и зачем-то приплели сюда SIMD, использование которого имеет одинаковые проблемы что у x86, что у Эльбруса, но к обсуждаемому вопросу это не имеет никакого отношения. Большинство кода, работающего на реальных системах, Simd использует в гомеопатических дозах, практически не влияющих на перф.
Во-первых, будь я хоть земляным червяком или Хищником, от этого технические аргументы не изменятся и проблемы Эльбруса никуда не уйдут. Во-вторых, в профессиональной технической дискуссии перейти на личности в первом же предложении - это расписаться в собственной некомпетентности в вопросе. Учтите на будущее.
Что касается Ваших тезисов. Они страдают некоторой оторванностью от практики, давайте попробую объяснить чуть подробнее. В утверждении "Интел буквально каждый раз один и тот же код анализирует в рантайме" нет никаких цифр, сколько это стоит в реальности. Потому что если OoO движок в сумме добавляет грубо говоря, 20% TDP, но при этом ускоряет работу программы в 2 раза - значит он улучшает энергоэффективность. Оценка реальной стоимости OoO крайне сложна, но мы можем просто посмотреть на практике, что Эльбрусы на схожих нанометрах имеют худшие показатели и перфа, и даже TDP, что в итоге даёт крайне плохие показатели по энергоэффективности. Собственно говоря, мне понятно почему и я пытаюсь уже детально технически объяснить, в чём причина.
Дальше, ваше заблуждение в том, что если ALU не работает, то пауэр не потребляется. В реальности, непосредственная работа ALU потребляет мало энергии, на уровне единиц процентов (если не брать сложные команды вроде sqrt и т.д.). А вот если вы не можете заполнить ШК, то все цепи в процессоре работают вхолостую. Это как на машинe с оптимальным режимом 100 км/ч гонять на первой скорости в 10км/ч по пробкам - расход топлива резко увеличивается. Для VLIW незаполненность ШК критически влияет на энергоэффективность.
Что касается предикатного кода - тут у вас недостаточно понимания нюансов работы Эльбруса. Представьте у вас есть if-узел, где по одной альтернативе просто обход, а по второй маленький линейный участок, где просто делается инкремент значения в памяти - абсолютно типичный и крайне распространённый паттерн. Проблема в таком коде в том, что вам надо ставить код маленького ЛУ под предикат и сливать с if-узлом (иначе он будет исполняться минимум 5 тактов), но выработка предиката занимает 2-3 такта, и если в if-узле мало кода (а так чаще всего и бывает), то вам придётся ждать выработки его значения и в итоге сильно ухудшать производительность. Поэтому компилятору Эльбруса не остаётся ничего другого, как снимать предикат с Load'a и ADD'a (чтобы спланировать их как можно выше) и оставлять под предикатом только STORE в память, выигрывая таким образом 4 такта. Но при таком преобразовании вы начинает исполнять LOAD и ADD ВСЕГДА, даже если в реальности вероятность перехода на маленький ЛУ близка к нулю.
Собственно, куча такого рода проблем и нюансов приводит к тому, что в реальности количество микроархитектрных операций, исполненных на Эльбрусе будет существенно ВЫШЕ, чем на том же x86. И это также отрицательно влияет на энергоэффективность, хотя не уверен, что это главная проблема. Скорее всего главная проблема именно в сложности регистрового файла и куче разных фич, которые нужны, чтобы добиться приемлемой производительности . По сути в Эльбрусе реализовано куча ОоО фич, которые просто менеджатся программно, а не аппаратно. А всё это жрёт энергию.
Я бы сказал, что в данный момент скорее всего в режиме бинарки хороший оптимизированный JIT под x86 будет работать лучше на Эльбрусе, чем быстрый нативный порт на e2k. Правда там могут быть определённые "но", но это уже надо каждый случай отдельно обсуждать. Но в целом моя мысль в том, что в теории JIT более перспективны для Эльбруса, но на практике это малореалезуемо скорее всего. Создание нормального RISC с ОоО проще, прямее, дешевле, удобнее и экнономит кучу времени для программистов.
JIT'ы имеют возможность собрать динамическую информацию об исполняемом коде и соптимизировать его исходя из этого. Т.е. в таком режиме они немного закрывают тот гап, который VLIW процессоры имеют по сравнению с RISC/CISC с OoO.
Проблема в том, что создать такой JIT для VLIW - задача очень серьёзная. У того же МЦСТ просто нет ресурсов на такое. Поэтому в итоге JIT'ы для того же Эльбруса в реальности неоптимизированы и работают крайне плохо (кроме бинарки x86->e2k в которую было вложено много ресурсов)
Бэкенд llvm вряд ли сможет хорошо соптимизировать код под Эльбрус.
Собственно, вы абсолютно правы. В теории, JIT для Эльбруса более перспективен. На практике написать высокопроизводительный JIT для каждого из интерпретируемых языков - это колоссальная работа, вряд ли осуществимая на практике.
Наверное, ARM было бы оптимальным решением. Но там легко могут организовать проблемы с лицензией. Поэтому, в плане открытости и независимости, на данный момент наиболее перспективным выглядит RISC-V. Но с другой стороны, это ещё очень сырая архитектура.
За державу обидно.
Тут 2 момента.
Во-первых постоянные кивания "на заказчика" и рассказы про "обеими руками за"- это, скажем так, не совсем правда.
Во-вторых, суть статьи как раз в том, что это технически неверное направление. Проблемы продвижение, маркетинга, создания экосистеммы и т.д. и т.п. - это вопросы для отдельного, очень большого разговора.
Мультиклет это не general-purpose CPU. Т.е. совсем другая история, не связанная с обсуждаемым топиком.
Изначально всё было нацелено на широкий рынок. Была знаменитая статья в 99-ом в Microprocessor Report про Эльбрус. А получилось так, как получилось
За всё надо платить и нет никаких гарантий, что в том же Эльбрусе нет своих аппаратных уязвимостей, которые просто ещё не нашли.
В Эльбрусе с этим ещё хуже. В типовых архитектурах, если бранч предиктор более менее хорошо работает, то дополнительная нагрузка на кэш минимальна. В Эльбрусе же там просто всегда надо исполнять код по обеим веткам по сути (если линейный участок попал под предикат)
В Эльбрусе нет предсказателя переходов (хотя есть статьи, где это пробовали делать).
Но в целом вы правы. Там множество мелких и не очень проблем возникает, просто я не хотел совсем уж в технику уходить, т.к. это заняло бы уйму времени на написание статьи, а технически восприняло бы всё это пара десятков человек.
Как бы я об этом и написал как раз - большинство программистов в ассемблер не лазят. А без этого вы на Эльбрусе перформанса не получите. Что и является большим недостатком. Этому приличная часть статьи посвящена
Здесь нет обсуждения вопроса, как правильно вести бизнес. Только техническая сторона вопроса. Критерий перспективности является то, в каких нишах Эльбрус технически может быть конкурентен. Собственно я показал, что и по абсолютной производительности, и по энергоэффективности процессоры на базе VLIW проигрывают архитектурам RISC/CISC.
Там набор факторов. С одной стороны МЦСТ это де факто - советское НИИ. Т.е. есть объективные проблемы с пониманием того, как работать в нынешних условиях, и желанием работать над продвижением своих продуктов. ОКРы сдаются - и хорошо.
С другой стороны есть понимание, что Эльбрус принципиально проигрывает. Отсюда дополнительный набор действий по наведению тумана.
Идеальный вариант - это вложить силы в разработку нормального RISC/CISC процессора. Теоретически, это могут сами же МЦСТ и сделать. И не мучать несчастных пользователей и не вкладывать деньги туда, куда заведомо понятно что не надо.
Если кратко, то это утопия
Скажем так, на некоторых серверных задачах недостатки Эльбруса становятся минимальными, но при этом всё равно он будет проигрывать топовым RISC/CISC'ам. В HPC, где мы молотим много плавучки и паттерны доступа к памяти несложные - Эльбрус может показывать близкие к максимумам цифры. Но HPC - это лишь часть серверного рынка, причём довольно специфическая, там вообще на GPU переходят часто. А если ваши сервера хостят сайтики - там перформанс Эльбруса будет стремиться ко дну.
У Эльбруса 6 fma в такт. В остальном вы смешали тёплое с мягким и зачем-то приплели сюда SIMD, использование которого имеет одинаковые проблемы что у x86, что у Эльбруса, но к обсуждаемому вопросу это не имеет никакого отношения. Большинство кода, работающего на реальных системах, Simd использует в гомеопатических дозах, практически не влияющих на перф.
Уважаемый коллега,
Во-первых, будь я хоть земляным червяком или Хищником, от этого технические аргументы не изменятся и проблемы Эльбруса никуда не уйдут. Во-вторых, в профессиональной технической дискуссии перейти на личности в первом же предложении - это расписаться в собственной некомпетентности в вопросе. Учтите на будущее.
Что касается Ваших тезисов. Они страдают некоторой оторванностью от практики, давайте попробую объяснить чуть подробнее. В утверждении "Интел буквально каждый раз один и тот же код анализирует в рантайме" нет никаких цифр, сколько это стоит в реальности. Потому что если OoO движок в сумме добавляет грубо говоря, 20% TDP, но при этом ускоряет работу программы в 2 раза - значит он улучшает энергоэффективность. Оценка реальной стоимости OoO крайне сложна, но мы можем просто посмотреть на практике, что Эльбрусы на схожих нанометрах имеют худшие показатели и перфа, и даже TDP, что в итоге даёт крайне плохие показатели по энергоэффективности. Собственно говоря, мне понятно почему и я пытаюсь уже детально технически объяснить, в чём причина.
Дальше, ваше заблуждение в том, что если ALU не работает, то пауэр не потребляется. В реальности, непосредственная работа ALU потребляет мало энергии, на уровне единиц процентов (если не брать сложные команды вроде sqrt и т.д.). А вот если вы не можете заполнить ШК, то все цепи в процессоре работают вхолостую. Это как на машинe с оптимальным режимом 100 км/ч гонять на первой скорости в 10км/ч по пробкам - расход топлива резко увеличивается. Для VLIW незаполненность ШК критически влияет на энергоэффективность.
Что касается предикатного кода - тут у вас недостаточно понимания нюансов работы Эльбруса. Представьте у вас есть if-узел, где по одной альтернативе просто обход, а по второй маленький линейный участок, где просто делается инкремент значения в памяти - абсолютно типичный и крайне распространённый паттерн. Проблема в таком коде в том, что вам надо ставить код маленького ЛУ под предикат и сливать с if-узлом (иначе он будет исполняться минимум 5 тактов), но выработка предиката занимает 2-3 такта, и если в if-узле мало кода (а так чаще всего и бывает), то вам придётся ждать выработки его значения и в итоге сильно ухудшать производительность. Поэтому компилятору Эльбруса не остаётся ничего другого, как снимать предикат с Load'a и ADD'a (чтобы спланировать их как можно выше) и оставлять под предикатом только STORE в память, выигрывая таким образом 4 такта. Но при таком преобразовании вы начинает исполнять LOAD и ADD ВСЕГДА, даже если в реальности вероятность перехода на маленький ЛУ близка к нулю.
Собственно, куча такого рода проблем и нюансов приводит к тому, что в реальности количество микроархитектрных операций, исполненных на Эльбрусе будет существенно ВЫШЕ, чем на том же x86. И это также отрицательно влияет на энергоэффективность, хотя не уверен, что это главная проблема. Скорее всего главная проблема именно в сложности регистрового файла и куче разных фич, которые нужны, чтобы добиться приемлемой производительности . По сути в Эльбрусе реализовано куча ОоО фич, которые просто менеджатся программно, а не аппаратно. А всё это жрёт энергию.
Я бы сказал, что в данный момент скорее всего в режиме бинарки хороший оптимизированный JIT под x86 будет работать лучше на Эльбрусе, чем быстрый нативный порт на e2k. Правда там могут быть определённые "но", но это уже надо каждый случай отдельно обсуждать. Но в целом моя мысль в том, что в теории JIT более перспективны для Эльбруса, но на практике это малореалезуемо скорее всего. Создание нормального RISC с ОоО проще, прямее, дешевле, удобнее и экнономит кучу времени для программистов.
JIT'ы имеют возможность собрать динамическую информацию об исполняемом коде и соптимизировать его исходя из этого. Т.е. в таком режиме они немного закрывают тот гап, который VLIW процессоры имеют по сравнению с RISC/CISC с OoO.
Проблема в том, что создать такой JIT для VLIW - задача очень серьёзная. У того же МЦСТ просто нет ресурсов на такое. Поэтому в итоге JIT'ы для того же Эльбруса в реальности неоптимизированы и работают крайне плохо (кроме бинарки x86->e2k в которую было вложено много ресурсов)