Бенчмарки заточены под обычные процессоры, поэтому для Эльбрусов они не показательны, про закрытый geekbench и говорить нечего. Коме того у Эльбрусов есть вполне объективные проблемы с поддержкой скриптовых языков, о которых в МЦСТ знают и которые постепенно, по мере возможностей, решаются.
Я же говорю, Интел может оказаться всего лишь первой ласточкой. Сейчас вообще все открытые проекты под угрозой -- Гугл, вон, тоже не дремлет: https://www.opennet.ru/opennews/art.shtml?num=58565 Так что без Интела может и не загнётся, а вот без risc-v, на который Синтакор завязан -- вполне может и загнуться. Кому будет нужен их гипотетический процессор без соответствующей программной экосистемы? Кто будет писать для них софт, если риск-5 загнётся от недофинансирования? Очередной чемодан без ручки, который ещё произвести где-то нужно.
При том, что раньше Интел поддерживала производителей чипов на архитектуре RISC-V, а теперь перестала :-) Кто может гарантировать, что примеру Интел не последуют другие компании? Времена-то -- тяжёлые! ;-) Для поклонников risc-v это должно стать первым звоночком, я считаю.
Условный потенциальный покупатель будет покупать эльбрусы не для игр. Целевая ниша эльбрусов -- это как раз те самые офисы и госучреждения с высокими требованиями к безопасности и ограниченным перечнем софта, поэтому с портированием тут никаких проблем нет. А заточенные под е2к программы показывают весьма пристойную производительность. Впрочем, и игры никто не запрещает портировать на Эльбрусы, если конечно это кому-то нужно.
Тут речь не про поддержку команд для простоты написания эмуляторов, хотя она тоже будет влиять (но обычно не сильно)
Ну я так и понял, что в цитате Трушкина речь идёт о системе команд в целом. Об этом и говорю. Я имел в виду, что у Эльбрусов и своих подводных камней хватает, так они ещё и чужие к себе тянут.
(г) я у Кости не видел — сейчас ему уж не буду звонить, но по возможности уточните цитату хотя бы по памяти, спрошу.
Из эльбрусочатика в Телеге:
Andrey Petroff: "Костя, а ведь вы в МЦСТ все прекрасно знаете почему Эльбрус не может работать на высоких тактовых частотах. Но почему-то вы боитесь рассказать об этом общественности!"
Konstantin Trushkin: "Общественность не поймёт всех тонкостей. Что-то связано с VLIW-овостью, но не "вообще ШК", а конкретными особенностями реализации в Э. (я сам их до конца не знаю). Что-то с тем, что у нас не custom дизайн, а на стандартных ячейках (кроме регфайла). Что-то вообще с самой технологией. Вот для примера: Э-8СВ и Байкал-М оба на технологии 28 нм. И (сюрприз) оба - на 1.5 ГГц. Что народ думает? Правильно - виноват VLIW. Слышал от физдизайнеров, что на 16 нм поднять частоту кэша L1 выше 2 ГГц крайне сложно. Вообще, у всех. Это никак с архитектурой не связано. А что-то с тем, что мы тянем обратную совместимость до последнего (к этому подходу, мягко говоря, есть вопросы)".
(е) ровно так же является лично Вашим предположением, не основанным ни на чём — сделать условный larm или lriscv никакой принципиальной проблемы, насколько мне известно, не составляет; это ресурсный вопрос, как и для трансметы.
И не нужно, ибо: "С целью более эффективной трансляции кода вещественной арифметики в процессорах «Эльбрус» была реализована ее поддержка со стороны аппаратуры". (С) С. А. Родзевич "Аппаратная поддержка двоичной трансляции x86 вещественной арифметики в процессорах "Эльбрус"".
Я потому и бью тревогу, что вижу куда гребут разрабы Эльбруса -- в сторону Итаниума с его аппаратной поддержкой кодов x86. Считаю этот путь стратегически ошибочным.
При той сложности портирования какая у Эльбруса присутствует - транслятор это необходимость. Плюс он хорошо закрывает дыры в особенностях VLIW которые там просто по определению присутствуют
А тут вы натыкаетесь на особенность VLIW'ов и конкретно на её реализацию от МЦСТ - нельзя просто взять и выкинуть поддержку чего-то не сломав ISA или не сделав эмуляцию через микрокод
Это, к слову, еще одна причина почему VLIW не очень хороший выбор в чистом виде
Не уверен, что отдельные особенности нынешних Эльбрусов являются каким-то характерным и неустранимым свойством vliw архитектуры. Просто напомню, что в процессорах Интел семейства х86 параллелизм уровня инструкций (т.н. "суперскалярность") появился только в 1992 году (Pentium), а внеочередное исполнение и микрокод впервые были применены лишь в Pentium Pro в 1995 году. До того времени х86-е процессоры ничем подобным не обладали, при том что к vliw они никакого отношения естественно не имели. Так что хоронить Эльбрусы пока слишком рано, простор для развития у них ещё есть.
Про «МСЦТ» и «пиарили» чуть не сполз под стул: дружище, это суровая контора, которая пиаром не занимается практически вообще
Тем не менее при каждом публичном выступлении, которых было немало за последние несколько лет, представители МЦСТ не упускают случая "прорекламировать" свой транслятор, преподнося его как большое достижение и конкурентное преимущество своих процессоров. Я давно слежу за Эльбрусами и знаю о чём говорю. И на первый взгляд они правы.
В действительности же наличие такого транслятора:
а) размывает имидж Эльбрусов и приводит к ненужным предрассудкам и непониманию со стороны интересующихся данными процессорами людей;
б) отвлекает дефицитные человеческие и временные ресурсы от непосредственной работы над процессором и компилятором;
в) препятствует (а не упрощает, как это заявляется) переводу на е2к программной ифраструктуры, т.к. никто добровольно не будет портировать свой продукт на экзотическую архитектуру в ситуации когда есть совершенно легальная, предоставляемая самой МЦСТ возможность этого не делать. Пример -- новый КОМПАС-3D, разработчики которого вместо того, чтобы обеспечить нативную работу своего продукта под Линуксом (а от линукса до Эльбруса -- один шаг), просто обмазали его вайном;
г) усложняет внутреннее устройство процессоров, и без того страдающих от груза обратной совместимости (по словам самого К. Трушкина);
д) вызывает вопросы относительно надёжности работы оборудования, запущенного с применением бинарной трансляции, т.к. добавляется ещё одна точка отказа. Наблюдать такое влияние транслятора можно на примере запуска игр на инженерике 16С, когда в нативе игры работают нормально, а под линтелом падают. Понятно, что судить о работе процессора по опытному образцу не совсем правильно, но тем не менее зависимость налицо. А что будет если упадёт не игра, а что-то важное и ответственное?
е) в отличие от потенциально универсальной Трансметы, которую гипотетически можно было научить запускать код из-под любой архитектуры (ARM, RISC-V), lintel обучен запускать только х86. Следовательно, дальше у МЦСТ два пути: либо двигать Эльбрусы в сторону Трансметы, либо добавлять в свои процессоры всё новые и новые костыли (если уж выбирать, то лучше первое);
Короче говоря, надеюсь я доживу до того времени, когда разработчики Эльбрусов наберутся смелости и таки выбросят lintel на помойку, всем от этого станет только легче. А кому нужна совместимость с виндовыми программами -- пусть используют RTC.
Так вроде импортозамещение предполагает отказ от иностранного софта и оборудования, по крайней мере в госсекторе и в сфере КИ? Почему же пункт о наличии транслятора не убран из требований к Эльбрусам? Год-то на дворе не 2005-й...
Даже представить не могу зачем военным так остро могла бы понадобиться совместимость с x86. По-моему кто кто, а уж военные точно могли бы без этого обойтись. Да и вообще, что-то не особо слышно чтобы Эльбрусы применялись в военке...
Если честно, очень в этом сомневаюсь. Если бы такие требования существовали, то они распространялись бы на всех производителей, а не только на МЦСТ, но я что-то не слышал чтобы к Байкалу или Ядру предъявлялись подобные требования. Скорее всего картина следующая: в руководстве МЦСТ есть некто, кому очень нравится идея трансляции, вот они и пихают эту приблуду во все свои процессоры, даже несмотря на то, что это идёт вразрез с самой идеологией импортозамещения. Не исключено также, что эти "требования" составлялись не без участия представителей МЦСТ, и если бы они не пиарили свой транслятор, выдавая его за некую "киллерфичу", то, возможно, и требования такого со стороны "госзаказчика" не было бы. Пока что, по моим наблюдениям, ничего кроме вреда этот транслятор Эльбрусам не приносит.
Бенчмарки заточены под обычные процессоры, поэтому для Эльбрусов они не показательны, про закрытый geekbench и говорить нечего. Коме того у Эльбрусов есть вполне объективные проблемы с поддержкой скриптовых языков, о которых в МЦСТ знают и которые постепенно, по мере возможностей, решаются.
В открытой Готике и на х86 есть просадки до 25-30 fps: https://www.youtube.com/watch?v=0t23JYGiihc&t=441s
Я же говорю, Интел может оказаться всего лишь первой ласточкой. Сейчас вообще все открытые проекты под угрозой -- Гугл, вон, тоже не дремлет: https://www.opennet.ru/opennews/art.shtml?num=58565 Так что без Интела может и не загнётся, а вот без risc-v, на который Синтакор завязан -- вполне может и загнуться. Кому будет нужен их гипотетический процессор без соответствующей программной экосистемы? Кто будет писать для них софт, если риск-5 загнётся от недофинансирования? Очередной чемодан без ручки, который ещё произвести где-то нужно.
При том, что раньше Интел поддерживала производителей чипов на архитектуре RISC-V, а теперь перестала :-) Кто может гарантировать, что примеру Интел не последуют другие компании? Времена-то -- тяжёлые! ;-) Для поклонников risc-v это должно стать первым звоночком, я считаю.
Ага, ждите, обещаного три года ждут... Хотя я бы на Синтакор сильно не рассчитывал, т.к. похоже что risc-v начинают потихоньку сливать: https://3dnews.ru/1080995/intel-zakrivaet-podrazdelenie-setevih-kommutatorov-i-prekrashchaet-programmu-poddergki-protsessornoy-arhitekturi-riscv
Условный потенциальный покупатель будет покупать эльбрусы не для игр. Целевая ниша эльбрусов -- это как раз те самые офисы и госучреждения с высокими требованиями к безопасности и ограниченным перечнем софта, поэтому с портированием тут никаких проблем нет. А заточенные под е2к программы показывают весьма пристойную производительность. Впрочем, и игры никто не запрещает портировать на Эльбрусы, если конечно это кому-то нужно.
Может всё-таки конкретно Эльбрусам чего-то не хватает, а не vliw вообще? Так-то на 8СВ развитие Эльбрусов не остановилось...
Только в случае разных архитектур частота не является показателем производительности.
Ну я так и понял, что в цитате Трушкина речь идёт о системе команд в целом. Об этом и говорю. Я имел в виду, что у Эльбрусов и своих подводных камней хватает, так они ещё и чужие к себе тянут.
Слышал что в Pentium Pro впервые появилось разделение на CISC-фронтенд и RISC-бэкенд. Возможно что-то и напутал...
Из эльбрусочатика в Телеге:
Andrey Petroff: "Костя, а ведь вы в МЦСТ все прекрасно знаете почему Эльбрус не может работать на высоких тактовых частотах. Но почему-то вы боитесь рассказать об этом общественности!"
Konstantin Trushkin: "Общественность не поймёт всех тонкостей. Что-то связано с VLIW-овостью, но не "вообще ШК", а конкретными особенностями реализации в Э. (я сам их до конца не знаю). Что-то с тем, что у нас не custom дизайн, а на стандартных ячейках (кроме регфайла). Что-то вообще с самой технологией. Вот для примера: Э-8СВ и Байкал-М оба на технологии 28 нм. И (сюрприз) оба - на 1.5 ГГц. Что народ думает? Правильно - виноват VLIW. Слышал от физдизайнеров, что на 16 нм поднять частоту кэша L1 выше 2 ГГц крайне сложно. Вообще, у всех. Это никак с архитектурой не связано. А что-то с тем, что мы тянем обратную совместимость до последнего (к этому подходу, мягко говоря, есть вопросы)".
И не нужно, ибо: "С целью более эффективной трансляции кода вещественной арифметики в процессорах «Эльбрус» была реализована ее поддержка со стороны аппаратуры". (С) С. А. Родзевич "Аппаратная поддержка двоичной трансляции x86 вещественной арифметики в процессорах "Эльбрус"".
Я потому и бью тревогу, что вижу куда гребут разрабы Эльбруса -- в сторону Итаниума с его аппаратной поддержкой кодов x86. Считаю этот путь стратегически ошибочным.
Не уверен, что отдельные особенности нынешних Эльбрусов являются каким-то характерным и неустранимым свойством vliw архитектуры. Просто напомню, что в процессорах Интел семейства х86 параллелизм уровня инструкций (т.н. "суперскалярность") появился только в 1992 году (Pentium), а внеочередное исполнение и микрокод впервые были применены лишь в Pentium Pro в 1995 году. До того времени х86-е процессоры ничем подобным не обладали, при том что к vliw они никакого отношения естественно не имели. Так что хоронить Эльбрусы пока слишком рано, простор для развития у них ещё есть.
Тем не менее при каждом публичном выступлении, которых было немало за последние несколько лет, представители МЦСТ не упускают случая "прорекламировать" свой транслятор, преподнося его как большое достижение и конкурентное преимущество своих процессоров. Я давно слежу за Эльбрусами и знаю о чём говорю. И на первый взгляд они правы.
В действительности же наличие такого транслятора:
а) размывает имидж Эльбрусов и приводит к ненужным предрассудкам и непониманию со стороны интересующихся данными процессорами людей;
б) отвлекает дефицитные человеческие и временные ресурсы от непосредственной работы над процессором и компилятором;
в) препятствует (а не упрощает, как это заявляется) переводу на е2к программной ифраструктуры, т.к. никто добровольно не будет портировать свой продукт на экзотическую архитектуру в ситуации когда есть совершенно легальная, предоставляемая самой МЦСТ возможность этого не делать. Пример -- новый КОМПАС-3D, разработчики которого вместо того, чтобы обеспечить нативную работу своего продукта под Линуксом (а от линукса до Эльбруса -- один шаг), просто обмазали его вайном;
г) усложняет внутреннее устройство процессоров, и без того страдающих от груза обратной совместимости (по словам самого К. Трушкина);
д) вызывает вопросы относительно надёжности работы оборудования, запущенного с применением бинарной трансляции, т.к. добавляется ещё одна точка отказа. Наблюдать такое влияние транслятора можно на примере запуска игр на инженерике 16С, когда в нативе игры работают нормально, а под линтелом падают. Понятно, что судить о работе процессора по опытному образцу не совсем правильно, но тем не менее зависимость налицо. А что будет если упадёт не игра, а что-то важное и ответственное?
е) в отличие от потенциально универсальной Трансметы, которую гипотетически можно было научить запускать код из-под любой архитектуры (ARM, RISC-V), lintel обучен запускать только х86. Следовательно, дальше у МЦСТ два пути: либо двигать Эльбрусы в сторону Трансметы, либо добавлять в свои процессоры всё новые и новые костыли (если уж выбирать, то лучше первое);
Короче говоря, надеюсь я доживу до того времени, когда разработчики Эльбрусов наберутся смелости и таки выбросят lintel на помойку, всем от этого станет только легче. А кому нужна совместимость с виндовыми программами -- пусть используют RTC.
Так вроде импортозамещение предполагает отказ от иностранного софта и оборудования, по крайней мере в госсекторе и в сфере КИ? Почему же пункт о наличии транслятора не убран из требований к Эльбрусам? Год-то на дворе не 2005-й...
Даже представить не могу зачем военным так остро могла бы понадобиться совместимость с x86. По-моему кто кто, а уж военные точно могли бы без этого обойтись. Да и вообще, что-то не особо слышно чтобы Эльбрусы применялись в военке...
Если честно, очень в этом сомневаюсь. Если бы такие требования существовали, то они распространялись бы на всех производителей, а не только на МЦСТ, но я что-то не слышал чтобы к Байкалу или Ядру предъявлялись подобные требования. Скорее всего картина следующая: в руководстве МЦСТ есть некто, кому очень нравится идея трансляции, вот они и пихают эту приблуду во все свои процессоры, даже несмотря на то, что это идёт вразрез с самой идеологией импортозамещения. Не исключено также, что эти "требования" составлялись не без участия представителей МЦСТ, и если бы они не пиарили свой транслятор, выдавая его за некую "киллерфичу", то, возможно, и требования такого со стороны "госзаказчика" не было бы. Пока что, по моим наблюдениям, ничего кроме вреда этот транслятор Эльбрусам не приносит.