RISC-V — звезда родилась: x86 не у дел, ARM сломала обе ноги / forpes.ru

Главная
RISC-V — звезда родилась: x86 не у дел, ARM сломала обе ноги

RISC-V — звезда родилась: x86 не у дел, ARM сломала обе ноги +61

09.10.2024 14:00

Barseadar 150 44000 Источник

Привет, постоянные и не очень читатели :)

Это снова я — с четвёртой статьей из цикла про архитектуры, процессоры и всё такое. Напомню, как всё было:

Part I: Скандальное разоблачение x86: ARM врывается с двух ног
Part II: Этой индустрии нужен новый герой: ARM врывается с двух ног
Part III: Китайский киднеппинг: похищение дочки
Part IV: RISC-V — звезда родилась: x86 не у дел, ARM сломала две ноги ← ВЫ ЗДЕСЬ

С тех пор утекло много всяких жидкостей: в x86 титанические сдвиги из-за провалов Intel с массовым выходом процессоров из строя (поговаривают, что Qualcomm их даже прикупить может, в такое никто бы не поверил пару лет назад); ARM — архитектура в целом — притормозила со своими гулливеровскими шагами из поколения в поколение, даже в серверном сегменте как-то всё притихло (не видать нам массовых серверов Dell или HPE с чипами на ARM как своих ушей); китайцы прихватизировали у британцев пласты IP (Intellectual property) да тихонечко свою микроэлектронику развивают под санкциями, никому не мешая.

Как видите, интересного много; для лучшего погружения в контекст стоит прочесть первые три статьи из цикла (хотя бы краем глаза взглянуть), но это на ваше усмотрение. Моя работа, в конце концов, сделать так, чтобы вы не уснули на обеденном перерыве за чашкой кофе, а потому этот лонгрид читабелен и без «сильмариллиона» за плечами.

В чём RISC: Люди Икс и предыстория

RISC-V (произносится как «риск-пять») — это открытая модульная процессорная архитектура и система команд, представленная в 2010 году. По меркам других архитектур это буквально вчера (x86 в 16-битном виде появилась на свет божий в 1978 году).

Родилась эта чудо-архитектура в лабораториях (хочется верить, подземных) Калифорнийского университета в Беркли. В основе лежит концепция RISC (Reduced Instruction Set Computing), как и у ARM. RISC-V изначально отличался от схожих проектов тем, что планировался для множества компьютерных задач, а не только для образования.

Проект масштабный, над ним работала целая группа учёных и инженеров, но главными локомотивами проекта стали два учёных (оппенгеймеры своего дела). Все знают Джобса или Гейтса, но многие великие умы неизвестны широкой публике — исправлю это недоразумение.

~~Профессор Ксавье~~ Дэвид Паттерсон — американский учёный, профессор информатики в Калифорнийском университете в Беркли, лауреат премии Тьюринга, гений, филантроп, ~~миллиардер~~. Он стоял у истоков разработки архитектуры RISC ещё в 1980-х годах, так что и за ARM можно благодарить этого человека. Паттерсон ввел сам термин RISC и сыграл ключевую роль в развитии концепций, которые легли в основу RISC-V. Капля оффтопа: он также участвовал в создании технологии RAID-массивов, без которой сложно представить современные серверы.

Крсте Асанович — учёный-инженер, доктор компьютерных наук в Беркли, соучредитель SiFive (это бесфабричная полупроводниковая компания, занимающаяся разработкой коммерческих процессоров RISC-V и IP-блоков для них). Был одним из ведущих архитекторов проекта RISC-V. Асанович и его студенты в лаборатории разработали первые спецификации RISC-V и начали активное продвижение идеи открытой архитектуры.

Отмечу ещё одного учёного-инженера — который был соруководителем проекта RISC-I, — Карло Секвина. В 1980-х годах сама идея уменьшить длину команд казалось довольно радикальной. Секвин вместе с другими инженерами Калифорнийского университета в Беркли создавал научную базу, которая и показала, что можно добиться значительного ускорения работы процессора за счёт упрощённой архитектуры набора команд.

При создании RISC-V инженеры стремились к чему-то фундаментально иному — открытой архитектуре, которую можно свободно использовать и модифицировать. Дэвид Паттерсон и Крсте Асанович выпустили технический отчёт «Наборы инструкций должны быть бесплатными: аргументы в пользу RISC-V» — название говорит само за себя.

У внимательного читателя, вероятно, появится вопрос: окей, RISC-V, а что там с первыми 4 версиями? 5 скорее указывает не на версию, а на историческую преемственность и улучшение предыдущих наработок архитектуры-прародительницы RISC и других схожих технологий.

Berkeley RISC (1980-1984 г.): первая версия архитектуры, разработанная в Беркли под руководством Дэвида Паттерсона и его команды. В итоге появился экспериментальный процессор RISC-I (44 420 транзисторов) с упрощённым набором команд (32 инструкции), который смог доказать эффективность концепции RISC по сравнению с традиционными архитектурами CISC. Через пару лет появился RISC-II (40 760 транзисторов) — это улучшенная версия процессора RISC-I с увеличенным набором команд (39) и примерно в 3 раза большей производительностью, чем у RISC-I.

Проект показал, что простая архитектура может быть функциональной и эффективной. Для достоверности отмечу, что ещё до появления названия RISC уже были устройства, которые можно отнести к этой концепции: CDC 6600, Data General Nova, семейство процессоров IBM 801. Но именно проект Berkeley RISC дал название архитектуре. Проект позже коммерциализировала Sun Microsystems — так появился SPARC; также RISC вдохновил на создание архитектуры ARM.

RISCовые парни и просто отличные инженеры: Джим Пик, Корбин Ван Дайк, Цви Пешкесс, Дэн Фицпатрик, Джон Фодераро.

Stanford MIPS: работа над этой архитектурой в исследовательских целях велась параллельно в Стэнфорде с 1981 года по 1984 год под руководством Джона Хеннесси. Что-то вроде ответа на RISC и IBM 801. Эта работа стала фундаментом для компании MIPS Computer Systems и коммерческих процессоров семейства MIPS, которые широко использовались в индустрии (например, микропроцессор R2000): встраиваемые компьютеры, ПК, рабочие станции, серверы и суперкомпьютеры.
SPARC: Архитектура SPARC (Scalable Processor Architecture) была разработана компанией Sun Microsystems на основе концепций RISC в конце 1980-х годов. SPARC широко применялся в рабочих станциях и серверных системах.

RISC-V уже на этапе концепции задумывался как нечто, способное перевернуть рынок микроэлектроники вверх ногами. Подчеркну, может, но не обязательно сделает это: одной лишь хорошей технологии/идеи недостаточно для ~~доминирования~~ выживания на рынке, иначе бы Windows Phone бесславно не погибла. При этом RISC-V — не концепция, она доказала свою жизнеспособность в реальных продуктах. Но об этом позже.

Открытость, модульность и кастомизация — три крепко связанных столпа RISC-V, которые недоступны корпоративным мастодонтам, вроде ARM Ltd., Intel и AMD.

Первое — открытость

Полная спецификация RISC-V доступна всем желающим. Эта архитектура не связана лицензиями, патентами и прочей капиталистически-позолоченной мишурой. Если Стив Возняк и загадывал у Санты что-то на Рождество, то именно такой подход в микроэлектронике. Любая компания — от стартапа до некогда циклопической IBM — может использовать RISC-V за 0 шекелей. И это хорошо. Но что ещё есть в рукавах у RISC-V?

Модульность и кастомизация

Модульность RISC-V наглядно показывается в начале фильма Дэдпул и Росомаха.

Базовый набор инструкций RISC-V — он же ISA, минимальный набор команд, который поддерживается всеми процессорами на основе RISC-V — можно дополнить стандартными или кастомным расширениями. Это позволяет создавать специализированные процессоры для конкретных задач, не нарушая совместимости с другими процессорами.

Ремарка! Архитектура RISC-V включает в себя небольшое обязательное для выполнения подмножество команд (набор инструкций I — Integer) и несколько стандартных опциональных расширений.

Базовый набор поддерживает все стандартные операции: арифметические/битовые регистровые вычисления, управление памятью (load/store), операции ввода-вывода и синхронизацию многозадачных процессов. Вендоры могут добавлять или убирать функциональные блоки/модули для обработки графики, работы с БД или ИИ, минимизируя ненужные инструкции и легаси хвост. Их можно создавать с нуля; можно брать открытые бесплатные решения; можно лицензировать чьи-то проприетарные решения. Это крайне эффективный и гибкий подход.

Для примера приведу Rocket Chip (здесь про него подробно) — это фреймворк для проектирования систем на кристалле (SoC) с открытым исходным кодом, разработанный командой в Беркли на базе RISC-V. По сути это настраиваемый и гибкий фундамент (платформа) для проектирования и создания высокопроизводительных процессоров. Включает в себя базовые ядра RISC-V, поддерживающие кэширование, многопоточность и даже расширенные инструкции для работы с нейросетями.

Где место под солнцем RISC-V

HiFive Unleashed от SiFive — плата для разработки с поддержкой Linux и со встроенным SoC Freedom U540 (FU540), первым в мире многоядерным процессором RISC-V.

Вы наверняка слышали про концепцию ASIC (Application-Specific Integrated Circuit, интегральная микросхема для конкретного применения). В наше время ASIC-устройства обычно используют под одну задачу, например, майнинг криптовалют или обработку пакетов данных, минуя CPU.

Первые ASIC появились в далёкие 1970-е годы, компании разрабатывали интегральные схемы для конкретных задач — большие объёмы вычислений, где простота и скорость важнее универсальности; да, это сильно ограничивало функционал, но стоили они дешевле в пересчёте на производительность в конкретных вычислениях: математические операции, управление процессами, фильтрация сигналов и декодирование информации.

В общем, ASIC — технологии предтеч.

Расцвет ASIC пришелся на 1980-е — времена Майкла Джексона, Звёздных войн (тех самых, трушных); зачатков интернета в виде ARPANET, первых мобильных телефонов в чемоданчиках. ASIC прижился в телекоммуникациях, компьютерных системах и промышленной автоматизации.

В нелихие 1990-е (в Штатах то бишь) технологию оптимизировали и удешевили благодаря EDA-инструментам (автоматизация проектирования), а уже в нулевых начался самый сок. Вернее SoC (System-on-a-Chip, SoC) — система на одном кристалле. При проектировании в одном чипе научились размещать несколько функциональных блоков: вычислительные ядра (прикладной процессор общего назначения), память, интерфейсы I/O и прочие компоненты, что не только удешевляет производство, но и сокращает энергопотребление. По сей день SoC — это стандарт в индустрии. Все современные ASIC стали SoC, а все SoC по своей сути ASIC со вспомогательными блоками. ASIC — как отдельные устройства — продолжают использовать в ИИ, 5G, автономных системах, криптомайнинге и т.д.

Apple's Neural Engine (ANE, нейронный движок от Apple). По сути специализированные ядра, aka ASIC-блоки в составе SoC.

Но причём тут RISС-V?

На рынке доминируют x86 и ARM. У первой монополия в настольных и серверных системах (доля ARM незначительна) и легаси хвост размером с Якутию; у второй монополия в мобильных и встроенных системах, а также строгое лицензирование и стандартизация для совместимости (ANE прикрутить можно, но значительная часть должна быть такой, какой её разработала компания ARM Ltd.).

RISС-V выигрывает по многим параметрам: нет гигантского легаси-хвоста; нет строгой стандартизации ядер, как в ARM (но это же и проблема для оптимизации); порог входа для потенциального вендора значительно ниже, чем в x86 (никого, кроме Intel и AMD, по существу и нет); лицензирование блоков от сторонних разработчиков по желанию; простота разработки новых микроконтроллеров или процессоров.

Особенно выигрышно RISС-V смотрится в узкоспециализированных решениях: ASIC, SoC с блоками для решения конкретных задач, микроконтроллерах / MCU (MCU в контексте SoC означает включение блока микроконтроллера в более крупный дизайн интегральной схемы), IoT (Internet of Things, интернет вещей).

Серверный чип Google Titan (слева) и чип безопасности Titan M первого поколения (справа)

Крупные игроки, вроде Alibaba и Google, уже включились в развитие архитектуры. Google, к слову, создаёт проприетарные ключи безопасности Titan для облачных сервисов и устройств, внутри которых криптопроцессор на RISC-V. Также у них есть Titan M2 для смартфонов Pixel на RISC-V — это отдельный чип (SoC-ASIC), который не использует ресурсы основного процессора. Что-то вроде модуля TPM (Trusted Platform Module) в материнских платах (штука, которая требуется для установки Windows 11, тоже про безопасность).

И особенно важно, что Google планирует сделать RISC-V архитектурой «tier-1» для Android. А это уже серьезная заявка.

RISC повсюду

RISC-V создаёт уникальные условия для развития: открытость, гибкость и адаптируемость на аппаратном уровне, независимость от политики, санкций и т.п. С санкциями уточню: так как RISC-V открыта, международное комьюнити крайне важно; прямые санкции невозможны, но можно объявить страну (или любой НИИ) нерукопожатной — и никто из светлых демократий не рискнёт начать совместные проекты или продавать лицензии на свои IP. Штаты вставляют палки в колёса Китаю и будут вставлять всем остальным, кому пожелают. В России уже создали свою ассоциацию «Альянс RISC-V».

Конгломераты и корпорации, которые могут позволить себе исследования и разработку, а также заказать производство более-менее крупной партии чипов на TSMC или же на фабрике с устаревшим техпроцессом (далеко не везде нужны 3-нанометровые чипы), разрабатывают собственные кастомные решения на базе RISC-V — так и контроля больше (никаких тебе аппаратных закладок в безопасности) и свобода от лицензирования. Хотя на практике разработка сложного SoC на RISC-V с нуля не имеет смысла для большинства компаний — есть готовые открытые или платные IP (Intellectual Property) «кубики», этакие модули, которые можно взять бесплатно или лицензировать и использовать для своей системы на кристалле: блоки обработки данных, интерфейсы, контроллеры памяти и другие компоненты, которые разработчики интегрируют в свои SoC, вместо того чтобы разрабатывать их с нуля.

Примеры продуктов на RISC-V

Qualcomm и их микроконтроллеры; Alibaba и их процессоры XuanTi; SiFive и их 64-битные многоядерные чипы (даже Linux-дистрибутивы работают); DeepComputing продает ноутбук DC-ROMA Laptop II, планшет DC-ROMA Pad II для нативной разработки и другие продукты. Semidynamics представила первый в мире полностью когерентный тензорный блок RISC-V.

DC-ROMA Laptop II. Ага, уже вторая версия.

К тому же не стоит забывать про независимых разработчиков и исследовательские институты, которые активно используют RISC-V в образовании и исследованиях. RISC-V позволяет инженерам и программистам разрабатывать чипы без бюрократических ограничений. А значит будет приток новых идей и необычных решений, которые трудно реализовать в закрытых системах.

Единичные поставки RISC-V SoC. По прогнозам, объем поставок SoC на базе RISC-V вырастет до 16,2 млрд единиц, а доходы достигнут 92 млрд долларов к 2030 году, при этом годовые темпы роста составят 44% и 47% соответственно. Отчёт можно скачать здесь. — Единичные поставки RISC-V SoC. По прогнозам, объем поставок SoC на базе RISC-V вырастет до 16,2 млрд единиц, а доходы достигнут 92 млрд долларов к 2030 году, при этом годовые темпы роста составят 44% и 47% соответственно. Отчёт можно *скачать здесь*.

Разумеется, RISC-V рассматривается как технология для космических программ и военных систем: европейское космическое агентство (ESA) изучает — а может уже и использует — эту архитектуру для создания процессоров в космических устройствах. Открытость RISC-V позволяет избежать тотальной зависимости от американских/английских технологий, что вроде как критично в условиях возможных санкций или геополитических ограничений (оставлю комментарии при себе, но видимо, даже у европейцев где-то есть план Б или план последней буквы английского алфавита). Россия, к слову, тоже инвестирует в потенциал RISС-V, хотя у нас и свой Эльбрус есть.

Китай активно развивает RISC-V в своих проектах, в том числе в области космической техники — тут вопросов нет. В США разрабатывают решения на базе RISC-V для военной электроники и автономных систем. Тоже ничего удивительного.

Если подытожить, то RISC-V развивается вширь и вглубь, тогда как x86 поплохело (надеюсь, Intel справится с проблемами, нам нужна конкуренция), а ARM сбавил обороты. На RISC-V уже есть реальные продукты, да, нишевые, но потенциала достаточно для ПК, игровых консолей, смартфонов, серверов и т.п.

Не выводы, но проблемы

Видится мне кипа заградительных стен для RISC-V. Если передовые разработки будут в области военной и космической промышленности (а так и бывает, как правило), то никто ими делиться не будет — даже спустя годы. Если условный Китай или Россия под санкциями будет создавать передовые RISC-V чипы, то зачем делиться лицензией на блоки с «недружественными» странами? Если корпорация, вроде Apple, разработает эквивалент своих M-чипов на RISC-V, то ни Google, ни Samsung, ни Microsoft, ни кто-либо другой никогда их не увидит (справедливости ради, нынешних A и M-чипов на ARM тоже нет ни у кого, только чипы-конкуренты от Qualcomm и MediaTek).

Фрагментация будет значительной (это одновременно вызов для совместимости, но и гибкость при создании специализированных решений, вроде ASIC) + сложности с кибербезом, но это необязательно плохо, в массовые продукты всё равно пойдут проприетарные блоки-доработки от корпораций, которые как были, так и будут их IP; туда же пойдут только чипы, совместимые с распространёнными пользовательскими и серверными ОС. Зато у корпораций не будет полной монополии на всё; появятся стартапы и небольшие компании, которые без собственных продуктов и производств будут создавать отличные модули для RISC-V процессоров.

А как итог — максимальная свобода. Хочешь, создавай своё с 0; хочешь, бери что-то из открытых вариантов; не устраивает — делай гибрид или лицензируй блоки у сторонних компаний. Порог входа станет проще, влияние политики меньше, новых идей будет больше. Если сейчас сложно представить появление третьей стороны в мире x86, то в RISC-V такое будет возможно даже при одном всемирном гегемоне.

RISC-V — это не просто технологическая альтернатива диктату x86 и ARM Ltd. Это новая философия проектирования процессоров: открытость, адаптивность и снижение затрат на разработку. Этакий конструктор для каждого, Open Source в мире микроэлектроники, если угодно.

Осталось дело за малым — целостная экосистема, полноценная поддержка современных ОС и совместимость с существующим популярным ПО. Эффективные эмуляторы, по типу Rosetta, подойдут на начальном (хочется верить, переходном) этапе, но нативная поддержка будет эффективнее.

И у RISC-V есть всё, чтобы конкурировать с x86 и ARM даже в массовом сегменте.

Комментарии (150)

checkpoint
09.10.2024 21:24
#27398518
Как апологет движения open source, open hardware и RISC-V в частности, вставлю свои незамысловатые пять копеек.
1. Открытая и расширяемая система команд это очень замечательно. Еще более замечательно если эта система команд является хорошо выверенно, лишенной атавизмов и избыточности (ортогональной), нацеленной на решение современных задачи, как-то векторные, матричные и нейро вычисления. Но! Какой бы эффективной ни была система команд микропроцессора, это всего лишь 5% (если не меньше) в его производительности. Гигантский пласт решений, которые делают современные микропроцессоры от AMD и Intel столь непревзойденно эффективными, скрывается в микроархитектуре - в тех самых многоуровневых схемах из вентилей и триггеров которые реализуют систему комманд в виде супескалярных OoO конвейеров, высокопроизводительных кэшей, интерконнекта и т.д. И почти все эти микроархитектурные решения являются глубоко проприетарными: закрытыми лиценциями, защищенными авторским правом и NDA, и часто просто являются коммерческой тайной не подлежащей передаче кому либо. Получается, что молодым микропроцессорным компаниям почти закрыт путь к созданию высокоэффективных вычислительных ядер, так как ни Intel, ни AMD, ни ARM, ни IBM и ни Apple не ходят лицензировать свои микроархитектурные решения дабы не плодить конкуренцию (ARM делает это но за огромные деньги и с условием применять только их ISA). Путь у таких компаний один - создавать свои микроархитектурные решения, а это катастрофически сложно, долго, с большим количеством проб и ошибок и, как следствие, является финансово неподьемным. А еще в этом деле можно легко нарваться на судебные тяжбы с тем же Intel-ом или IBM за случайное повторение уже запатентованных решений. Именно поэтому мы сейчас не видим на рынке высокоэффектиных вычислительных ядер на базе RISC-V, и, скорее всего, еще не скоро их увидим.
2. Нет никаких технических препятствий для того, чтобы реализовать высокопроизводительный микроппроцессор с микроархитектурой типа Skylake, Alder Lake или Zen 5, но с программным интерфейсом (т.е. системой команд) RISC-V. Однакож ни Intel, ни AMD не проявили ни малейшего интереса в этом направлении. Почему ? Да потому, что выпустив такой микропроцессор они вскроют ящик пандоры. Сейчас очень удобно, через разного рода эксперов, потихонечку поливать RISC-V всякими субстанциями, ведя рассказы в духе "RISC-V еще сырая, еще молодая, вот пусть окрепнет... а вот x86 и arm - надежный старый конь". Но действительность такова, что никто из топовых производителей микропроцессоров не желает выпускать такие продукты, для них это страшный сон. Но есть надежда. Надежда на то, что у Intel-а дела не пойдут, а покатятся вниз по касательной и тогда они будут вынужены пойти на радикальный шаг дабы вдохнуть новую жизнь в свою продукцию, и может быть тогда нас ждет новая эра.
3. В RISC-V International страшно увлеклись расширениями. Этих расширений уже наплодили столько, что если выпустить микропроцессор поддерживающий хотя бы половину этих расширений, то число поддеживаемых им инструкций превысит самый топовый камень от Intel со всеми его архаизмами. И это еще не всё. Заложенная в RISC-V возможность кастомизации приводит к тому, что начали появляться микропроцессоры с системой команд с "вариацией на тему". Всё это не прибавляет универсальности и совместимости. Я просто уверен, что вместо одной единой системы команд, мы придем к нескольким десяткам вариантов полность или частично несовместимых между собой вариантов RISC-V. Маслица в огонь подольют (и уже подливают) национальные варианции. И несмотря на наличие компиляторов и решений автоматизирующих перенос кода с одной системы команд на другую, жизнь программистов станет сущим адом. Короче, нас ждет балканизация системы команд микропроцессоров.
1. Armmaster
  09.10.2024 21:24
  #27398678
  Однако ж ни Intel, ни AMD не проявили ни малейшего интереса в этом направлении. Почему ?
  
  Потому что для этих компаний наличие огромной программной экосистемы x86 и монополия на эту архитектуру является колоссальным конкурентным преимуществом. Поэтому для Intel/Amd нет никакого смысла делать RISC-V чипы в тех сегментах, где они доминируют.
  1. checkpoint
    09.10.2024 21:24
    #27398714
    Именно так. Как только Intel выпустит высокопроизводительный проц с RISC-V архитектуруй, тут же настанет конец x86 и её монопольному положению на рынке, а этого в Intel позволить сейчас не могут. Но может случитсья так, что накал страстей всё развернет на 180 градусов.
    
    unreal_undead2
    09.10.2024 21:24
    #27399544
    И всё легаси моментально переедет на RISC V? x86 - странная и ужасная архитектура, но поддержка работы старых бинарников - однозначный плюс.
    
    fen-sei
    09.10.2024 21:24
    #27400270
    Помнится Itanium64 не взлетел из-за отказа от x86, а AMD64 взлетел благодаря поддержке x86.
    
    Так что RISC V - это для Andriod и Apple.
    
    khajiit
    09.10.2024 21:24
    #27400498
    А так же для Linux, BSD — одним словом, для систем, где не трясутся над бинарной совместимостью, потому что или исходники открыты и можно легко пересобрать, или достаточно воли чтобы продвинуть решение.
    
    unreal_undead2
    09.10.2024 21:24
    #27400606
    Ну пересоберите PHP 8 с поддержкой JIT на RISC V )
    
    khajiit
    09.10.2024 21:24
    #27400662
    Как напишут JIT на RISC V для PHP 8 — так сразу =)
    
    unreal_undead2
    09.10.2024 21:24
    #27400740
    Так это написание JIT и входит в данном случае в портирование на новую архитектуру. Как и, скажем, для Java или Chromium (там вроде поддержка RISC V есть, но возможно качество генерируемого кода ещё тюнить придётся).
    
    Goron_Dekar
    09.10.2024 21:24
    #27401356
    Но уж точно не входит в "поддержку работы старых бинарников"
    
    unreal_undead2
    09.10.2024 21:24
    #27401384
    Собственно, эта "поддержка работы старых бинарников" автоматически позволяет пользоваться тем же JIT на новых процессорах Intel/AMD.
    
    khajiit
    09.10.2024 21:24
    #27401452
    POPCNT последнее время сломала много копий
    
    unreal_undead2
    09.10.2024 21:24
    #27401474
    Расширения - отдельная тема, и для RISC V ещё более актуальная. У Интела по крайней мере есть обратная совместимость, а на RISC V в принципе возможны все 2^N вариантов для N расширений.
    
    checkpoint
    09.10.2024 21:24
    #27401666
    Нет, не позволяет. Интел уделяет монументальное количество времени и средств на адаптацию библиотек к своим постоянно меняющимся процессорам, выжимая максимум из новых инструкций и обеспечивая эту самую "бинарную совместимость" на уровне библиотек. Всё это скрыто под капотом и обычно пользователю не заметно. Так же срыто от пользователя и то, что огромный пласт проблем совместимости решается на уровне операционной системы (новая Винда всегда выходит чуть раньше нового интеллового проца и это не просто так). Но если Вы возмёте какой-то старый софт (10-15 летней давности), старую ОС и попытаетесь запускать всё это на новых процах, то в лучшем случае Вас ждет очень посредственная производительность, а в большинстве случаев Вы столкнетесь с массой проблем с запуском ПО и его стабильной работой.
    
    unreal_undead2
    09.10.2024 21:24
    #27401700
    и обеспечивая эту самую "бинарную совместимость" на уровне библиотек.
    
    Можно конкретный пример отсутствия обратной совместимости на уровне инструкций процессора?
    
    checkpoint
    09.10.2024 21:24
    #27401980
    Попробуйте установить Windows XP на современный интелловый проц. Вы столкнетесь с огроменным количеством проблем совместимости, в том числе и на уровне системы команд.
    
    Мне как-то попадалась статья одного хакера которому это удалось, но ему пришлось надергать кусочков из Windows 10, в итоге получился гибрид ежа и ужа.
    
    Armitage
    09.10.2024 21:24
    #27402268
    на 8-9 поколение вполне можно хоть NT4 установить, а это в общем вполне еще бодрые процессоры
    
    unreal_undead2
    09.10.2024 21:24
    #27403712
    Конкретную проблемную команду процессора всё таки назовите. Проблемы с совместимостью будут в основном из за обвязки - чипсет, BIOS (который теперь UEFI) и т.п.
    
    checkpoint
    09.10.2024 21:24
    #27406420
    Я попытаюсь найти эту статью и дам Вам на изучение, там проблемы по всем направлениям. И да, современный микропроцессор это не только система команд. Даже если Intel и поддерживает все древние инструкции, за последние 10 лет они навводили столько всякого говна в свои микропроыессоры, что запустить на них старый софт просто невозможно.
    
    khajiit
    09.10.2024 21:24
    #27401472
    Гугл сходу выдает LLVM KaleidoscopeJIT. Так что, возможно, это просто вопрос интеграции инструмента vs костылесипединга
    
    unreal_undead2
    09.10.2024 21:24
    #27401522
    LLVM плохо применим к динамическим языкам (иначе бы и в браузерах, и в PHP движках давно сидели бы на нём). В Java теоретически запользовать можно, но там много усилий потрачено на дополнительную оптимизацию по результатам профилировки непосредственно в процессе исполнения и переехать на LLVM с их сохранением несколько нетривиально.
    
    khajiit
    09.10.2024 21:24
    #27404784
    То есть, опять вопрос не принципиальный, а наличия инструмента, который вопрос политик развития.
    
    K0styan
    09.10.2024 21:24
    #27400686
    Это было 20+ лет назад. Тогда тоже были альтернативные платформы - MIPS, Sparc - но сборка ПО под них была сильно опциональной. Сейчас даже какие-то пользовательские утилиты и под x86, и под ARM пилят.
    
    checkpoint
    09.10.2024 21:24
    #27401614
    Мир бинарной совместимости потихоньку уходит в прошлое. Опенсорс и компиляция по месту (JIT) приходит на смену. Если Интел или AMD продолжать цепляться за бинарную совместимость, то они рискуют в один момент остаться за бортом.
    
    unreal_undead2
    09.10.2024 21:24
    #27401654
    И какие AAA игрушки нынче распространяются в исходниках или JIT компилируются? На серверах - да, в основном open source и JIT (хотя, скажем, SAP или Oracle пока не умерли), но JIT движок под новую платформу сам собой не появится и не всегда можно просто запользовать LLVM. Так что в принципе смена архитектуры сейчас действительно реальна, но требует определённых усилий. При этом ARM в плане внедрения в десктопы и суровый энтерпрайз уже заметно продвинулся, у RISC V ещё всё впереди.
    
    checkpoint
    09.10.2024 21:24
    #27401946
    у RISC V ещё всё впереди.
    
    Тут есть интересный нюанс: ARM, протаптывая дорогу к портабельному софту, делает это в том числе и для RISC-V - разработчики учатся писать совместимый софт, появился принципиально новый портабельный компилятор (LLVM) и все это идет в общую копилку. Никзкоуровневая аппаратная зависимость давно уже стала уделом разработчиков компиляторов и операционых систем, а весь пользовательский софт давно портабелен (за исключением некоторых клинических случаев) и независим не только от ISA, но и от операционных систем. Это касается как оперсор, так и проприетарного коммерческого софта.
    
    OpenA
    09.10.2024 21:24
    #27402378
    ARM, протаптывая дорогу к портабельному софту, делает это в том числе и для RISC-V
    
    Нет, арм продирается сквозь кусты вслед за интел, и все больше подражает последнему что бы было легче.
    
    unreal_undead2
    09.10.2024 21:24
    #27403724
    разработчики учатся писать совместимый софт
    
    С оптимизациями по NEON и SVE ) Возможно, искажённая картина мира, но вижу, как вокруг оптимизируют прикладной софт на интринсиках, а то и с самописным JITом. Переносимая векторизация - пока ещё скорее светлое будущее, хотя подвижки в эту сторону есть.
    
    agalakhov
    09.10.2024 21:24
    #27401968
    AAA игрушки внутри очень портабельны, выпуск под еще одну платформу - это установка еще одной галочки в настройках проекта и все. Так что никого они на x86 не удержат. Их перевыпустят сразу и все. Особенно сейчас, когда там все интересное все равно делается на SPIR.
    x86 держится не на игрушках, а на большом количестве узкоспециализированных приложений, которые поддерживаются кое-как и которые некому портировать. Местами там даже на Delphi есть. Самый ад - в софте для всяких узкоспециализированных железок. Тот же "умный дом" на KNX настраивается строго одной софтиной от строго одного вендора, работающей строго под виндой, требующей аппаратный ключ в USB и с жутким legacy внутри. С учетом того, что я видел, кто и как ее пишет, быстро ее никуда и ни на что не портируют. Ее даже просто другим компилятором под ту же винду пересобрать не получится.
    
    MK_Ultra
    09.10.2024 21:24
    #27401408
    Это именно то, что случилось когда интел выпустил итаниум. настал конец их монопольному положению, хорошо что тогда они это могли себе позволить.
1. rPman
  09.10.2024 21:24
  #27399500
  Программный интерфейс это случайно не аналог fpga в центре процессора?
1. molnij
  09.10.2024 21:24
  #27399672
  Однакож ни Intel, ни AMD не проявили ни малейшего интереса в этом направлении. Почему?
  
  А почему они должны это делать? Вот честно, пытался прикинуть и ни одной заметной причины не смог придумать. Сюрприз, но AMD и Intel это коммерческие компании и они делают продукт не для удовлетворения любопытства, а для продажи (кто знает, может в рамках R&D у них в лабораториях и есть образцы, но мы же про массовый продукт?). Кто будет массовым покупателем для этих процессоров - я даже придумать не могу. Домашний сегмент - сразу мимо, серверный - у интела уже был опыт с потрясающе эффективными итаниумами. Не представляю, как можно будет продавить эту авантюру еще раз. Тот же ARM в серверах вроде понемножку что-то делает, но никакого взрывного роста не наблюдается, а значит вопрос энергоэффективности не так уж и остр по сравнению с другими (а они есть). Офисники.. Ну посмотрим опять же на пример Qualcomm попытавшегося влезть на полянку ноутбуков, но чисто имхо, пока тоже не вглядит прорывным продуктом. Я про него после выпуска и тестов первых дней вообще ничего не слышу в общем поле.
  
  Ну и глобально, зачем пытаться делать конкурента своим же продуктам - решительно неясно. Риски, даже очевидные, заметны сразу, а преимущества, мягко говоря неочевидны, особенно в обозримой перспективе.
  1. vvzvlad
    09.10.2024 21:24
    #27403242
    Например, потом что они уже просрали огромнейший мобильный рынок? И ровно те же подвижки сейчас происходят с рынком ноутбуков? Потому что несмотря на жирные арм с тпд под 200вт в серверах, энергоэффективность на ватт у арм лучше, а в носимых устройствах это имеет значение.

AVKinc
09.10.2024 21:24
#27398610
Так то RISC это не малое количество инструкций, вон тот же AVR вполне себе RISC, а там инструкций больше сотни. Это процессор с простыми инструкциями. Ну и большое число РОН очевидно.
1. checkpoint
  09.10.2024 21:24
  #27398754
  Если не ошибаюсь, то сам Паттерсон и ввел такое понятие как "ортогональная система команд". Это такой набор команд, который не содержит избыточности в рамках какого-то класса задач. С точки зрения разработчиков AVR, их система команд содержит минимально достаточной набор команд для своего класса.
  
  Проблема в том, что решаемые классы задач постояно меняются. С появлением "мультимедия" набор инструкций резко стал разбухать: сначала векторыми 128, потом 256 и 512, а теперь вот матричными и всякой нейрохренью. На мой взгляд все эти специфические инструкции нужно вынести из системы команд процессора общего назначения и имплементировать их в виде отдельной аппаратуры через стандартные периферийные интерфейсы (либо на всё том же кристалле, для быстроты, либо на отдельном). Зачем весь этот багаж интегрируют прямо в систему команд мне не понятно. Ведь эти специфические инструкции используются оганиченным числом приложений и, по сути, висят они там без дела. В то же время они создают массу проблем для операционной системы, увеличивают площадь и сложность декодера, и уменьшают пропускную способность конвейера (ограничивают предел тактовой частоты). Выкинуть их нафиг, оставить только RV64GC и на этом успокоиться. Кому надо - пусть делают ядра ускорителей в духе Nvidia или AMDGPU. Это позволило бы существенно поднять тактовую частоту и увеличить число ядер на кристалле, что для большинства задач является более важным, чем считать нейронки и 3D графику.
  1. khajiit
    09.10.2024 21:24
    #27400514
    Не путайте апи к некоему черному ящику и инструкции, позволяющие этот ящик реализовать.
    Необходимы оба.
  1. ahdenchik
    09.10.2024 21:24
    #27406872
    На мой взгляд все эти специфические инструкции нужно вынести из системы команд процессора общего назначения и имплементировать их в виде отдельной аппаратуры через стандартные периферийные интерфейсы (либо на всё том же кристалле, для быстроты, либо на отдельном).
    
    В RISC-V именно так и предлагается делать
    
    checkpoint
    09.10.2024 21:24
    #27407016
    Кем предлагается ? Пока что я вижу как пухнет система команд от всё новых и новых расширений. Не то, чтобы они плохие или бесполезные, просто совать их в систему команд процессора не следовало бы. И я не смог найти внятного обьяснения почему консорциум RISC-V International выбрал именно такой подход.
1. event1
  09.10.2024 21:24
  #27401678
  RISC = Reduced Instruction Set Architecture. Изначальная идея была именно в уменьшении и упрощении системы команд и, за счёт этого, упрощении компилятора. Именно, упомянутые в статье граждане первые додумались, что пользователь пользуется не процессором, а программно-аппаратным комплексом. И успешно улучшили весь комплекс за счёт упрощения системы команд.
  
  Но, по скольку, с одной стороны, в интеле тоже не дураки сидят (сидели, во всяком случае), а с другой, нужны определённые фичи, то со временем по количеству команд (и по многим другим показателям) произошла конвергенция. И сегодня количество команд armv8 и x86_64 примерно совпадает.
  1. unreal_undead2
    09.10.2024 21:24
    #27401724
    Изначально идея была в том, чтобы убрать микрокод как класс и через ISA дать прямой интерфейс к возможностям процессора без этой прослойки. Усложнение ISA из-за дополнительной функциональности в ALU и прочих юнитах процессора идее RISC не противоречит.
    
    torgeek
    09.10.2024 21:24
    #27404434
    Если уж на то пошло, то граница идёт по системе команд процессора, которая видна программистам.
    
    А микрокод там внутри на декодере вычислительного ядра или аппаратная реализация команд — это дело архитектуры кремния. Туда только разработчиков процессора допускают. И снаружи никакой разницы нет.
    
    Идея скорее в обратном, в повышении сложности и удобства в командах отдавать на уровень промежуточных языков, виртуальных машин и компиляторов. А процессору отдавать максимально удобный машкод для проектирования максимального аппаратного перфа. Это я пересказывают вводные по риск5 от Паттерсона :)
    
    unreal_undead2
    09.10.2024 21:24
    #27404460
    Это я пересказывают вводные по риск5 от Паттерсона :)
    
    А оригинальную статью 1980го года про RISC читали?
    
    checkpoint
    09.10.2024 21:24
    #27407030
    У меня есть пара книг за его авторством, в том числе сборник статей "Электроника СБИС. Проектирование микроструктур" от 1989г, Мир. И из их прочтения у меня сложилось обратное представлени - Паттерсон в молодости поработав на запуске мэйнфреймов четко решил избавляться от микрокода. :)
  1. khajiit
    09.10.2024 21:24
    #27404826
    Только, надо дополнить, не Reduced Instruction Set, а (Reduced Instruction) Set
    Не урезанный набор инструкций, а набор упрощенных инструкций, что естественным образом приводит к упрощению и уменьшению самого набора, но при этом никак не мешает расширять его.
    Так же и CISC — это набор сложных инструкций (выполняющих сразу комплекс операций под капотом).
    То у многих, почему-то, происходит фиксация на Instruction Set как на неделимой сучности.
    
    event1
    09.10.2024 21:24
    #27404860
    В Стендфорде, где это всё придумали, с вами не согласны
    
    RISC, or Reduced Instruction Set Computer. is a type of microprocessor architecture that utilizes a small, highly-optimized set of instructions, rather than a more specialized set of instructions often found in other types of architectures.
    
    Да и в самой статье упоминается первый риск:
    
    В итоге появился экспериментальный процессор RISC-I (44 420 транзисторов) с упрощённым набором команд (32 инструкции)
    
    khajiit
    09.10.2024 21:24
    #27404868
    что естественным образом приводит к упрощению и уменьшению самого набора
    
    Кто с чем несогласен?
    Наоборот, прямое подтверждение.
    
    event1
    09.10.2024 21:24
    #27404964
    Вы утверждаете что Reduced в RISC относится к Instruction, а не к Set. То есть по-вашему, по-русски правильно, "набор упрощённых инструкций". Тогда как из вышеприведённых цитат очевидно, что верно традиционное понимание: "упрощённый набор инструкций"
    
    khajiit
    09.10.2024 21:24
    #27405030
    из вышеприведённых цитат очевидно
    
    прямое калькирование и отсутствие семантической группировки вообще.
    Не говоря уже о том, что приводить особенности устоявшегося перевода в качестве аргумента столь же верно, сколь называть взаимодействие с GUI — ксерить.
    
    Речь о причинноследственной связи. И то утверждение можно фальсифицировать.

Alcpp
09.10.2024 21:24
#27398642
"ARM сломала обе ноги" Я так и не нашел пояснения этого в тексте.
1. Titsubishi
  09.10.2024 21:24
  #27398674
  Arm сильно зависит от тех процесса. Она не сломала ноги, но уже уперлась в потолок - дальнейшее увеличение её потенциала сильно зависит от уменьшения тех процесса, либо увеличения площади кристалла + все это дело нуждается в хорошем охлаждении. Вот собственно потому и в телефонах частоты камней едва превышают 2 ГГц. Боюсь, рассказы про эффективные плоские испарительные камеры в очень плоских гаджетах, без активного охлаждения - не более чем маркетинговый ход.
  1. OrkBiotechnologist
    09.10.2024 21:24
    #27398968
    Вот собственно потому и в телефонах частоты камней едва превышают 2 ГГц.
    
    Но в серверных решениях на ARM подобного ограничения нету, в силу наличия нормальной, активной системы охлаждения.
    Да и засимость от уменьшения техпроцесса с увеличением площади кристалла, касается вообще всех.
    
    unreal_undead2
    09.10.2024 21:24
    #27399508
    Угу - вижу как в Top 500 лезут системы на NVIDIA Grace, о сломанных ногах речи нет.
  1. Vedomir
    09.10.2024 21:24
    #27400044
    Так это касаетс вообще всех архитектур и x86 и RISC-V и даже Эльбруса.
    
    Titsubishi
    09.10.2024 21:24
    #27400108
    Нет и Эльбрус - не архитектура. ARM несколько упёрся в потолок, тогда как у х86 потенциал ещё раскрывать и раскрывать. На пальцах не объясню и даже пытаться не буду.
    
    unreal_undead2
    09.10.2024 21:24
    #27400146
    Хотя бы поясняющую ссылку можно? Насчёт потенциала x86, которого нет у ARM.
    
    Titsubishi
    09.10.2024 21:24
    #27400158
    Нет. В этом вопросе можно только разобраться и вряд ли одной какой-то ссылки будет достаточно.
1. etofiasko
  09.10.2024 21:24
  #27399566
  ето в самом начале жеж, предыдущие статьи назывались - типа арм ворволась с двух ног вот и
  1. Barseadar Автор
    09.10.2024 21:24
    #27399582
    Да, здесь скорее отсылка к предыдущим статьям, поэтому и рекомендую во введении краем глаза их глянуть — там я подробно разбирал, как ARM росла семимильными шагами, сейчас же рост сильно замедлился
    
    Vedomir
    09.10.2024 21:24
    #27400048
    Тогда был рост с низкой базы, сейчас база уже достаточно большая.

Titsubishi
09.10.2024 21:24
#27398650
Шикарная статья! Спасибо, Автор! Хоть я довольно поверхностно разбираюсь в архитектурах, прочёл залпом) потенциал RISC-V действительно велик и, надеюсь, он себя раскроет.
1. Barseadar Автор
  09.10.2024 21:24
  #27399590
  Спасибо, значит и предыдущие статьи из цикла должны зайти :)

redsh0927
09.10.2024 21:24
#27398810
Система команд без флагов не нужна.
1. checkpoint
  09.10.2024 21:24
  #27398828
  Вам недостаточо флагов в CSR ?
  
  Если Вы про флаги для операций АЛУ, то такие флаги усиливают зависимости команд между собой и усложняют декодер, что являет пролемой при реализации конвейера с внеочередным исполнением.
  1. unreal_undead2
    09.10.2024 21:24
    #27400262
    то такие флаги усиливают зависимости команд между собой
    
    Точно? Учитывая, что уже давно отдельные биты отслеживаются независимо.
    
    checkpoint
    09.10.2024 21:24
    #27401720
    Я же не говорил, что решений нет. Есть масса способов разрешения зависимостей как внутри одного конвейера, так и между разными в пределах одного ядра (старый добрый Томасуло). Но как писал Паттерсон, избавившись от флагов мы сильно упрощаем работу микроархитектурным разработчикам, декодер получается проще, потребляет меньше места (и электричества) и позовляет повысить тактовую частоту.
    
    redsh0927
    09.10.2024 21:24
    #27403734
    Флаги нужны для наращивания разрядности арифметики, проверки переполнений и всё такое. Без флагов эти вещи приходится делать блевотворными костылями, в разы менее эффективно.
    
    "облегчает работу микроархитектурным разработчикам" - вы там долбанулись что ли? Процессор проектируется один раз и потом просто печатается сколько нужно, софта под него пишется неограниченное количество. Что это за прикол облегчать работу одному, чтобы потом сотни мучались?
    
    Вообще, в классических, нормальных архитектурах цпу не принято терять данные. Сумматор помимо данных n-бит принимает и возвращает перенос, аналогично со сдвигами, умножение возвращает двойное слово и т.д. Всё это должно быть доступно разработчику на Ассемблере. Это вам не "безопасные" ЯВУ, молча отбрасывающие "лишние" данные.
    
    И, кстати, найдите и покажите мне этот декодер на дайшоте, посмеёмся. Только не надо показывать в духе "вот исполнительные блоки, вот кэш, всё остальное стало быть декодер". Покажите конкретно декодер команд. Что-то сомневаюсь что он хотя бы 1% на ядро занимает на кристалле. Придумали какую-то отмазку чтобы выпускать всё более мерзкие наборы команд...
    
    checkpoint
    09.10.2024 21:24
    #27406442
    
    О какой потере данных идет речь ? В RISC-V имеются команды для работы с переносом, никаких проблем тут нет.
    
    Никто, кроме создателей компиляторов (и ОС), не пишет на ассемблере. О чем вообще речь ? О том, что Вам как программисту не удобно писать на асме ? Ну извините, эффективная система команд не всегда может удовлетворять требованиям удобства отдельно взятыго индивида.
    
    Настоятелно рекомендую Вам почитать статьи Паттерсона на заданную тему, перед тем как брызгать слюнями. Архитектуре RISC уже более 30 лет, возмущаться надо было в 80-х.
    
    vanxant
    09.10.2024 21:24
    #27406822
    
    Ну как раз в сфере IoT и прочей мелочёвки типа контроллера стиральной машины на асме пишут. По той причине, что вендор предоставил компилятор языка, реализующего некое подмножество чего-то, похожего на Си, а всякие там llvm и gcc не завезли или они дико лажают.
    
    Понимаете, ту же инструкцию умножения можно реализовать в железе нормально, а можно микрокодом на сдвигах и сумматоре. И тогда какое-нибудь умножение на 3 быстрее сделать вручную... вот только gcc о таких особенностях конкретного микроконтроллера нифига не знает и не будет.
    
    checkpoint
    09.10.2024 21:24
    #27406882
    Согласен, в embedded иногда пишут на асме и мне приходится с этим сталковаться. Но это большая редкость и такие случаи можно приравнять к компиляторам или разработке ОС. Для подавляющего большинства задач embedded разработчикам достататочно Си99 + библиотека HAL. В крайнем случае - интринсики для запрета/разрешения прерываний и доступа к CSR. Писать свою библиотеку математики это либо если уж совсем новая архитектура (GCC/LLVM еще не завезли), либо очень старая - компилятор уже не завезут.
    
    В коменте выше человек брызжет словами пытась обвинить создателей архитектуры RISC-V в том, что якобы из-за отсутствия архитектурного регистра флагов там теряются какие-то данные. Большего бреда придумать сложно. Мне попадалась разная критика системы команд RISC, но такое вижу впервые. Отсутствие регистра флагов это типично для RISC.
1. checkpoint
  09.10.2024 21:24
  #27398840
  Del

smoluks4096
09.10.2024 21:24
#27398860
Выбранные примеры удручают своей неизвестностью. Можно было взять например:
- все новые ESP32 (ESP32-C*, ESP32-H*, ESP32-P*)
- RP2350 (Raspberry Pi Pico 2) - на выбор, два Arm Cortex-M33 или два Hazard3 RISC-V ядра
- AllWinner D1
1. vvzvlad
  09.10.2024 21:24
  #27403250
  В которых первые два это микроконтроллеры, в которых риск5 или арм не имеет особого значения в конечном счете.

vanxant
09.10.2024 21:24
#27399302
Статья слишком рекламно-восторженная. Хотелось бы более взвешенного подхода.

"Нет хвоста легаси, как у х86" - чем это хорошо, не объясняется. Просто хорошо и всё тут, верьте мне. Зато умалчивается чем плохо - незрелый софт, начиная с компиляторов и всяких там jvm

"Нет жёсткой сертификации ядер, как у Аrm" - опять же, чем это хорошо, не объясняется. Просто хорошо и всё тут, верьте мне. Зато умалчивается чем плохо - под каждое семейство процессоров нужен по сути свой компилятор, который умеет оптимизировать вот конкретно этот набор инструкций. И, соответственно, каждый программу нужно перекомпилировать под каждый процессор, чего разумеется никто делать не будет. Т.е. в выигрыше у нас всякий IoT, где ради экономии пары микроватт потребления можно физически выпилить ненужные блоки. В минусе - масс маркет со всякими линукс дистрами и гуглоплеями. В штуках намного больше первых, а в деньгах - вторых.
1. torgeek
  09.10.2024 21:24
  #27399456
  Минус легаси, очевидно, в неодходимости разрабатывать и тестировать архитектуру чипа под всё накопившееся наследие. Да и тюнинговать систему команд становится архисложно из-за принятых когда-то неудачных решений по способам кодирования, например.
  
  Хотя в плюсах, что очевидно, стабильная работа всего софта за последние 50 лет на новых чипах. Это дорогого стоит.
  1. bilayan
    09.10.2024 21:24
    #27399560
    Так всё это нивелируется из за
    
    под каждое семейство процессоров нужен по сути свой компилятор, который умеет оптимизировать вот конкретно этот набор инструкций. И, соответственно, каждый программу нужно перекомпилировать под каждый процессор, чего разумеется никто делать не будет.
    
    khajiit
    09.10.2024 21:24
    #27400566
    Это то ли патетичное заламывание рук, то ли вообще некомпетентность: x86 обошлись без отдельного компилятора под каждую версию SSE в каждом поколении процессоров двух производителей (а ранее и пяти) — все, что нужно, включается флагами. А чтоб не думать — -march=native
    
    unreal_undead2
    09.10.2024 21:24
    #27400600
    А чтоб не думать — -march=native
    
    Для "коробочного" софта, который отдаётся кастомерам в бинарном виде, думать придётся.
    
    khajiit
    09.10.2024 21:24
    #27400678
    Проблемы коробочниов… к утверждению про отдельный компилятор для каждого процессора они отношения вообще не имеют.
    
    unreal_undead2
    09.10.2024 21:24
    #27400746
    Я согласен, что отдельный компилятор не нужен, но разбираться с зоопарком расширений всё равно придётся.
    
    unreal_undead2
    09.10.2024 21:24
    #27400752
    Я согласен, что отдельный компилятор не нужен, но разбираться с зоопарком расширений всё равно придётся.
    
    Limansky
    09.10.2024 21:24
    #27401136
    Теоретически, да. Но это будет влиять на производительность, и на практике видим совсем другое. Вот если берём базовую ISA RISC-V и вокруг выстраиваем обвязку из стандартных общепринятых расширений и прикручиваем компилятор gcc/clang то все вроде бы ок. А ещё в архитектуру можно встраивать свои расширения (открытые/закрытые), так же разработчики оптимизируют "свои" (берут за основу теже gcc/clang ) компиляторы под конкретные "свои" ядра и эти оптимизации почти всегда закрыты, но это не беда, просто берём все от одного производителя и радуемся, не жели страдаем с каким-то базовым компилятором для оной архитектуры. Проблема теоретически, может случится когда одно расширение есть в одних чипах, а в других отсутствует, тут уже одно и тоже приложение, которое опирается на эти расширения не будет работать, на других ядрах, хотя казалось бы одна экосистема к примеру risc-v 64 bit, linux, но это уже совсем другая история...
    
    unreal_undead2
    09.10.2024 21:24
    #27401302
    Закрытые расширения/оптимизации - отдельная история. Но открытые расширения вполне можно покрыть флагами gcc/clang, заинтересованные разработчики могут добавлять туда же оптимизации для своих процессоров.
    
    когда одно расширение есть в одних чипах, а в других отсутствует
    
    Вот про этот зоопарк я и писал. Разрулить можно (скажем, отдельными so под базовую архитектуру и разные расширения с загрузкой нужной в зависимости от фич железа), но требует усилий.
    
    khajiit
    09.10.2024 21:24
    #27401528
    Вот про этот зоопарк я и писал
    
    См сиблинг, это не зоопарк, это данность мира x86
    
    khajiit
    09.10.2024 21:24
    #27401524
    расширение есть в одних чипах, а в других отсутствует
    
    Банальнейшая банальность в мире x86, которой десятки лет.
    почти десяток версий SSE, полдюжины наборов 3Dnow! и AVX — это и давнее прошлое и повседневная реальность. А еще есть новые инструкции в стандартном наборе (POPCNT поднял много шума), разное поведение инструкций в зависимости от поколения (RDTSC, например) умершие расширения, поменявшие свое назначение префиксы…
    
    molnij
    09.10.2024 21:24
    #27403562
    Вот просто любопытства ради, а popcnt где-то кроме новостей шум поднял? Я просто так и не придумал кейс в котором кто-то обновляется на одиннадцатую винду на компьютере приближающемся к возрасту совершеннолетия, уцелевшем чудом, на условном Dual Core, обламывается и раздраженно начинает писать во все инстанции.
    
    Ну или из последних новостей - обновляет драйвер NVidia до последней актуальной версии (для карты того же почтенного возраста, иначе бы не влезла в PCI-E 1.0) и тоже идет строчить гневные комментарии всюду куда дотянется.
    
    Как-то сюрреалистично выглядит, нет?
    
    khajiit
    09.10.2024 21:24
    #27404752
    Сюрреалистично выглядит то, что одни и те же, известные по x86, проблемы для RISC-V — это ужасные проблемы-проблемы, от которых он абисатильна захнедся, а для x86 — все в порядке вещей и так и надо. Хотя это давно уже вообще не проблемы.
    
    vikarti
    09.10.2024 21:24
    #27404970
    Таскать библиотеки под разные версии. Давно ж решено
    
    Ну да - чуть медленее будет компиляция
    
    unreal_undead2
    09.10.2024 21:24
    #27405092
    Да, как написал. Но у Интела развитие линейное - скажем, если на процессоре есть AVX2, то точно есть popcnt. А на RISC V расширения ортогональны - то есть можно сделать процессор с крипторасширениями без векторов, можно - с векторными без крипто, можно и то и то - и так со всеми. Так что для полной поддержки надо таскать 2^N библиотек, если для оптимизации кода применимы N расширений.
    
    Там и простые инструкции на несколько расширений развалены, но насколько понимаю на всём сложнее микроконтроллеров можно расчитывать как минимум на GC.
    
    vanxant
    09.10.2024 21:24
    #27401428
    x86 обошлись без отдельного компилятора под каждую версию SSE
    
    Да-да, как раз во время первого SSE и конкурирующего 3DNow я выносил код обработки изображений в отдельную либу и компилил её под интел - icc, под amd - msvc. Второй, конечно, умел и под интел компилить, и машинный код был почти такой же, но код из-под icc работал на 20-30% быстрее, но только на интелах. Потому что они знали все подводные камни и затачивались конкретно под свои процессоры.
    
    khajiit
    09.10.2024 21:24
    #27401558
    Возражая по форме вы фактически подтверждаете сказанное.
    
    rukhi7
    09.10.2024 21:24
    #27406782
    Если вы не напишете на ассемблере с использованием sse mmx функции декодирования DCT блоков, например, никакой компилятор вам их сам не напишет, какие бы флаги вы ему не включали, об этом мне рассказали те кто эти функции в интеле писал на ассемблере.
    
    checkpoint
    09.10.2024 21:24
    #27406910
    Потому, что это проприетарная Intel-овская ISA! В ней огромная часть закрыта всякими NDA и только Intel имеет право писать оптимизированные библиотеки и оптимизирующий компилятор для своих же процов. С открытыми архитектурами такого нет. Если система команд полностью опублиоквана со всеми нюансами, то рано или поздно под неё появится оптимизирующий компилятор который в подавляющем большинстве случаев будут генерировтать код оптимальней чем программист.
    
    rukhi7
    09.10.2024 21:24
    #27407428
    ну вот как раз подвезли наглядный пример вот здесь:
    
    Я ускорил генерацию blurhash в 3̶6̶ 8̶7̶ 128 раз
    
    найдите заголовок:
    
    3. SIMD (SSE + NEON)
    
    и вы увидите вот такую волшебную строчку в коде:
    
    #ifdef __SSE__
    
    и вот такие типы:
    
    __m128
    
    согласитесь это совсем не похоже на флаг компиляции, может быть когда нибудь компиляторы научатся переписывать код в других типах, но пока прогресс туда явно не дошел. Но чтобы работал код именно под этим иф-дефом какой-то флаг компиляции все таки нужен, но без кода написанного руками не обойтись и я думаю ближайшие лет 10 это не изменится, я что-то не слышал чтобы кто-то учил ИИ применять SSE по его ИИ разумению.
1. torgeek
  09.10.2024 21:24
  #27399480
  По части сертификации в риск5 есть процесс из двух шагов — "пакетные/наборные спецификации" типа RVA24 и наборы инструментов, в том числе открытых, для проверки соответствия нового чипа этим спецификациям.
  
  В части усиления кроссовместимости чипов разных разработчиков по системе команд, кажется очевидным, что появится однажды какой-то совместный процесс у Байкала и Ядра в рамках ассоциации риск5.
1. unreal_undead2
  09.10.2024 21:24
  #27399482
  "Нет жёсткой сертификации ядер, как у Аrm" - опять же, чем это хорошо, не объясняется.
  
  Для людей, решающих, на чём строить датацентры и облака - это скорее минус.
  1. torgeek
    09.10.2024 21:24
    #27399546
    Как понимаю, речь не про отсутсвие сертификации, а про "невозможность" создания другого органа сертификации. То есть монопольная зависимость архитектуры от одного поставщика.
    
    Barseadar Автор
    09.10.2024 21:24
    #27399596
    Всё верно, мысль в этом была
    
    unreal_undead2
    09.10.2024 21:24
    #27399610
    Но при этом есть некая уверенность, что софт, скопилированный под, скажем, ARM 8.2 будет работать на любых процессорах с соответствующей лицензией и сертификацией - хоть на новых моделях от текущего поставщика, хоть на процессорах другой фирмы. А вот насколько это работает с RISC V - пока непонятно.
    
    torgeek
    09.10.2024 21:24
    #27399700
    Ищите в описании проца такую запись "Полное соответствие профилю RISC-V RVA22" — это пример из чипа Sophgo SG2380.
    
    unreal_undead2
    09.10.2024 21:24
    #27399722
    Полное соответствие профилю RISC-V RVA22
    
    И кто это проверял? "Мамой клянусь"?
    
    torgeek
    09.10.2024 21:24
    #27399734
    Как и в любом федеративном продукте типа ядра Линукса или шины PCIe))
    
    checkpoint
    09.10.2024 21:24
    #27401808
    Вообще-то тесты свободно доступны, любой пользователь их может прогнать и опубликовать результаты, и вендору будет крайне тяжело их оспорить. Что-то подобное есть у Web-браузеров - тест на соответствие стандартам JavaScript и HTML.
    
    С проприетарными процами всё строго наоборот - как хозяин-барин решит, так и будет, а пользователи должны продолжать давиться этим кактусом. Как там у Интела с дохнущими камнями, кстати ? Признали уже проблему или всё еще отмазываются фразой "неправильная эксплуатация привела к деградации..." ?
    
    unreal_undead2
    09.10.2024 21:24
    #27403746
    x86 - другая крайность с выбором из пары вендоров. В случае ARM по крайней мере есть NVIDIA, Amazon, Ampere, Huawei, Fujitsu (если речь о серверных решениях).
    
    Aelliari
    09.10.2024 21:24
    #27403860
    выбором из пары вендоров
    
    AMD и Zhaoxin?
    
    P.S. на правах шутки :)
    
    unreal_undead2
    09.10.2024 21:24
    #27403884
    Ну да, кто в здравом уме Zhaoxin в датацентры закупит (хотя на безрыбье где то может и до такого дойти...)
    
    torgeek
    09.10.2024 21:24
    #27404480
    На безрыбье и Эльбрус умеет х86 исполнять. Причём, рассказывают, что иногда х86 код исполняется быстрее родного е2к-кода))

0utlander
09.10.2024 21:24
#27399662
Можно добавить, что в России уже есть свое решение на RISC-V
1. Barseadar Автор
  09.10.2024 21:24
  #27399676
  Нам нужны производства, фабрики, технологии литографии, вот что самое главное, но да перспективные разработки есть :)
  1. funca
    09.10.2024 21:24
    #27399826
    Как сказали выше:
    
    Короче, нас ждет ~~балканизация~~ байкализация системы команд микропроцессоров.
    
    unreal_undead2
    09.10.2024 21:24
    #27399938
    То есть ноги пока не ломаем? )
    
    tharsedX
    09.10.2024 21:24
    #27400818
    главное, чтобы не бакланизация
  1. PetrSerg
    09.10.2024 21:24
    #27400890
    Да? Самое главное это люди, технически грамотные люди. Да и не только технически.

Vedomir
09.10.2024 21:24
#27400132
Как-то очень много воды и картинок. Мне кажется что преимущества и польза для общества у RISC-V те же, что и у любого открытого проекта
1. Невозможность монополизации и независимость от внезапного приступа придури/жадности единственного владельца
2. Гораздо более жесткая кокнуренцияи между гораздо большим и разнообразным числом действующих лиц
Собственно все то же что выделяет более открытую ARM на фоне более закрытой x86.

Каких-то волшебных преимуществ RISC-V само по себе не несет и будет повторять историю ARM медленно развиваясь от простых и слабых процессоров/микроконтроллеров к более сложным и мощным.

По сути это повторение истории ARM с более явно выраженными преимуществами открытости.

Единственное реально хорошее место в статье - подчеркивание роли микроархитектуры для производительности. Сама по себе система команд не делает RISC-V лучше, преимущества открытости организационные и политические.

Грубо говоря когда Джобс захотел выйти в новый сегмент мобильных устройств на х86 была монополия Intel и дурь интел как единственного принимающего решения лица сгубила перспективы архитектуры. Иначе все мобильники сейчас могли бы быть на x86. А большая открытость и конкуренция на ARM позволила найти компании, которые дурью не страдали и увидели перспективы.

Примерно так пять столетий назад в Китае единое и мопнопольное правительство приняло решение отказаться от технического прогресса и захвата заморских колоний, а в Европе среди множества независимых друг от друга и конкурирующих между собой правительств нашлись те, кто решил в это вложиться. Колумб несколько королей обошел в поисках финансирования, пока не нашел достаточно смелых.

Ну и замедление роста ARM вполне естественно - пропадает эффект низкой базы.

И да Windows Phone была очень плохой и идеей и технологией. Детище маркетологов и красивых отчетов для начальства и журналистов, совершенно не рассчитанное на использование в реальной жизни.
1. daggert
  09.10.2024 21:24
  #27400396
  И да Windows Phone была очень плохой и идеей и технологией.
  
  Вот сейчас обидно. Как имевший в руках тогда те телефоны - я все еще скучаю по их простоте, по тому какой у них был интерфейс, по самой концепции живых плиток, по тому как там была реализована система к доступу к фото/видео, по интеграции с сервисами того-же майкрософт.
  
  Еслиб гугл не душил из-за конкуренции с ведром и майки чуток более открыли доступ до железа - мыб видели третьего адекватного игрока на рынке, который имел фанбазу.
  1. Werefare
    09.10.2024 21:24
    #27400598
    Поддерживаю, Windows Phone была новаторской и смелой с точки зрения UI/UX; NOKIA пичкала WP-смартфоны крутыми аппаратными решениям, вроде OLED-дисплеев и беспроводной зарядки. Сейчас это стало стандартом в отрасли, а тогда было у единиц. Умерла она из-за отсутствия софта (того же Google) и поддержки от сторонних разрабов, а не от чего-либо другого.
  1. Vedomir
    09.10.2024 21:24
    #27405272
    Я ни секунды не спорю с тем что есть люди, которым они могли нравится, но тут уже в дело вступает статистика - те люди, которым они радикально не понравились, как и мне например, составляют подавляющее большинство.
    
    Я еще превосхожно помню статьи тех времен с одним общим рефреном "ну почему люди такие тупые и не понимают, что на самом деле это удобно, надо больше вкладываться в маркетинг чтобы обьяснить людям, что это на самом деле удобно".
    
    Те вещи, которые действительно удобны, не встречают такого молчаливого сопротивления и их не надо проталкивать силой, они наоборот сами распространяются с вирусным эффектом.
    
    С технологической же точки зрения они сделали феерическую глупость полностью сломав обратную совместимость приложений - первый раз с выпуском Windows Phone, второй раз с выпуском 8 версии. Два раза надо было полностью переписывать приложения. Такая технологическая политика могла бы и Android погубить.
    
    Если бы майки вместо Phone развивали Windows Mobile они вполне могли бы занять место Android сделав это вовремя или остаться третьим игроком сделав это чуть позже. Имели бы примерно те же достоинства и недостатки что и Android.
1. Fasterpast
  09.10.2024 21:24
  #27401144
  Windows Phone была очень плохой и идеей и технологией. Детище маркетологов и красивых отчетов для начальства и журналистов, совершенно не рассчитанное на использование в реальной жизни.
  
  Вообще ни разу нет, как раз все, кто пользовался в реальной жизни, были довольны, ведь в то время это было лучше из двух миров: удобный не лагучий интерфейс даже на слабом железе и относительная открытость, нормальный файловый менеджер и т.д. Там были другие проблемы, в т.ч. с СДК и в целом со взаимодействием с разработчиками приложений, поэтому платформа начала загибаться банально из-за отсутствия многих важных (для людей) программ. А запуск андройдовского ПО то ли не допилили, то ли специально (ошибочно) зарезали...
1. Limansky
  09.10.2024 21:24
  #27401254
  Вот уж не совсем, я согласен. Был владельцем данного аппарата, мне он очень нравился (Windows Phone 8, Windows Phone 8.1, моя модель не поддерживала переход уже на новую версию) и я скучаю конечно по нему, но вот гвозди в крышку гроба забивала придурь создателей в плане апи, форматов фалов, etc. это не давало возможностей как обратной совместимости, так и владельцам некоторых не слабых устройств обновляться.
1. event1
  09.10.2024 21:24
  #27401730
  Собственно все то же что выделяет более открытую ARM на фоне более закрытой x86.
  
  Довольно произвольное утверждение. x86 точно так же можно лицензировать и допиливать. AMD именно этим и занимается. А раньше ещё были VIA и ещё кто-то. Я думаю, что причины успехов ARM последнего времени в том, что сама архитектура гибче
  1. unreal_undead2
    09.10.2024 21:24
    #27401750
    x86 точно так же можно лицензировать и допиливать.
    
    Ну попробуйте ) Сейчас его могут использовать только те, кто получил лицензию в те времена, когда Интел её давал (и их правопреемники).
    
    event1
    09.10.2024 21:24
    #27401956
    Систему команд даже лицензировать не надо. Патенты на неё истекли. Но собрать из готовых блоков рабочий процессор, как у АРМ не получится, конечно.
    
    unreal_undead2
    09.10.2024 21:24
    #27403750
    Она разве не авторским правом защищается? Там сроки побольше. Ну и конкретно x86-64 появился позже и насчёт него надо отдельно с AMD договариваться.
    
    event1
    09.10.2024 21:24
    #27404680
    Думаю, что нет. Во всяком случае интел судилась с цайрикс из-за патентов, а не из-за авторских прав.
  1. Vedomir
    09.10.2024 21:24
    #27405306
    Вообще-то нет. У AMD и еще буквально пары крохотных компаний которые до сих пор делают такие процессоры есть лицензионные соглашения заключенные много десятилетий назад. Новые лицензии уже много десятилетий получить невозможно.
    
    event1
    09.10.2024 21:24
    #27405452
    я не вполне точно там выразился. У АРМа разработчики получают конструктор из которого они собирают процессор, который потом производят, как хотят. Интел таким, конечно, не занимается. Но, с другой стороны, патенты на системы команд истекли. То есть, лицензировать их не надо. То есть, кто угодно может сесть и сделать x86-совместимый компьютер. Всё что нужно это немного денег и времени
    
    Ну и кстати, даже если бы патенты не истекли, Интелу всё равно не удалось бы их зажать. Его бы заставили их лицензировать по разумной цене по антимонопольному законодательству. Точно так же как qualcomm заставляют лицензировать патенты на wi-fi и 5g
    
    unreal_undead2
    09.10.2024 21:24
    #27405464
    У АРМа разработчики получают конструктор
    
    Или только спецификацию на ISA и рисуют своё ядро с той же системой команд (архитектурная лицензия).
    
    Vedomir
    09.10.2024 21:24
    #27405502
    Так x86 же тоже развивается 5 версий SSE две версии AVX, x86-64. Насколько я помню срок действия патентов 25 лет, из под них еще даже x86-64 не должна выйти. AMD в свое время заключила кросслицензионные соглашения с Intel но это их внутренне дело.
    
    Аналог Pentium 3 наверное можно сделать без лицензий но на нем никакой современный софт не пойдет.
    
    И если бы лицензия на x86 продавалась на нее бы длинная очередь выстроилась - как минимум из досанкционных китайцев, да даже и русских вроде Байкала которые лицензию на АРМ покупали.
    
    Apple бы сделала свои ядра на x86 и производила бы их на современных техпроцессах.
    
    Но когда Intel им отказала непосредственно в процессорах, купить лицензию на x86 было негде.
    
    Вместо этого все долго и мучительно изобретали высокопроизводительные ARM почти два десятилетия.
    
    event1
    09.10.2024 21:24
    #27405712
    И если бы лицензия на x86 продавалась на нее бы длинная очередь выстроилась - как минимум из досанкционных китайцев
    
    Китайцы, кстати, вполне успешно разрабатывают х86 процессоры в сотрудничестве с VIA для собственного рынка.
    
    unreal_undead2
    09.10.2024 21:24
    #27405740
    Это как раз "старые лицензиаты", цепочка тянется к Cyrix.
    
    Vedomir
    09.10.2024 21:24
    #27405912
    Не совсем, к Centaur Technology, Cyrix уходит к AMD.
    
    unreal_undead2
    09.10.2024 21:24
    #27405950
    В 1999ом VIA купила и кусок Cyrix'а и Centaur.
    
    Vedomir
    09.10.2024 21:24
    #27405900
    Обратите внимание на форму сотрудничества - это не покупка лицензии, а совместное предприятие с фирмой, которое владеет лицензией несколько десятков лет. VIA кстати тоже лицензию не покупала, она купила фирму с такой лицензией основанную аж в 1995 году - Centaur Technology. Есть еще одно такое совместное предприятие с AMD и причина у него точно такая же - невозможность просто купить лицензию.
    
    С ARM никто такие сложные схемы не изобретает, просто покупается лицензия - либо на ядро либо на архитектуру.
1. checkpoint
  09.10.2024 21:24
  #27401872
  Не совсем так. RISC-V это не просто еще одна система команд с открытой лицензией (таких, кстати, есть несколько: OpenRISC, OpenPOWER и т.д.), RISC-V это хорошо выверенная, подкрепленная десятилетиями научных исследований, система команд нацеленная на производительность и эффективность исполнения. Целями создания RISC-V было не удобство программирования или написания очередного компилятора, а простота реализации на микроархитектурном уровне, минимум зависимостей между командами, простая схема декодера, легкость конвейеризации, относительно высокая плотность кода, энергоэффективность и т.д. Получилось ли у Паттерсона и Асанович достичь этих целе - мне судить сложно, есть много "за", как и много обьективной критики.
  1. unreal_undead2
    09.10.2024 21:24
    #27403766
    Как идея оно мне нравится (даже симулятор базового набора команд писал из интереса, чтобы заодно одну рабочую идею обкатать). Но пока не вижу конкретных реализаций, пригодных для энтерпрайза и HPC.
    
    checkpoint
    09.10.2024 21:24
    #27406472
    Про конкретные реализации я четко написла в самом первом комменте. Их нет и не будет еще достаточно долго - кто-то должен будет пройти длинный путь создания высокопроизводительной микроархитектуры, при этом все остальные монополисты в виде Intel, AMD, IBM и ARM будут тщательно совать палки в колёса.

IvanovSV
09.10.2024 21:24
#27400648
"Два из наиболее известных продуктов Беркли - LSD и Unix. Я не думаю, что это совпадение"
1. Ingas
  09.10.2024 21:24
  #27401662
  LSD не имеет никакого отношения к Беркли

Genka_pokos
09.10.2024 21:24
#27401288
Как же вы задрали со своими супергероями
1. ssj100
  09.10.2024 21:24
  #27401344
  А какие возгласы были когда Apple выпустили M1

xabar
09.10.2024 21:24
#27403628
А можно и мне имхо выкатить? Я 15 лет занимаюсь системой разработкой. Прошёл mips, e2k, powerpc, x86, arm на максимальной сложности со всеми дополнениями.

Не будет r5 массовым. Не нужен. Деньги нужны - а r5 не нужен. Займёт какую-то определённую долю, порядка 0,1% и тихонечко там будет подгнивать.

Почему то о нем модно говорить и рассказывать как он захватит мир - прям rust в мире кремния. А по факту очередная бестолковая поделка.

Вся мякотка современных камней вотвсяких акселераторах, npu, gpu и прочих свистелках, которые закрыты, и поставляются с бинарным микрокодом. А какой смысл в r5 тогда?
1. torgeek
  09.10.2024 21:24
  #27404614
  вотвсяких акселераторах, npu, gpu и прочих свистелках
  
  Оно так и есть — все большие чипы на риск5 именно тут, в ускорителях. Так у Алибабы, Тенсторрента, Эсперанто, Вентаны, Семидинамикс...
  
  Плюс со стороны универсальных микроконтроллерных задач уже полно процессоров на риск5. Тут прям всем миром переход виден — от тотального у WCH и Еспрессив до попробовать — Ренессаc, NXP, Нордики и даже итальянцы из СТМ пошли сюда только что. Про спецконтроллеры мало говорят, но их делают почти все, даже наши Кравтвей и Аквариус и всякие разработчики базовых станций, например))
  
  На следующий год, очевидно, что будет много выходить процессоров с риск5 в сегменте ПК/ноутов. Первые 4-8-16 ядерные уже вывши в этом году в готовых устройствах, но это "на любителя" — дозревают драйвера, компиляторы и ОС. А на следующий год выходят и наши, например Ядро уже получило первую выпечку собственного риск5 чипа для замены АРМов в своих планшетах.
  1. checkpoint
    09.10.2024 21:24
    #27406922
    Пользователь @xabar прав, высокая производительность создается не системой команд, а микроархитектурными решениями, а они все напрочь запатентованы и никто из мэтров ими делиться не собирается. Так, что путь RISC-V к олимпу HPC будет очень и очень тернист. Но я, на против, уверен что это произойдет и настанет момент когда камни на архитектуре RISC-V от разных вендоров, один за другим, начнут бить рекорды производительности. Я даже почти уверен, что Intel, почувствовав запах своей подгорающей задницы, возглавит эту гонку.
1. torgeek
  09.10.2024 21:24
  #27404742
  Прошёл mips, e2k, powerpc, x86, arm
  
  Жаль, конечно, что не дошли до сегодня системы команд чипов из времён позднего союза типа Кронос или развитие линеек на основе PDP11. Дотащили только эльбрусовский е2к.
  
  Но массовым тиражом (1,8 млн. шт. в этом году) вышел риск5 чип АМУР на зеленоградской фабрике Микрон. Он полностью спроектирован в России, включая использование вычислительного опенсорсного ядра из Петербурга. Причём разработчики АМУРа фактически использовали исходники ядра без разработчиков этого ядра. И это первый такой удачный опыт.
  1. checkpoint
    09.10.2024 21:24
    #27406998
    Да, я тоже хотел бы видеть продолжение советской линейки PDP11 вместо E2K. Взяли бы комплект КН1811 или КН1831ВМ1 и переложили бы его на современные наномеры, предварительно расширив слово до 64 бит.
    
    MIK32 АМУР, несмотря на некоторые нюансы, оказался не плох. АЦП бы ему подправить (Vref увеличить, битности добавить), увеличить EEPROM до 16К и вполне годный будет микроконтроллер, не хуже всяких STM32. :)
1. torgeek
  09.10.2024 21:24
  #27404852
  Займёт какую-то определённую долю, порядка 0,1%
  
  Как ни парадоксально, но это уже произошло. Причём даже выше 1% участия риск5 в "больших" чипах :)
  
  Байкал реализовала в своём серверном 48-ядерном АРМ процессоре Байкал-С ядро риск5 для доверенной загрузки и управления чипом.
  
  МЦСТ в линейке Спарк-процессоров выпустила новый чип с дополнительным риск5 ядром управления питанием.
  
  Сюда же симпатичный пример на перспективу, правда про "мелкие" чипы — компания Бештау в Ростове проектирует риск5 процессоры микроконтроллерного применения для замены чипов с системами команд 8051 и АРМ в своих периферийных устройствах — клавиатуры, мыши, мониторы и т.п.
  1. unreal_undead2
    09.10.2024 21:24
    #27404876
    Если так считать, то Minix - очень популярная ОС )
    
    torgeek
    09.10.2024 21:24
    #27405352
    Более точно "будущее уже здесь, но неравномерно распределено"))

4m3l
09.10.2024 21:24
#27404914

PwrUsr
09.10.2024 21:24
#27406290
Так чьи акции-то покупать? Если обещают рост рынка 40%+ в год - надо бы откусить кусочек...

WDC? BABA? Intel? Google? или кто ?
1. checkpoint
  09.10.2024 21:24
  #27406928
  Концерна Калашников.

RISC-V — звезда родилась: x86 не у дел, ARM сломала обе ноги +61

В чём RISC: Люди Икс и предыстория

Первое — открытость

Модульность и кастомизация

Где место под солнцем RISC-V

Но причём тут RISС-V?

RISC повсюду

Примеры продуктов на RISC-V

Не выводы, но проблемы

Комментарии (150)

Barseadar Автор

Barseadar Автор

Barseadar Автор

Barseadar Автор