У VLIW Э премущество в полной независимости от средств обхода архитектурных недостатков процессоров legacy-подхода -
А это заявление можете подкрепить какой нибудь статьёй, где это формально доказывается?
А то понимаете в чем дело - раз есть предсказатель ветвлений (а он в э16 вроде как есть), значит если он неаккуратно сделан то возможен весь спектр атак на него.
Есть кэш? См. Выше, но только весь спектр атак на тайминги.
И так далее.
К сожалению, без математики я вам на слово не поверю.
Т.е. трудно создать быстрый процессор в рамках legacy-подхода без риска подпасть под патентные риски
Ну так лицензируйте нужные патенты, раз все так, как вы говорите, все же как тт справляются. (Это вообще намёк на то, что патенты действуют ограниченное время и далеко не все о чем вы говорите ими покрыто).
Во-вторых Эльбрусы не нуждается в постоянном патчинге дыр в этих кокостыляхв
Поверю когда вы мне покажите эволюцию errata на Эльбрус, в которой будет пусто. Можете?
P.s и чтобы называть имеющиеся подходы- legacy, вам бы неплохо начать с доказательства, что это так. Опять же - формально строгого.
да все знают преимущества VLIW архитектуры, кто только её не пользует (TI, AMD, Intel),
У TI - DSP, да, VLIW'ы, но не в процессоре общего назначения.
У Intel следы VLIW' а в кусочках Intel Xe разве что. Итаниум они недавно похоронили. Замечу, то что осталось тоже скорее в специализированных ускорителях.
У AMD были прошлые видеокарты (до GCN даже) на базе VLIW, но отказались по все тем же причинам, по которым не взлетел Itanium в свое время.
Что то я ещё забыл? Может есть какой нибудь пример процессора общего назначения на базе VLIW, что до сих пор жив и успешен, но я не знаю о нем?
ну и если Эльбрусы удастся применить в университетской программе, то почему нет?
Потому что это будет растратой с нулевым преимуществом перед любым современным ARM, x86 или чем нибудь там ещё.
эти компы мне дали базовые знания, которые я развил.
Знания дают не компы, а учебнын программы. Включите в обучение пару семестров по архитектурам и заставьте студентов сдавать курсач по проектированию своего простого ядра - пользы будет в разы больше при меньших затратах.
а уже когда появится массовость из-за применение в госзакупках, тогда процы станут дешевле
Этой уверенности я не понимаю от слова совсем. Никто не мешал мцст заказать партию э8с в 10 раз больше чем они заказывали (у Байкала же вышло заказать больше эмок чем было выпущено эльбрусов за последние 20 лет, включая инженерники), но тут надо помнить, что у мцст ядро, которое в среднем похоже по скорости на современные атомы, но площадь чипа - 600 с лишним кв.мм, такое дешевл не будет в принципе (я про 16с)
Так ссылка старая, времен всей истории. С тех пор убрали, к сожалению. Не понимаю правда зачем, возможно стоит спросить того кто выложил в свое время бинарники, благо он же автор статьи ;)
а вот для разработчиков, которым действительно может предоставляться информация с грифами - то тут помимо рисков еще и геморрой по получению форм допусков для сотрудников и организации работы с содержащими её носителями.
Нюанс для разработчика в том, что ты можешь не знать что информация секретная, когда разглашаешь - это не избавит тебя от ответственности. То есть разрабочтик, который реверсом получил что-то что под грифом и решил написать статью на хабре - вполне себе будет виноват. Поэтому работать с такой штукой - как мне кажется опасно для собственного благополучия.
Секретность и отсутствие нормальной документации ставит крест на всей экосистеме даже если представить что ради легальности взяли и все переделали без GPL компонентов и более того - даже если вдруг начали соблюдать GPL и все исправно выкладывать. Без нормальной документации (тех же гайдлайнов по оптимизации) работать с таким процессором будет то еще удовольствие. Не говоря про то что если это графи секретности где-то есть - то банально юридически опасно - вдруг случайно нарушишь.
Всё это - теоретические фантазии защитников JIT. Что в каком-то редком случае JIT обгонит код собранный без JIT. При этом о всех накладных расходах они забывают, и что в среднем JIT будет хуже нативной компиляции.
Все это лежит в основе подходов той же nVidia к VLIW'ам, то есть люди видели на практике. Я готов продолжить обсуждать эту тему когда вы принесете какое-нибудь подтверждение своих слов (за подтверждением моих я вас отправлю смотреть на примеры которые я обозначил ранее).
Их можно было какое-то время купить, но смысла в этом нет (поправьте если не прав). Так как если верить фотографиям и описаниям, это был SSD на Silicon Motion 2013-2014 года разработки, совершенно непонятно зачем брать его, а не какой-нибудь Samsung, или если прям нужен тот же Silicon Motion контроллер и та же память - поискать конкретное сочетание у Crucial, Kingston и еще десятка вендоров.
что у них где используется, будет только уменьшаться...
Увы, это правда так. Хотя я в этом плане исключительно за открытость - мне кажется налогоплательщики имеют право знать на что конкретно пошли их налоги. Пусть и без деталей.
С другой стороны - вряд ли это повлияет на возможности коммерческого применения этого процессора?..
Мне это интересно с точки зрения аргумента "Мин Обороны запрещает", который кажется еще более шит белыми нитками, если Эльбрусы в этой самой оборонке дальше офиса не используются.
Ведь весь интерес к нему и все споры вокруг него исходят именно из потенциальной возможности его использования именно как коммерческого процессора, по-моему?
Весь интерес и споры вокруг его коммерческих продаж - да, именно из этого и исходят. Но вопросы вокруг применения железки минобороны напрямую влияют на это самое коммерческое применение - так как если вокруг половины вопросов страшный NDA и чуть ли не гостайна - это как по мне ставит крест на его коммерческом применении вне зависимости от остальных качеств (я, напомню, за то что нельзя продавать то, на что лицензии не соблюдаются в принципе, это как минимум незаконно, а может еще и неэтично).
Что совершенно не решает проблему статического планирования выполнения кода. Немного маскирует разве что.
Простой пример - стоит пользователю отклонится от типичного пути под который был сделан профиль - и получим еще большую просадку производительности на VLIWах чем было бы без профиля. Если код у нас в основном линейный, но профиль дает какие-то преимущества - это повод пойти к авторам компилятора и объяснить им при помощи багов что они неправы.
И потом еще повторная компиляция.
И еще, и еще и столько раз сколько нужно это самое еще. И это дает именно динамическое планирование выполнения кода, в зависимости от действий пользователя. Да, ценой дополнительных счетчиков, зондов, фидбека и периодического пересмотра оптимизаций.
Почему-то про R500/R1000/R2000 открыто известны примеры конкретных устройств, где они используются. Не понимаю, почему такой же уровень информации недоступен про Эльбрус.
но из неё тоже мало что понятно.
Из нее понятно, что закупали компьютеры, но не для каких-то критичных применений, так как по сути там 801-PC - который простой десктоп с radeon'ом, hdd и Эльбрусом - то есть офисная машинка.
Нет, VLIW хуже подходит для JIT, потому что VLIW компиляция сложная
Я говорил что он там раскрывает себя с лучшей стороны. Имея в виду что результат лучше чем в случае с компиляцией. И причина тут простая - в случае с интерпретацией и JITом мы получаем динамическое планирование, которого у VLIW нет.
Да, это требует ресурсы, да, это всегда баланс между временем на оптимизацию и оптимальностью кода (поэтому у успешных реализаций JIT VM, не важно под VLIW или нет есть warmup и есть объектный кэш).
Собственно это все - причины по которым RTC у Эльбруса в некоторых случаях быстрее чем нативный код.
Которая обанкротовушилась еще в далёком 2008-м.
Строго говоря они не обанкротились, их в 2009 году купили. И это все никоим образом не умаляет их вклада в понимание особенностей того же VLIW.
Я может быть не совсем точно выразился - я конкретно говорил в контексте мин обороны как заказчика. Изделия на спарках у них есть, легко найти. А вот про Эльбрус я не слышал внятного ответа о том где условный Эльбрус-4С или 2СМ используется из проектов мин обороны.
а с другой - если вендор лишен права распространения копий, то копии не могут быть законно введены им в оборот и не могут законно появиться у их получателей.
Дальнейшнее распространение ПО становится невозможным, но все что было распространено в нарушении - ок.
А почему стреляют минусы на Эльбрусе? Исторически VLIW как раз раскрывает себя с лучшей стороны именно в JIT и собственно что Интел, что другие товарищи (мой любимый пример с nVidia и их ядрами Denver и Carmel - где они JITают ARM в VLIW, хотя можно и трансмету вспомнить) как раз таки делали упор именно на JIT компиляцию и даже говорили что-то в духе "да вот с нативным шедулером не очень вышло, но когда делаем jit там все недостатки программным образом решаются и получается нормально)
Раст такой язык, где принято использовать текущий stable по-умолчанию, то есть пока поддержка e2k не в апстриме или МЦСТ не сможет обеспечить задержку релиза нового раста в дни или недели - это все равно не считается за нормальную реализацию.
Но даже если не про jit'ы - что там с Golang? Язык компилируемый, подходы примерно такие же (поддерживается обычно stable и oldstable и oldoldstable версии, то есть на текущий момент 1.19, 1.18 и 1.17), правда отличительной особенностью его является то, что gccgo брать в продакшн мягко говоря не стоит из-за особенностей реализации. Так что вопрос - какая версия официального компилятора Го последняя на Эльбрусах?
А это заявление можете подкрепить какой нибудь статьёй, где это формально доказывается?
А то понимаете в чем дело - раз есть предсказатель ветвлений (а он в э16 вроде как есть), значит если он неаккуратно сделан то возможен весь спектр атак на него.
Есть кэш? См. Выше, но только весь спектр атак на тайминги.
И так далее.
К сожалению, без математики я вам на слово не поверю.
Ну так лицензируйте нужные патенты, раз все так, как вы говорите, все же как тт справляются. (Это вообще намёк на то, что патенты действуют ограниченное время и далеко не все о чем вы говорите ими покрыто).
Поверю когда вы мне покажите эволюцию errata на Эльбрус, в которой будет пусто. Можете?
P.s и чтобы называть имеющиеся подходы- legacy, вам бы неплохо начать с доказательства, что это так. Опять же - формально строгого.
Мне о таком неизвестно. Вроде бы я вас спросил кто применяет в процессорах общего назначения?
X86времен 486 не покрыт патентами уже. А лицензировать для реальной работы тот же арм - не понимаю чем плохо.
А зачем?
А что касается вариантов архитектур:
Кроме arm и прочего остаётся ещё несколько вариантов:
Risc-v
OpenPower
OpenSPARC
openRISC или как там его
Разработать свой risc
Очень интересно, что как пример глупых мантр привёл статью которая пыталась защитить Эльбрус. Но я понимаю, подлог в ней довольно очевиден.
У TI - DSP, да, VLIW'ы, но не в процессоре общего назначения.
У Intel следы VLIW' а в кусочках Intel Xe разве что. Итаниум они недавно похоронили. Замечу, то что осталось тоже скорее в специализированных ускорителях.
У AMD были прошлые видеокарты (до GCN даже) на базе VLIW, но отказались по все тем же причинам, по которым не взлетел Itanium в свое время.
Что то я ещё забыл? Может есть какой нибудь пример процессора общего назначения на базе VLIW, что до сих пор жив и успешен, но я не знаю о нем?
Потому что это будет растратой с нулевым преимуществом перед любым современным ARM, x86 или чем нибудь там ещё.
Знания дают не компы, а учебнын программы. Включите в обучение пару семестров по архитектурам и заставьте студентов сдавать курсач по проектированию своего простого ядра - пользы будет в разы больше при меньших затратах.
Этой уверенности я не понимаю от слова совсем. Никто не мешал мцст заказать партию э8с в 10 раз больше чем они заказывали (у Байкала же вышло заказать больше эмок чем было выпущено эльбрусов за последние 20 лет, включая инженерники), но тут надо помнить, что у мцст ядро, которое в среднем похоже по скорости на современные атомы, но площадь чипа - 600 с лишним кв.мм, такое дешевл не будет в принципе (я про 16с)
А по существу вам есть что сказать или возразить?
Так ссылка старая, времен всей истории. С тех пор убрали, к сожалению. Не понимаю правда зачем, возможно стоит спросить того кто выложил в свое время бинарники, благо он же автор статьи ;)
Нюанс для разработчика в том, что ты можешь не знать что информация секретная, когда разглашаешь - это не избавит тебя от ответственности. То есть разрабочтик, который реверсом получил что-то что под грифом и решил написать статью на хабре - вполне себе будет виноват. Поэтому работать с такой штукой - как мне кажется опасно для собственного благополучия.
Секретность и отсутствие нормальной документации ставит крест на всей экосистеме даже если представить что ради легальности взяли и все переделали без GPL компонентов и более того - даже если вдруг начали соблюдать GPL и все исправно выкладывать. Без нормальной документации (тех же гайдлайнов по оптимизации) работать с таким процессором будет то еще удовольствие. Не говоря про то что если это графи секретности где-то есть - то банально юридически опасно - вдруг случайно нарушишь.
Все это лежит в основе подходов той же nVidia к VLIW'ам, то есть люди видели на практике. Я готов продолжить обсуждать эту тему когда вы принесете какое-нибудь подтверждение своих слов (за подтверждением моих я вас отправлю смотреть на примеры которые я обозначил ранее).
Их можно было какое-то время купить, но смысла в этом нет (поправьте если не прав). Так как если верить фотографиям и описаниям, это был SSD на Silicon Motion 2013-2014 года разработки, совершенно непонятно зачем брать его, а не какой-нибудь Samsung, или если прям нужен тот же Silicon Motion контроллер и та же память - поискать конкретное сочетание у Crucial, Kingston и еще десятка вендоров.
Увы, это правда так. Хотя я в этом плане исключительно за открытость - мне кажется налогоплательщики имеют право знать на что конкретно пошли их налоги. Пусть и без деталей.
Мне это интересно с точки зрения аргумента "Мин Обороны запрещает", который кажется еще более шит белыми нитками, если Эльбрусы в этой самой оборонке дальше офиса не используются.
Весь интерес и споры вокруг его коммерческих продаж - да, именно из этого и исходят. Но вопросы вокруг применения железки минобороны напрямую влияют на это самое коммерческое применение - так как если вокруг половины вопросов страшный NDA и чуть ли не гостайна - это как по мне ставит крест на его коммерческом применении вне зависимости от остальных качеств (я, напомню, за то что нельзя продавать то, на что лицензии не соблюдаются в принципе, это как минимум незаконно, а может еще и неэтично).
Что совершенно не решает проблему статического планирования выполнения кода. Немного маскирует разве что.
Простой пример - стоит пользователю отклонится от типичного пути под который был сделан профиль - и получим еще большую просадку производительности на VLIWах чем было бы без профиля. Если код у нас в основном линейный, но профиль дает какие-то преимущества - это повод пойти к авторам компилятора и объяснить им при помощи багов что они неправы.
И еще, и еще и столько раз сколько нужно это самое еще. И это дает именно динамическое планирование выполнения кода, в зависимости от действий пользователя. Да, ценой дополнительных счетчиков, зондов, фидбека и периодического пересмотра оптимизаций.
Почему-то про R500/R1000/R2000 открыто известны примеры конкретных устройств, где они используются. Не понимаю, почему такой же уровень информации недоступен про Эльбрус.
Из нее понятно, что закупали компьютеры, но не для каких-то критичных применений, так как по сути там 801-PC - который простой десктоп с radeon'ом, hdd и Эльбрусом - то есть офисная машинка.
Я говорил что он там раскрывает себя с лучшей стороны. Имея в виду что результат лучше чем в случае с компиляцией. И причина тут простая - в случае с интерпретацией и JITом мы получаем динамическое планирование, которого у VLIW нет.
Да, это требует ресурсы, да, это всегда баланс между временем на оптимизацию и оптимальностью кода (поэтому у успешных реализаций JIT VM, не важно под VLIW или нет есть warmup и есть объектный кэш).
Собственно это все - причины по которым RTC у Эльбруса в некоторых случаях быстрее чем нативный код.
Строго говоря они не обанкротились, их в 2009 году купили. И это все никоим образом не умаляет их вклада в понимание особенностей того же VLIW.
Я может быть не совсем точно выразился - я конкретно говорил в контексте мин обороны как заказчика. Изделия на спарках у них есть, легко найти. А вот про Эльбрус я не слышал внятного ответа о том где условный Эльбрус-4С или 2СМ используется из проектов мин обороны.
Дальнейшнее распространение ПО становится невозможным, но все что было распространено в нарушении - ок.
Вчера забыл добавить еще одно: слухи говорят, что линукс требовался заказчиком.
А почему стреляют минусы на Эльбрусе? Исторически VLIW как раз раскрывает себя с лучшей стороны именно в JIT и собственно что Интел, что другие товарищи (мой любимый пример с nVidia и их ядрами Denver и Carmel - где они JITают ARM в VLIW, хотя можно и трансмету вспомнить) как раз таки делали упор именно на JIT компиляцию и даже говорили что-то в духе "да вот с нативным шедулером не очень вышло, но когда делаем jit там все недостатки программным образом решаются и получается нормально)
Релиз: 6 мая 2021 года
Раст такой язык, где принято использовать текущий stable по-умолчанию, то есть пока поддержка e2k не в апстриме или МЦСТ не сможет обеспечить задержку релиза нового раста в дни или недели - это все равно не считается за нормальную реализацию.
Но даже если не про jit'ы - что там с Golang? Язык компилируемый, подходы примерно такие же (поддерживается обычно stable и oldstable и oldoldstable версии, то есть на текущий момент 1.19, 1.18 и 1.17), правда отличительной особенностью его является то, что gccgo брать в продакшн мягко говоря не стоит из-за особенностей реализации. Так что вопрос - какая версия официального компилятора Го последняя на Эльбрусах?
Так ты так и не обосновал, почему такое поведение однопоточной задачи это нормально, да и почему однопоточные задачи это нетипично - тоже.