Во-первых, будь я хоть земляным червяком или Хищником, от этого технические аргументы не изменятся и проблемы Эльбруса никуда не уйдут. Во-вторых, в профессиональной технической дискуссии перейти на личности в первом же предложении - это расписаться в собственной некомпетентности в вопросе. Учтите на будущее.
Что касается Ваших тезисов. Они страдают некоторой оторванностью от практики, давайте попробую объяснить чуть подробнее. В утверждении "Интел буквально каждый раз один и тот же код анализирует в рантайме" нет никаких цифр, сколько это стоит в реальности. Потому что если 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 в которую было вложено много ресурсов)
Конечно. Команда, делавшая Exagear, вышла из отдела бинарки, делавшей RTC. Это на всех презентациях Элтеховских указывалось, да и название компании намекает.
Бегло посмотрев, могу сказать, что там они пытались вкорячить BP в реалии Эльбруса и по итогу получилось даже хуже. Это неудивительно, ибо там в округе, в том же компиляторе, надо многое допиливать, чтобы адаптироваться с новой схеме переходов. Да и вообще, архитектура это достаточно комплексная вещь. BP критически важен для RISC/CISC архитектур, а в реалиях Эльбруса как его грамотно использовать ещё надо подумать и скорее всего это должно повлечь очень серьёзные переделки, отсюда мой скепсис, что BP уйдёт в реальный камень в итоге.
Что касается вашего вопроса про BP и площадь кристалла. Это достаточно типичное заблуждение (которое культивируется адептами VLIW), что VLIW - простой. В реальности чтобы обеспечить всю эту параллельность на уровне ШК и поддержку всяких оптимизаций - требуется очень много транзисторов и соответственно пауэра. И получается, что в итоге "сложный BP" оказывается менее ёмким, чем вся машинерия в округе, обеспечивающая раскрутку параллельного конвейера.
Обсуждения про предсказатель переходов я слышал лет 10 назад точно, а может и больше. Я честно говоря сильно сомневаюсь, это колоссальные переделки. Ну и скажем прямо, это и есть признание того, что концепция VLIW в чистом виде неудачна. Сделают предсказатель, потом глядишь и операции начнут переставлять в аппаратуре )
Вы это теоретически рассказываете или реально сами трогали кишки AOSPшного JIT'a? Во-первых, там на схеме чётко написано, что если AOT скомпилировано, то запускай его. Во-вторых, я в тех местах сам предметно лазил года 3-4 назад, возможно они что-то подкрутили, но тогда JIT врубался только для того dex кода, который по каким-либо причинам не был предкомпилирован. Что согласуется с указанной картинкой.
На самом деле это само по себе не имеет отношение к дискуссии. В общем-то в Android действительно всё есть для полноценного JIT'a, это регулируется нужными ручками при сборке. И для Эльбруса это имеет потенциальные преимущества, тут я абсолютно согласен и написал об этом выше.
Правда я как представлю, во что скомпилится весь ART под Эльбрусом, меня холодный пот прошибает))) Там просто самый худший вариант, который может быть по перфу для Эльбруса, наверное. Но ладно, подождём пару минут пока вся инициализация прогрузится а там будем надеяться, что в сам runtime из кода выходить почти не будем )))
Я понимаю, что вы хотите сказать. Но в ваших рассуждений есть логическая лакуна, которую я пытаюсь показать, но видимо получается не очень.
Давайте попробую по-другому. Есть код, для которого OoO не нужен. В таких условиях — да, VLIW будет работать на уровне RISC/CISC по перфу, сэкономив при этом какие-то транзисторы и мощность в теории. Проблема в том, что таких задач мало (я, кстати, об этом вверху упоминал и это по-видимому согласуется с вашим тезисом, что удел VLIW — спецвычислители и графоний). Если же начинается реальная жизнь из того кода, который актуален для серверов/десктопов, то VLIW там просто начинает проигрывать безбожно. Чтобы как-то эту ситуацию подправить и на общих нагрузках проигрывать RISC/CISC с OoO не в 10, а скажем в 2 раза, надо добавлять всякие специфические фичи в процессор, по типу DAM, MLT, вращающихся регистров и т.д. А это на самом деле тоже стоит пауэра и транзисторов (да ещё и частоты косвенно). Поэтому в итоге на реальном VLIW процессоре, хоть как-то пригодном для жизни у вас даже бабочка будет уступать RISC/CISC. Ну т.е. если вы делаете спецпроцессор — то да, VLIW может быть конкурентен. А для general CPU — нет. Надеюсь, так моя мысль лучше понятна.
Я говорил не про работу Андроида, а про его сборку, если что ))
Касаемо работы Android, в принципе JIT'ы для Эльбрусов потенциально более подходят, т.к. есть возможность как раз собирать динамически какую-то инфу и что-то с этим делать. Но правда Dalvik достаточно давно уже работает в основном в режиме AOT поэтому JIT-кода там как такового практически нет
Но и Эльбрус сделан с расчётом на то, чтобы компилятор мог по максимуму забивать ШК
Сделан-то сделан, проблема в том, что в реальной жизни очень многое мешает эффективной набивке ШК. Не разорвалась зависимость по памяти - проблема (DAM не всегда можно применить). Много ветвлений - проблема (бранч предиктора нет, надо либо всё тащить под предикаты, а это по сути исполнение паразитного кода, либо оставлять как есть, тогда торчать на подготовках регистров переходов, а их всего 3 и задержка там 5 тактов до перехода). А уж если не смогли в горячий цикл call заинлайнить - то туши свет на любых оптимизациях фактически. Т.е. сборка с динамической линковкой библиотек просто априори будет страдать от больших деградаций. Поэтому на практике VLIW существенно уступает по перфу более классическим архитектурам.
В общем случае это не так. Во-первых, на любой мало-мальски сложной программе у компилятора Эльбруса возникнут проблемы. Т.е. там просто невозможно сгенерировать что-то даже приближенное к идеальному коду. Во-вторых, даже если мы возьмём какой-нибудь крайне простой или синтетический пример, где компилятор сможет идеально упаковать ШК, то у вас VLIW процессор банально будет работать на частоте ниже обычного RISC/CISC, и этот RISC/CISC ещё и транзисторов занимать меньше и энергии потреблять тоже меньше. Посмотрите ради интереса на характеристики того же Итаниума и сравните их с аналогичной линейкой x86-64. На том же техпроцессе и схожих параметрах ядра/кэшей, там частота существенно ниже x86-64, при этом и Ватт больше, и площадь выше.
Нет, обратное неверно. Всё, что делает компилятор для VLIW, спокойно может делать и компилятор для RISC/CISC. Разница в том, что если для RISC/CISC компилятор что-то недооптимизирует, то аппаратура подстрахует и соптимизирует сама (это стоит определённых транзисторов для OoO движка). В случае VLIW, если компилятор что-то не смог (а его возможности в реальности крайне ограничены), то всё, аппаратура уже ничего не сможет сделать.
Во-первых, раз уж вы утверждаете, что x86 плохо подходит под такие задачи, будет здорово, если вы укажите, что подходит лучше. Я пока лишь утверждаю, что x86 лучше чем Эльбрус, и пользователи, при прочих равных, будут выбирать первый.
Во-вторых про себестоимость вы написали что-то странное. Для топовых серверных решений люди покупают x86 процы ценой по 10к баксов только потому, что им критически важен абсолютный перформанс на своих задачах. И они готовы переплатить раз этак в 5-10 за проц только за дополнительные 20% производительности, например. Т.е. себесоимость устройств тут мало на что влияет. У тех же процов Arm себестоимость ниже, но тем не менее, они доминируют только в определенных нишах. Вопрос почему та или иная процессорная архитектура достигла/не достигла успеха многогранный. Но в данный момент речь идёт только о том, что чисто с технической точки зрения у VLIW-архитектур есть понятные недостатки, по причине которых они в общем случае уступают по производительности классическим RISC/CISC архитектурам.
Нет, принципиально уступает. И с точки зрения абстрактной архитектуры (нет возможности использовать динамическую информацию, которая присутствует во время исполнения), и с точки зрения реальной имплементации в железе (много регистров нужно, отсюда проблемы с частотой т.д.)
В целом - да. Эльбрус не является процом, подходящим для массового серверного/десктопного рынка. Есть определённые задачи, где он может быть на уровне, но это точно не работа Ворда или сборка AOSP.
Нет, это не так. Для того, чтобы достичь хоть какой-то вменяемой производительности, Эльбрусу надо делать много спекулятивных и предикатных вычислений. Проще говоря, если мы возьмём какую-то программу, то количество исполненных микроопераций при её запуске на Эльбрусе будет выше, чем на x86, например. Плюс у Эльбруса очень жирный код получается, это тоже большой минус по сравнению с классическими RISC/CISC
Эльбрус никогда не производился на 65нм на отечественных заводах. Был образец, сделанный на 90нм (это какой-то из первых образцов Эльбруса). Насколько помню, там было много проблем и плохой выгод годных. Проще говоря, Эльбрус для массового производства на отечественных заводах не готов.
Уважаемый коллега,
Во-первых, будь я хоть земляным червяком или Хищником, от этого технические аргументы не изменятся и проблемы Эльбруса никуда не уйдут. Во-вторых, в профессиональной технической дискуссии перейти на личности в первом же предложении - это расписаться в собственной некомпетентности в вопросе. Учтите на будущее.
Что касается Ваших тезисов. Они страдают некоторой оторванностью от практики, давайте попробую объяснить чуть подробнее. В утверждении "Интел буквально каждый раз один и тот же код анализирует в рантайме" нет никаких цифр, сколько это стоит в реальности. Потому что если 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 в которую было вложено много ресурсов)
Конечно. Команда, делавшая Exagear, вышла из отдела бинарки, делавшей RTC. Это на всех презентациях Элтеховских указывалось, да и название компании намекает.
и?
Спасибо, я не видел данную статью.
Бегло посмотрев, могу сказать, что там они пытались вкорячить BP в реалии Эльбруса и по итогу получилось даже хуже. Это неудивительно, ибо там в округе, в том же компиляторе, надо многое допиливать, чтобы адаптироваться с новой схеме переходов. Да и вообще, архитектура это достаточно комплексная вещь. BP критически важен для RISC/CISC архитектур, а в реалиях Эльбруса как его грамотно использовать ещё надо подумать и скорее всего это должно повлечь очень серьёзные переделки, отсюда мой скепсис, что BP уйдёт в реальный камень в итоге.
Что касается вашего вопроса про BP и площадь кристалла. Это достаточно типичное заблуждение (которое культивируется адептами VLIW), что VLIW - простой. В реальности чтобы обеспечить всю эту параллельность на уровне ШК и поддержку всяких оптимизаций - требуется очень много транзисторов и соответственно пауэра. И получается, что в итоге "сложный BP" оказывается менее ёмким, чем вся машинерия в округе, обеспечивающая раскрутку параллельного конвейера.
Нет, к сожалению ((
На самом деле это само по себе не имеет отношение к дискуссии. В общем-то в Android действительно всё есть для полноценного JIT'a, это регулируется нужными ручками при сборке. И для Эльбруса это имеет потенциальные преимущества, тут я абсолютно согласен и написал об этом выше.
Правда я как представлю, во что скомпилится весь ART под Эльбрусом, меня холодный пот прошибает))) Там просто самый худший вариант, который может быть по перфу для Эльбруса, наверное. Но ладно, подождём пару минут пока вся инициализация прогрузится а там будем надеяться, что в сам runtime из кода выходить почти не будем )))
Давайте попробую по-другому. Есть код, для которого OoO не нужен. В таких условиях — да, VLIW будет работать на уровне RISC/CISC по перфу, сэкономив при этом какие-то транзисторы и мощность в теории. Проблема в том, что таких задач мало (я, кстати, об этом вверху упоминал и это по-видимому согласуется с вашим тезисом, что удел VLIW — спецвычислители и графоний). Если же начинается реальная жизнь из того кода, который актуален для серверов/десктопов, то VLIW там просто начинает проигрывать безбожно. Чтобы как-то эту ситуацию подправить и на общих нагрузках проигрывать RISC/CISC с OoO не в 10, а скажем в 2 раза, надо добавлять всякие специфические фичи в процессор, по типу DAM, MLT, вращающихся регистров и т.д. А это на самом деле тоже стоит пауэра и транзисторов (да ещё и частоты косвенно). Поэтому в итоге на реальном VLIW процессоре, хоть как-то пригодном для жизни у вас даже бабочка будет уступать RISC/CISC. Ну т.е. если вы делаете спецпроцессор — то да, VLIW может быть конкурентен. А для general CPU — нет. Надеюсь, так моя мысль лучше понятна.
Я говорил не про работу Андроида, а про его сборку, если что ))
Касаемо работы Android, в принципе JIT'ы для Эльбрусов потенциально более подходят, т.к. есть возможность как раз собирать динамически какую-то инфу и что-то с этим делать. Но правда Dalvik достаточно давно уже работает в основном в режиме AOT поэтому JIT-кода там как такового практически нет
Сделан-то сделан, проблема в том, что в реальной жизни очень многое мешает эффективной набивке ШК. Не разорвалась зависимость по памяти - проблема (DAM не всегда можно применить). Много ветвлений - проблема (бранч предиктора нет, надо либо всё тащить под предикаты, а это по сути исполнение паразитного кода, либо оставлять как есть, тогда торчать на подготовках регистров переходов, а их всего 3 и задержка там 5 тактов до перехода). А уж если не смогли в горячий цикл call заинлайнить - то туши свет на любых оптимизациях фактически. Т.е. сборка с динамической линковкой библиотек просто априори будет страдать от больших деградаций. Поэтому на практике VLIW существенно уступает по перфу более классическим архитектурам.
Зачем отвоёвывать?)
В общем случае это не так. Во-первых, на любой мало-мальски сложной программе у компилятора Эльбруса возникнут проблемы. Т.е. там просто невозможно сгенерировать что-то даже приближенное к идеальному коду. Во-вторых, даже если мы возьмём какой-нибудь крайне простой или синтетический пример, где компилятор сможет идеально упаковать ШК, то у вас VLIW процессор банально будет работать на частоте ниже обычного RISC/CISC, и этот RISC/CISC ещё и транзисторов занимать меньше и энергии потреблять тоже меньше. Посмотрите ради интереса на характеристики того же Итаниума и сравните их с аналогичной линейкой x86-64. На том же техпроцессе и схожих параметрах ядра/кэшей, там частота существенно ниже x86-64, при этом и Ватт больше, и площадь выше.
Нет, обратное неверно. Всё, что делает компилятор для VLIW, спокойно может делать и компилятор для RISC/CISC. Разница в том, что если для RISC/CISC компилятор что-то недооптимизирует, то аппаратура подстрахует и соптимизирует сама (это стоит определённых транзисторов для OoO движка). В случае VLIW, если компилятор что-то не смог (а его возможности в реальности крайне ограничены), то всё, аппаратура уже ничего не сможет сделать.
Точно :)
Во-первых, раз уж вы утверждаете, что x86 плохо подходит под такие задачи, будет здорово, если вы укажите, что подходит лучше. Я пока лишь утверждаю, что x86 лучше чем Эльбрус, и пользователи, при прочих равных, будут выбирать первый.
Во-вторых про себестоимость вы написали что-то странное. Для топовых серверных решений люди покупают x86 процы ценой по 10к баксов только потому, что им критически важен абсолютный перформанс на своих задачах. И они готовы переплатить раз этак в 5-10 за проц только за дополнительные 20% производительности, например. Т.е. себесоимость устройств тут мало на что влияет. У тех же процов Arm себестоимость ниже, но тем не менее, они доминируют только в определенных нишах. Вопрос почему та или иная процессорная архитектура достигла/не достигла успеха многогранный. Но в данный момент речь идёт только о том, что чисто с технической точки зрения у VLIW-архитектур есть понятные недостатки, по причине которых они в общем случае уступают по производительности классическим RISC/CISC архитектурам.
Нет, принципиально уступает. И с точки зрения абстрактной архитектуры (нет возможности использовать динамическую информацию, которая присутствует во время исполнения), и с точки зрения реальной имплементации в железе (много регистров нужно, отсюда проблемы с частотой т.д.)
В целом - да. Эльбрус не является процом, подходящим для массового серверного/десктопного рынка. Есть определённые задачи, где он может быть на уровне, но это точно не работа Ворда или сборка AOSP.
Нет, это не так. Для того, чтобы достичь хоть какой-то вменяемой производительности, Эльбрусу надо делать много спекулятивных и предикатных вычислений. Проще говоря, если мы возьмём какую-то программу, то количество исполненных микроопераций при её запуске на Эльбрусе будет выше, чем на x86, например. Плюс у Эльбруса очень жирный код получается, это тоже большой минус по сравнению с классическими RISC/CISC
Эльбрус никогда не производился на 65нм на отечественных заводах. Был образец, сделанный на 90нм (это какой-то из первых образцов Эльбруса). Насколько помню, там было много проблем и плохой выгод годных. Проще говоря, Эльбрус для массового производства на отечественных заводах не готов.