Кто-то писал что компы выглядят как копии сановских
Слухи это все для меня потому, что никто внутренности этих компьютеров не запечатлел. А как раз то, что выглядят они как копии сановских, еще и с Солярисом на борту, увеличивает шанс, что это не просто копии, а прям они и есть.
К тому же, у российской оборонки есть замечательная традиция - делать красивые видео, а потом то что на этом видео - убирать на полочку и на практике использовать что попроще и подоступнее.
Тому, кто занимается продвижением Эльбруса, например, на рынке супервычислений. Эльбрус для таковых задач создавался в общем то.
Теоретически он как минимум мог быть допилен под HPC и вот это все. На практике - там важно I/O и научный код тоже специфичный, написанный зачастую учеными, а не программистами. На Эльбрус такое ложится плохо, как за счет того что I/O сделан не очень и потому что наличие ветвлений (да и вообще не оптимального кода) очень сильно бьет по производительности Эльбруса. В итоге в этой нише результат закономерно такой же как и в других.
В итоге получается результат, когда теоретически можно войти в одну нишу, но процессор позиционируют вообще непонятно куда, как следствие - ведет он себя нормально тоже непонятно в чем.
А так, исторически, VLIW себя хорошо показывает в ситуациях, где надо однотипно молотить потоки данных, например в DSP. Но эта та ниша, куда Эльбрус почему-то не захотели позиционировать.
архитектура эльбруса отличается от х86 сильнее, чем АРМ и РиРиск-а
Почему это важно? ? какие именно отличия тут влияют? И почему вы думаете, что эти отличия не будут влиять в других местах?
активно применяется LuaJit, а в Эльбрусе он пока что работает в режиме трансляции
На Эльбрусе ряд вещей в режиме трансляции работает быстрее нативного, из за его особенностей (и так скорее всего будет всегда). Так что это не аргумент.
К тому же, luajit на нем нативный, но не эффективный.
нужно написать примерно 16000 строк двоичного кокода.а
Расскажите пожалуйста как это? Точнее что такое строки двоичного кода?
К тому же, почему под risc-v, la64 и прочие их написали, а под Эльбрус нет? Хотя Эльбрус старше чем risc-v и la64, притом намного.
У Бачило в тесте есть один момент - у опенсорс форка движка на вулкане нет поддержки теней из оригинального дума, которые и на видеокарту нагрузку дадут и на процессор. Поэтому его правильно тестировать на одном и том же рендере и параллельно смотреть загрузку по ядрам в том числе. Но даже у него видно (тут кстати он молодец, что показал mangohud с временем рендера, но надо с MANGOHUD_CONFIG где включен core_load еще хотя бы и также было бы прекрасно видеть gpu_*_clock'и можно сразу histogram), что есть периодические затыки, особенно когда на экране появляются объекты.
В думе еще есть свой бенчмарк встроенный, правильно было бы хотя бы сглаживание скрутить в ноль, записать фрагмент когда ты гуляешь и сражаешься, а потом этот фрагмент уже прогнать.
Вообще записывать лог работы игры с детальной информацией - это прям обязательно в таких случаях, так как расскажет больше о играбельности.
Ну во-первых, насколько я понимаю это пока ещё тестовый выпуск. Проба пера, так сказать. Во-вторых -- серверная часть была запущена в виртуалке на ноутбуке. Так что всё не так плохо, а со временем станет ещё лучше.
Демо-база 1С 8.2 работала идеально шустро, когда я в бытность свою админом в стартапе игрался на своем ноутбуке с свежевышедшим 1С 8.2 Сервером для Linux, запуская клиент на том же ноутбуке под Wine'ом. Я могу ошибаться, но на дворе был кажется 2009 год, а ноутбук у меня был одноядерный на Core Solo (что-то в духе 1.2-1.6 ГГц, к сожалению прям таких деталей не помню уже за давностью лет), какой-то Acer был. Никакого SSD там конечно же и в помине не было. Единственное отличие - разве что вместо сети был локальный жесткий диск, 5400 rpm. Впрочем, я не уверен что сеть не быстрее.
UPD: собственно база там не очень большая и работает она быстро, когда у тебя один единственный клиент.
то очевидно что дело не в бобине Эльбрусе, как некоторые пытаются это представить
Такое поведение объясняется просто идеально всем тем, что мы знаем про VLIW и Эльбрус.
Так что если не в эльбрусе, то в чем? И отвечая на этот вопрос, не забудьте что таких спецэффектов не наблюдается не только на x86, но и на ARM, на risc-v и на loongarch.
В открытой Готике и на х86 есть просадки до 25-30 fps
Есть небольшая разница между "обычно 200 FPS, но просадки до 25-30" и "держалась на уровне 25-30 FPS"
К слову, если посмотреть на видео примерно в том месте где на x86 просадки до 25-30,у Эльбруса там просадки до 14-17 скорее с периодическим восстановлением до 24-25.
В этом проблема пересказов - они теряют информацию. Иногда существенно.
Вообще есть еще одна общая проблема у конкретно этих бенчмарков - нужно строить график fps от времени хотя бы, а лучше опубликовать время рендера кадра. Это позволит сразу предметно сказать были ли микрофризы или нет (сейчас для этого приходится видео смотреть). Человек, к сожалению, довольно чувствительно воспринимает когда время рендера кадра скачет в больших пределах и у тебя, допустим, 40 FPS в среднем, но периодически есть просадки до 20 (как у них наблюдается в Counter Strike'е)
А зачем тащить то, что не находит подтверждения в реальных источниках?
Я выше приводил несколько, притом не только Crusoe, но и более быстрого Efficeon'а.
Можно взять какое-нибудь уважаемое издание типа toms hardware и посмотреть что писали там. Если не хочется читать то вывод простой - примерно половинка от равночастотного Pentium III.
Если взять то что я приносил выше - там более новые игры и бенчмарки показывают совсем грустные результаты (1/10 от равночастотного Athlon'а при прочих равных), в более старых - где-то даже 2/3 от Атлона у Efficeon'а, но чаще 1/2, а то и вовсе 1/4.
Впрочем, если у тестов от сотрудника МЦСТ такое расхождение с реальностью, это многое объясняет про Эльбрусы, так что спасибо за такую информацию. Буду теперь на этот твой ответ ссылаться, как подвернется удобный случай.
Да, отсутствие "V" extension в JH7110 несколько удручает
Не просто V, а чтоб rvv 1.0. Потому что у меня есть две платки с rvv 0.7.1, и толку от него ноль, если не хочется писать ассемблерные вставки и потом их выверять по спеке чтоб портировать с rvv 0.7.1 на 1.0, да и такой код в апстрим в здравом уме никто не возьмет.
четырехядерный 1.5ГГц камень на RISC-V за $25 это прорыв.
Еще и с M.2. К ней осталось напечатаь корпус, подобрать радиатор какой-нибудь (чип почти не греется, но 60 градусов на нем в бенчмарках я видел, так что лучше перестрахуюсь) и будет 24/7 билд сервер для всяких нужд. А, из еще лично для меня больших плюсов - M.2 Key M - он хоть внутри и PCIe 2.0 1x, но это куда лучше для долгосрочного использования чем только microSD и USB.
Я имел в виду, что у Эльбрусов и своих подводных камней хватает, так они ещё и чужие к себе тянут.
Если эти подводные камни используются только в эмуляторах - их потом легко можно заменить или даже выкинуть, так как понятно что пострадает.
Собственно поддержка трансляторов часто имеет какие-то аппаратные костыли (та же история в Apple M1, та же история в китайских Loongson'ах). В этом нет ничего плохого.
Слышал что в Pentium Pro впервые появилось разделение на CISC-фронтенд и RISC-бэкенд.
Так там действительно так и случилось - в Pentium Pro появился декодер и все x86 команды декодировались в риск-подобный набор микроопераций. Но тут кроется проблема перевода - в оригиналае это micro-ops, а в русскоязычных статьях оно стало микрокодом. Вещи эти на самом деле похожие.
Вот для примера: Э-8СВ и Байкал-М оба на технологии 28 нм. И (сюрприз) оба - на 1.5 ГГц
А если посмотреть по сторонам - то TSMC в сотрудничестве с ARM когда запускали и анонсировали 28нм ноду, показывали 3.1 ГГц ARM процессор. Никто Qualcomm'у не мешал на 28nm HPm от TSMC выпустить Snapdragon 805 с частотой 2.7 ГГц и т.п.
Поэтому я лично с большим скепсисом отношусь к подобным заявлениям, так как звучат они, перефразируя немного поговорку: плохому танцору и технологии мешают.
А что-то с тем, что мы тянем обратную совместимость до последнего (к этому подходу, мягко говоря, есть вопросы)".
А это речь про немного другое - МЦСТ тянет совместимость с прошлыми версиями микроархитектуры. Потому что, строго говоря, подход VLIWов (в общепринятом определении) плох как раз тем, что поправить ошибку дизайна исполнительных блоков можно только ценой потери совместимости со всем кодом, что это поведение использовал (в некоторых случаях - со всем кодом в принципе).
Тут речь не про поддержку команд для простоты написания эмуляторов, хотя она тоже будет влиять (но обычно не сильно)
в сторону Итаниума с его аппаратной поддержкой кодов x86.
В Итаниумах аппаратная трансляция была только в первых и 2-х, в 9000-ом её убрали и заменили на софтварный IA-32 EL
Китайская StarFive недавно выпустила одноплатник VisionFive2 на базе JH7110 - четырехядерная СнК на архитектуре RISC-V, с GPU и прочими делами. По бенчмаркам этот одноплатник очень близок к RPi4 (ARM Cortex-A72), ну или как любимый Вами Э-8ВС на общих задачах.
По бенчмаркам он местами как Cortex-A55, местами ближе к A72, смотря в чем. У него все очень плохо с FP, нет SIMD'а никакого и в задачах, где оно используется он скорее похож на Raspberry Pi 3. Но вот в реальных применениях да, близок к 8С или даже 8СВ. Будет лучше, когда портируют более свежее ядро и смогут использовать апстримный pvr. Потому что в текущей официальной rootfs графика без какого либо ускорения, можно подкостыльнуть некоторый софт чтобы он использовал проприетарный блоб, но я лично пока использую в консольном варианте (кроме буквально одного скриншота).
Собственно было бы в плате что-то веселое - я бы написал статью, но веселым он был во времена Beagle-V Beta (а BeagleBone очень просили никому ничего не рассказывать про скорость и остальное пока не решили все переделать с нуля, что уже случилось в районе выхода первого VisionFive), а теперь оно очень сильно повзрослело.
Вспомнился недавний цирк с транслятором X86 > ARM в Qualcomm Snapdragon 835
А этот цирк не в Snapdragon'ах, а в Windows 10 (поздних ARM редакциях) и Windows 11. От процессора оно не очень зависит, кроме того что Microsoft'у эмулятор помогал сделать квалком. Так трансляция работает и по сей день, я в некоторые игры играю в Win 11 в Parallels где steam запущен через Microsoft'овский транслятор, так как в отличии от маковского он хорошо работает в том числе со странными играми.
Собственно история с судом непонятно как но заглохла примерно как и появилась.
Не уверен, что отдельные особенности нынешних Эльбрусов являются каким-то характерным и неустранимым свойством vliw архитектуры
Пока что Эльбрус - это VLIW буквально по учебникам, так что в текущий момент все общие проблемы подхода - на месте.
Являются ли они устранимыми - это уже немного зависит от того что вы готовы считать VLIW'ом. Чтобы поправить недостатки Эльбруса, придется туда докидывать нормальный предсказатель ветвлений (собственно в 16С хотели), внеочередное исполнение, городить декодер, таки применять обновляемый микрокод и так далее... Будет ли это VLIW'ом, если исчезнет явное распределение задач по блокам? От ответа на этот вопрос и зависит можно ли считать эти особенности неустранимыми и свойственными всем VLIW'ам. Да и в текущий момент МЦСТ не применили даже все трюки (опять же прошу прощения за ссылку на относительно странный сайт, но по поздним Itanium'ам на удивление сложно найти сколько-то детальную информацию), что были в поздних Itanium'ах, так что даже если вы решите считать такой процессор все равно VLIW'ом, текущие Эльбрусы подвержены всем типичным VLIWовским болячкам.
а внеочередное исполнение и микрокод впервые были применены лишь в Pentium Pro в 1995 году
Микрокод был начиная с 8086. Внеочередное исполнение - да, появилось в Pentium Pro.
Так что хоронить Эльбрусы пока слишком рано, простор для развития у них ещё есть.
Тем не менее при каждом публичном выступлении, которых было немало за последние несколько лет, представители МЦСТ не упускают случая "прорекламировать" свой транслятор
При той сложности портирования какая у Эльбруса присутствует - транслятор это необходимость. Плюс он хорошо закрывает дыры в особенностях VLIW которые там просто по определению присутствуют (об этом много статей на хабре, не буду повторяться).
Но МЦСТ рекламирует свое детище иным способом - пытается протолкнуть его в вершины всех реестров, чтобы у людей не было выбора кроме как покупать Эльбрусы. Ну это конечно ИМХО, основанное на том как всякие Elbrus Day проходили, на том как себя тот же Трушкин ведет в публичном пространстве, что различные сотрудники Базальта говорят с отсылкой на МЦСТ и т.п.
г) усложняет внутреннее устройство процессоров, и без того страдающих от груза обратной совместимости (по словам самого К. Трушкина);
А тут вы натыкаетесь на особенность VLIW'ов и конкретно на её реализацию от МЦСТ - нельзя просто взять и выкинуть поддержку чего-то не сломав ISA или не сделав эмуляцию через микрокод. Собственно если покопаться и пособирать информацию, ошибки проектирования процессора тянутся с e2kv1, потому что их исправление сломает совместимость со всем уже собранным софтом. Это, к слову, еще одна причина почему VLIW не очень хороший выбор в чистом виде, в мире когда у тебя есть проприетарный софт или просто abandonware opensource невозможность менять детали реализации железа - по меньшей мере катастрофа. Собственно спросите Михаила, насколько необходима пересборка ВСЕГО софта под новые версии микроархитектуры.
в отличие от потенциально универсальной Трансметы, которую гипотетически можно было научить запускать код из-под любой архитектуры (ARM, RISC-V), lintel обучен запускать только х86
Так теоретическая возможность у МЦСТ сделать транслятор для ARM - так же есть. И также, как в случае с трансметой, она нереализована и не факт что когда-либо будет.
PS: если что — я этих устриц ел: и топовые RISC-V на ощупь проверял
Если ты их щупал, то какой смысл был в челлендже в твоем посте? Ты тогда должен был бы знать, что даже довольно посредственный risc-v его легко выполнит (о чем я там и написал, благо у меня есть и один из худших представителей и довольно средненький). Притом не просто легко - а просто раскатать систему и запустить браузер.
Плохие да, но не поддельные A1 - у меня пока на всей моей коллекции одноплатников ни разу не подводили (в общей сложности около 10ка, в основном Samsung Evo или SanDisk Extreme).
обойдется дороже 2.5 HDD или переходника на SATA с SATA винтом
Не соглашусь, но, возможно, отличие рынков.
Опять же - есть еще вариант с CF карты, которые до сих пор производятся и продаются, переходник CF -> 2.5" IDE стоит дешево, а карточек которые могут давать 160МБ в секунду или больше - до сих пор полно.
Слухи это все для меня потому, что никто внутренности этих компьютеров не запечатлел. А как раз то, что выглядят они как копии сановских, еще и с Солярисом на борту, увеличивает шанс, что это не просто копии, а прям они и есть.
К тому же, у российской оборонки есть замечательная традиция - делать красивые видео, а потом то что на этом видео - убирать на полочку и на практике использовать что попроще и подоступнее.
А почему вы думаете, что там Эльбрус используется или использовался?
Более-менее детальные слухи были про Эльбрус-90Микро, который к e2k отношения не имеет.
Теоретически он как минимум мог быть допилен под HPC и вот это все. На практике - там важно I/O и научный код тоже специфичный, написанный зачастую учеными, а не программистами. На Эльбрус такое ложится плохо, как за счет того что I/O сделан не очень и потому что наличие ветвлений (да и вообще не оптимального кода) очень сильно бьет по производительности Эльбруса. В итоге в этой нише результат закономерно такой же как и в других.
В итоге получается результат, когда теоретически можно войти в одну нишу, но процессор позиционируют вообще непонятно куда, как следствие - ведет он себя нормально тоже непонятно в чем.
А так, исторически, VLIW себя хорошо показывает в ситуациях, где надо однотипно молотить потоки данных, например в DSP. Но эта та ниша, куда Эльбрус почему-то не захотели позиционировать.
Почему это важно? ? какие именно отличия тут влияют? И почему вы думаете, что эти отличия не будут влиять в других местах?
На Эльбрусе ряд вещей в режиме трансляции работает быстрее нативного, из за его особенностей (и так скорее всего будет всегда). Так что это не аргумент.
К тому же, luajit на нем нативный, но не эффективный.
Расскажите пожалуйста как это? Точнее что такое строки двоичного кода?
К тому же, почему под risc-v, la64 и прочие их написали, а под Эльбрус нет? Хотя Эльбрус старше чем risc-v и la64, притом намного.
У Бачило в тесте есть один момент - у опенсорс форка движка на вулкане нет поддержки теней из оригинального дума, которые и на видеокарту нагрузку дадут и на процессор. Поэтому его правильно тестировать на одном и том же рендере и параллельно смотреть загрузку по ядрам в том числе. Но даже у него видно (тут кстати он молодец, что показал mangohud с временем рендера, но надо с MANGOHUD_CONFIG где включен core_load еще хотя бы и также было бы прекрасно видеть gpu_*_clock'и можно сразу histogram), что есть периодические затыки, особенно когда на экране появляются объекты.
В думе еще есть свой бенчмарк встроенный, правильно было бы хотя бы сглаживание скрутить в ноль, записать фрагмент когда ты гуляешь и сражаешься, а потом этот фрагмент уже прогнать.
Вообще записывать лог работы игры с детальной информацией - это прям обязательно в таких случаях, так как расскажет больше о играбельности.
Демо-база 1С 8.2 работала идеально шустро, когда я в бытность свою админом в стартапе игрался на своем ноутбуке с свежевышедшим 1С 8.2 Сервером для Linux, запуская клиент на том же ноутбуке под Wine'ом. Я могу ошибаться, но на дворе был кажется 2009 год, а ноутбук у меня был одноядерный на Core Solo (что-то в духе 1.2-1.6 ГГц, к сожалению прям таких деталей не помню уже за давностью лет), какой-то Acer был. Никакого SSD там конечно же и в помине не было. Единственное отличие - разве что вместо сети был локальный жесткий диск, 5400 rpm. Впрочем, я не уверен что сеть не быстрее.
UPD: собственно база там не очень большая и работает она быстро, когда у тебя один единственный клиент.
Такое поведение объясняется просто идеально всем тем, что мы знаем про VLIW и Эльбрус.
Так что если не в эльбрусе, то в чем? И отвечая на этот вопрос, не забудьте что таких спецэффектов не наблюдается не только на x86, но и на ARM, на risc-v и на loongarch.
Судя по видео - это все таки нативные сборки открытых движков и нативный клиент 1С. OpenMW для Morrowind'а, OpenGothic для Готики и т.п.
Есть небольшая разница между "обычно 200 FPS, но просадки до 25-30" и "держалась на уровне 25-30 FPS"
К слову, если посмотреть на видео примерно в том месте где на x86 просадки до 25-30,у Эльбруса там просадки до 14-17 скорее с периодическим восстановлением до 24-25.
В этом проблема пересказов - они теряют информацию. Иногда существенно.
Вообще есть еще одна общая проблема у конкретно этих бенчмарков - нужно строить график fps от времени хотя бы, а лучше опубликовать время рендера кадра. Это позволит сразу предметно сказать были ли микрофризы или нет (сейчас для этого приходится видео смотреть). Человек, к сожалению, довольно чувствительно воспринимает когда время рендера кадра скачет в больших пределах и у тебя, допустим, 40 FPS в среднем, но периодически есть просадки до 20 (как у них наблюдается в Counter Strike'е)
А зачем тащить то, что не находит подтверждения в реальных источниках?
Я выше приводил несколько, притом не только Crusoe, но и более быстрого Efficeon'а.
Можно взять какое-нибудь уважаемое издание типа toms hardware и посмотреть что писали там. Если не хочется читать то вывод простой - примерно половинка от равночастотного Pentium III.
Если взять то что я приносил выше - там более новые игры и бенчмарки показывают совсем грустные результаты (1/10 от равночастотного Athlon'а при прочих равных), в более старых - где-то даже 2/3 от Атлона у Efficeon'а, но чаще 1/2, а то и вовсе 1/4.
Впрочем, если у тестов от сотрудника МЦСТ такое расхождение с реальностью, это многое объясняет про Эльбрусы, так что спасибо за такую информацию. Буду теперь на этот твой ответ ссылаться, как подвернется удобный случай.
Не просто V, а чтоб rvv 1.0. Потому что у меня есть две платки с rvv 0.7.1, и толку от него ноль, если не хочется писать ассемблерные вставки и потом их выверять по спеке чтоб портировать с rvv 0.7.1 на 1.0, да и такой код в апстрим в здравом уме никто не возьмет.
Еще и с M.2. К ней осталось напечатаь корпус, подобрать радиатор какой-нибудь (чип почти не греется, но 60 градусов на нем в бенчмарках я видел, так что лучше перестрахуюсь) и будет 24/7 билд сервер для всяких нужд. А, из еще лично для меня больших плюсов - M.2 Key M - он хоть внутри и PCIe 2.0 1x, но это куда лучше для долгосрочного использования чем только microSD и USB.
Если эти подводные камни используются только в эмуляторах - их потом легко можно заменить или даже выкинуть, так как понятно что пострадает.
Собственно поддержка трансляторов часто имеет какие-то аппаратные костыли (та же история в Apple M1, та же история в китайских Loongson'ах). В этом нет ничего плохого.
Так там действительно так и случилось - в Pentium Pro появился декодер и все x86 команды декодировались в риск-подобный набор микроопераций. Но тут кроется проблема перевода - в оригиналае это micro-ops, а в русскоязычных статьях оно стало микрокодом. Вещи эти на самом деле похожие.
А если посмотреть по сторонам - то TSMC в сотрудничестве с ARM когда запускали и анонсировали 28нм ноду, показывали 3.1 ГГц ARM процессор. Никто Qualcomm'у не мешал на 28nm HPm от TSMC выпустить Snapdragon 805 с частотой 2.7 ГГц и т.п.
Поэтому я лично с большим скепсисом отношусь к подобным заявлениям, так как звучат они, перефразируя немного поговорку: плохому танцору и технологии мешают.
А это речь про немного другое - МЦСТ тянет совместимость с прошлыми версиями микроархитектуры. Потому что, строго говоря, подход VLIWов (в общепринятом определении) плох как раз тем, что поправить ошибку дизайна исполнительных блоков можно только ценой потери совместимости со всем кодом, что это поведение использовал (в некоторых случаях - со всем кодом в принципе).
Тут речь не про поддержку команд для простоты написания эмуляторов, хотя она тоже будет влиять (но обычно не сильно)
В Итаниумах аппаратная трансляция была только в первых и 2-х, в 9000-ом её убрали и заменили на софтварный IA-32 EL
По бенчмаркам он местами как Cortex-A55, местами ближе к A72, смотря в чем. У него все очень плохо с FP, нет SIMD'а никакого и в задачах, где оно используется он скорее похож на Raspberry Pi 3. Но вот в реальных применениях да, близок к 8С или даже 8СВ. Будет лучше, когда портируют более свежее ядро и смогут использовать апстримный pvr. Потому что в текущей официальной rootfs графика без какого либо ускорения, можно подкостыльнуть некоторый софт чтобы он использовал проприетарный блоб, но я лично пока использую в консольном варианте (кроме буквально одного скриншота).
Собственно было бы в плате что-то веселое - я бы написал статью, но веселым он был во времена Beagle-V Beta (а BeagleBone очень просили никому ничего не рассказывать про скорость и остальное пока не решили все переделать с нуля, что уже случилось в районе выхода первого VisionFive), а теперь оно очень сильно повзрослело.
А этот цирк не в Snapdragon'ах, а в Windows 10 (поздних ARM редакциях) и Windows 11. От процессора оно не очень зависит, кроме того что Microsoft'у эмулятор помогал сделать квалком. Так трансляция работает и по сей день, я в некоторые игры играю в Win 11 в Parallels где steam запущен через Microsoft'овский транслятор, так как в отличии от маковского он хорошо работает в том числе со странными играми.
Собственно история с судом непонятно как но заглохла примерно как и появилась.
Пока что Эльбрус - это VLIW буквально по учебникам, так что в текущий момент все общие проблемы подхода - на месте.
Являются ли они устранимыми - это уже немного зависит от того что вы готовы считать VLIW'ом. Чтобы поправить недостатки Эльбруса, придется туда докидывать нормальный предсказатель ветвлений (собственно в 16С хотели), внеочередное исполнение, городить декодер, таки применять обновляемый микрокод и так далее... Будет ли это VLIW'ом, если исчезнет явное распределение задач по блокам? От ответа на этот вопрос и зависит можно ли считать эти особенности неустранимыми и свойственными всем VLIW'ам. Да и в текущий момент МЦСТ не применили даже все трюки (опять же прошу прощения за ссылку на относительно странный сайт, но по поздним Itanium'ам на удивление сложно найти сколько-то детальную информацию), что были в поздних Itanium'ах, так что даже если вы решите считать такой процессор все равно VLIW'ом, текущие Эльбрусы подвержены всем типичным VLIWовским болячкам.
Микрокод был начиная с 8086. Внеочередное исполнение - да, появилось в Pentium Pro.
Я этот простор не вижу, причины я обозначил выше.
При той сложности портирования какая у Эльбруса присутствует - транслятор это необходимость. Плюс он хорошо закрывает дыры в особенностях VLIW которые там просто по определению присутствуют (об этом много статей на хабре, не буду повторяться).
Но МЦСТ рекламирует свое детище иным способом - пытается протолкнуть его в вершины всех реестров, чтобы у людей не было выбора кроме как покупать Эльбрусы. Ну это конечно ИМХО, основанное на том как всякие Elbrus Day проходили, на том как себя тот же Трушкин ведет в публичном пространстве, что различные сотрудники Базальта говорят с отсылкой на МЦСТ и т.п.
А тут вы натыкаетесь на особенность VLIW'ов и конкретно на её реализацию от МЦСТ - нельзя просто взять и выкинуть поддержку чего-то не сломав ISA или не сделав эмуляцию через микрокод. Собственно если покопаться и пособирать информацию, ошибки проектирования процессора тянутся с e2kv1, потому что их исправление сломает совместимость со всем уже собранным софтом. Это, к слову, еще одна причина почему VLIW не очень хороший выбор в чистом виде, в мире когда у тебя есть проприетарный софт или просто abandonware opensource невозможность менять детали реализации железа - по меньшей мере катастрофа. Собственно спросите Михаила, насколько необходима пересборка ВСЕГО софта под новые версии микроархитектуры.
Так теоретическая возможность у МЦСТ сделать транслятор для ARM - так же есть. И также, как в случае с трансметой, она нереализована и не факт что когда-либо будет.
Если ты их щупал, то какой смысл был в челлендже в твоем посте? Ты тогда должен был бы знать, что даже довольно посредственный risc-v его легко выполнит (о чем я там и написал, благо у меня есть и один из худших представителей и довольно средненький). Притом не просто легко - а просто раскатать систему и запустить браузер.
Плохие да, но не поддельные A1 - у меня пока на всей моей коллекции одноплатников ни разу не подводили (в общей сложности около 10ка, в основном Samsung Evo или SanDisk Extreme).
Не соглашусь, но, возможно, отличие рынков.
Опять же - есть еще вариант с CF карты, которые до сих пор производятся и продаются, переходник CF -> 2.5" IDE стоит дешево, а карточек которые могут давать 160МБ в секунду или больше - до сих пор полно.
В общем дело ваше конечно.