Video

> Из всех архитектур самая перспективная это е2к (Эльбрус) Я вам в соседней ветке расписал про общую проблему VLIW'ов и почему это тупик с точки зрения процессоров общего назначения. А мы там только по верхушке айзберга прошлись, даже не трогали проблему совместимости и наслоения архитектурных ошибок, которые VLIW подход взращивает. > х86 -- архаика из 70-х которая практически исчерпала все возможности для дальнейшего улучшения Это утверждение требует обоснований, потому что так говорят точно с конца 90-х, но при этом x86 живее всех живых, прекрасно развивается и наращивает производительность. > АРМ -- вендорлок с сомнительной "голой" производительностью (без спецускорителей) Откройте тесты Apple M1/M2/M3 и повторите это глядя на них. Если вы считаете, что там причиной высокой "голой" производительности являются ускорители, то расскажите какой конкретно ускоритель позволяет какому-нибудь gcc показывать такую же скорость как у Zen2 с более высокой тактовой частотой. Про вендорлок странное заявление, с учетом возможности покупки лицензии и наличия нескольких разных микроархитектур от целой кучи вендоров :) > и такими же туманными перспективами в сегменте десктопов; Опять же, расскажите об этом Apple'у. Ну или объясните Microsoft'у что ставка на Oryon это ошибка. > РИСК-Г -- то же самое, только ещё более сырое и отсталое Тоже требует обоснование. Особенно с учетом того что вы говорите про архитектуры. > Зато у Эльбрусов, при том что они даже сейчас неплохо себя показывают Я вам в соседней ветке уже показал на примере - при огромной сложности процессора (12 млрд транзисторов для 16С это не шутки) Эльбрус в среднем показывает производительность уровня Atom'а и с более мелким Zen+ не может тягаться в большинстве задач. > просто безграничное поле для дальнейшего развития И тут вы не правы по нескольким причинам. Во первых - VLIW такая прекрасная штука, где у вас то что представляется снаружи людям - это и есть внутренее представление. То есть без того чтобы сломать совместимость с прошлым софтом (что категорически не приемлимо для ниши куда МЦСТ метит, пытаясь продать эту поделку как процессор общего назначения), если конечно вы не пойдете по пути ухищерений - например сделаете декодер из VLIW-команд во внутренее представление, ну а там заодно и переупорядочивание. И у этого пути есть одна маленькая проблема - непонятно зачем вам вообще был VLIW и зачем дальше страдать с повышенной нагрузкой на подсистему памяти и кэши, которая присуща всем VLIW'ам. А, еще не забывайте об одной фундаментальной ошибке архитектуры - переменной длине команд. С учетом этого вы получите все минусы VLIW и все минусы CISC в одном флаконе при нулевом количестве уникальных преимуществ. Именно поэтому все кто ни пытался использовать VLIW - в итоге от этой идеи отказались. > Надеюсь и государство не подведёт, и найдёт для новых Эльбрусов подходящую производственную площадку. Давайте вы попробуйте без беспочвенных надежд. Если у вас есть кандидаты - покажите что они имеют шанс согласиться, иначе можем Эльбрус похоронить уже сейчас. И в целом, попробуйте не вводить людей в заблуждение и не рекламировать заведомо провальную идею упихать VLIW'а в нишу процессоров общего назначения. А если не согласны - попробуйте лучше рассказать чем Эльбрус принципиально лучше других попыток.

> потому что так говорят с конца 90-х, но х86 живее всех живых Внезапно, это же относится и к Эльбрусам 😉😄 Учитывая что в седьмом поколении появляется предсказатель ветвлений, твои страдания по поводу vliw'а абсолютно беспочвенны. Кроме того, vliw для МЦСТ не фетиш, и очевидно что со временем они будут отходить (и Трушкин прямо об этом говорит) от идеологии чистого vliw'a. А в момент появления первых микропроцессорных Эльбрусов использование подобного подхода было абсолютно оправданно, как скудным финансированием, так и областью их применения. Так что собаки лают, а караван идёт. > Эльбрус в среднем показввает производительность уровня Атома Вообще-то даже Эльбрус-8СВ на нормально написанном коде показывает производительность уровня Intel i7-9700k с частотой втрое выше, чем у Эльбруса. Если не веришь -- поищи на Хабре статью под названием "Война с компилятором и с собой".

@@user-gg7bf5rt7m > Внезапно, это же относится и к Эльбрусам А это, кстати, не совсем верно. Начнем с того, что Эльбрусы больше не производятся, с примерно февраля 2022 года. Потом, я не просто так сказал про импортозамещение - если Эльбрус не навязывать, его покупают только энтузиасты-коллекционеры. Что говорит о его потребительских свойствах лучше всего. > предсказатель ветвлений, твои страдания по поводу vliw'а абсолютно беспочвенны Предсказатель ветвлений не решает проблем архитектуры. Прочитайте мои претензии внимательнее, пожалуйста (и напомню - это лишь их часть). Эффективность архитектуры от этого не сильно возрастает, фундаментальные проблемы подхода не решаются. Я не просто так вас в конце попросил указать на уникальные решения, которые выделяют Эльбрус на фоне других попыток сделать также (Transmeta Efficeon, Itanium, NVIDIA Denver, NVIDIA Xavier, исследовательские проекты IBM). Если принципиальных отличий, которые могли бы повлиять на исход, нет, то можно сразу хоронить воспользовавшись уже известными результатами. > от идеологии чистого vliw'a Я про это тоже упомянул - Intel как раз в Itanium попытался (см. 9300 и 9500-ые), получил все минусы CISC и половину минусов VLIW. И собственно говоря это все прямые следствия свойств VLIW'а. Прочитайте внимательнее претензии. > использование подобного подхода было абсолютно оправданно Во первых, вы это повторяете, но пока даже не попытались аргументировать. Вам простой контр-аргумент - создание in-order RISC процессора возможно силами команды студентов-дипломников, а если добавить немного аспирантов, то даже не очень сложный OoO-RISC получается, который в большинстве задач будет на МГц лучше чем Эльбрус сейчас. Это доказано тем же MIT с их SonicBOOM'ом и подтверждено ETH с их исследовательскими проектами в области RISC-процессоров. Суммарно затраты у них меньше чем затраты МЦСТ. Поэтому ваше утверждение - мягко говоря спорное. > Так что собаки лают, а караван идёт. Караван давно умер, а наблюдаемая деятельность - агония. Как я уже сказал - без принуждения этот караван никому не нужен. Про последнюю часть отвечу с конца: > Если не веришь -- поищи на Хабре статью под названием "Война с компилятором и с собой". Я эту статью читал и прекрасно знаю. В комментариях отлично разобрана главная её проблема - автор решил оптимизировать код под одну платформу, а под две других просто прифигачить только высокоуровневые оптимизации без попытки анализировать их целесообразность. То есть либо автор статьи также плохо понимает что делает, либо это целенаправленный подлог (читай - вранье). Но поэтому статья и на хабре, а не в научном журнале с репутацией, в последнем случае она не прошла бы ревью. > Вообще-то даже Эльбрус-8СВ на нормально написанном коде показывает производительность уровня Intel i7-9700k Строго говоря даже после всех оптимизаций получилась производительность ниже (5.04 против 3.43). В статье нет учета времени на оптимизацию, а вы пропустили момент "в среднем". Опять же мы идем дальше по списку фундаментальных свойств VLIW и почему их не используют за пределами DSP или специализированных вычислителей - если вы заморочитесь и портатите уйму времени на ручное раскладывание кода по исполнительным устройствам, вы можете даже получить какой-то сносный результат (в случае Эльбруса еще со звездочкой - когда в вашем коде преобладают FP операции, потому что баланс ИУ там смещен в сторону FP, которая в среднем не встречается), но добиться вы этого сможете только на практически линейном коде с минимумом зависимостей. А это - довольно малый процент реального кода и реальных алгоритмов, притом даже в HPC, хотя казалось бы. И тут уже не важно - хорошо вы написали код или нет, будете ли вручную оптимизировать что-то или нет - вы получите производительность атома. > с частотой втрое выше, чем у Эльбруса. А это вообще говоря было бы важно, если бы Эльбрус был способен работать на частоте i7-9700k :) Кстати, в тесте в принципе недостаточно информации о том на чем запускался тест. Какая память, сколько её, какие конкретно настройки, почему у i7-9700k с паспортным бустом до 4.9 указана частота в 4.8 (и правда ли она была во время теста 4.8) - не рассказано почему-то. А без этого тесты нельзя перепроверить. И это еще одна причина почему это все - плохое сравнение и почему в научном журнале (уважающем себя) такой материал бы завернули (да и почему уважающие себя тестовые лаборатории такое бы не опубликовали).

> Эльбрусы не производятся Доказательства, или балабол. > Интел в итаниум пытался А VIA пыталась в x86 -- и тоже померла по сути. Как и многие другие лицензиаты х86. И что? Выходит что Интел продолжает тянуть мёртвую и неудачную архитектуру? 😄 Интел просто решил, что лицензировать у АМД х86-64 выгодней, чем тянуть две архитектуры, вот он и отказался от IA64. Тем более что для х86 уже существовала масса ПО в отличие от итаниума, чего никак нельзя сказать про Эльбрусы. Так что для Эльбрусов такой проблемы не существует, просто исходя из отсутствия альтернатив.

​@@vladimir.smirnov ​> автор решил оптимизировать код под одну платформу Странно что когда на Эльбрусах запускают код оптимизированный под х86, то тебя это почему-то не смущает. Или это другое? 😄 Но тут ты снова врёшь, так как автор той стать применял преимущественно универсальные оптимизауии, которые давали выигрыш всем участникам, только в случае с Эльбрусом этот ввигрыш был выше. > было бы важно, если бы Эльбрус мог работать на частоте 9700к Это было бы замечательно, но в данном случае не важно, т.к. преимущество широкого командного слова в том и заключается, что более низкая частота в нём возмещается более ввсоким IPC > в статье нет учёта времени на оптимизацию. Он и не нужен, т.к. написание программы с нуля что под е2к, что под х86 занимает одно и тоже время. Так же как и перекрёстная оптимизация (х86 -> е2к и е2к -> х86) уже написанного кода.

Максимум - любую. Оптимально, очень грубо говоря: FHD - не выше 4060 Ti, 6700 XT, их аналогов. QHD, UWQHD - не выше 4070S, 7800 XT, 7900 GRE, их аналогов. UHD 4K - не выше 4070 Ti S, 7900 XT, их аналогов.