Comments 75
«Архитектура RISC изменит всё» - это product placement Apple (их серии Power).
Много позже, они снова возврашаются к этой идее и как итог мы видим их серию М.
Если б ARM был RISC-ом.
Он им был
В M1 уже есть чудо-инструкция Floating-point Javascript Convert to Signed fixed-point, rounding toward Zero, которая на RISC ни фига не похожа.
Так всё ж правильно сказано: он им был.
чуть почитал нашел такое еще https://habr.com/ru/articles/465723/ тоже интересная тема на тему float point (posit подход)
С чего бы она не похожа на RISC?
Это элементарная однотактовая операция регистр-регистр. 100% RISC идеология.
Ровно как и SIMD тоже 100% RISC.
Вы вообще смотрите не туда. Количество команд и наличие специализированных команд, не играет никакой роли.
Надо понимать, насколько сложна реализация команды в железе, и насколько хорошо это ложится на конвейер.
У ARM v8 есть CISC - операции CAS - это триумф практичности над идеологией.
А также (ещё с ARMv7) есть инструкции типа LDn, которые идеологически как бы обычные операции загрузки, но на самом деле это CISC load-op, осуществляющие частичную запись регистра.
https://eclecticlight.co/2021/08/23/code-in-arm-assembly-lanes-and-loads-in-neon/
Более того, юзала она в той сцене старый Apple Powerbook с процессором Моторола. Который честный CISC, к слову :)
А Чип Р6 существует?
Слишком много экзальтации.
Вы заставляете меня увеличивать свой словарный запас. Не надо так.
Есть такое.
Не знаю как реагировать на переводные статьи: претензии переводчику в плане сути необоснованны, претензии автору оригинала нет смысла озвучивать, ибо не дойдут.
Кликбейт как он есть.
Не так уж много людей смотрели этот фильм.
Помимо интересной мне даже в то время компьютерной тематики там были саундтреки от The Prodigy.
Полагаю, упоминание о Джоли и фильме сделано исключительно для привлечения внимания, поскольку статью о RISC можно было написать и без "Хакеров". Сути бы не изменило.
Уважаемый, не расстраивайтесь из-за минуса. Это я случайно. Я писал комментарий с телефона, а когда нажал - Отправить, увидел что вместо комментария минусовал ваш комментарий. Отменить минус хабр не дает, поэтому извиняюсь.
Замечательная статья! Хабр еще торт...
Со времен первого пентиума если не ещё раньше шли разговоры что архитектура RISC производительнее CISC. RISC архитектура с сокращённым набором команд. CISC процы со сложными командами 86-е например. Одна команда делает сложные операции, но за много тактов. Альтернативная RISC имеет очень простые команды, типа сложений и пересылок, но все выполняются за один такт. Уж во времена съемок "хакеры" про RISC точно было известно. Только это совсем не RISC-V, который появился сильно позже, в 2010.
Уж во времена съемок "хакеры" про RISC точно было известно.
Во времена съемок "Хакеров" архитектура RISC была как раз на подъёме, и вовсю теснила х86 в hi-end решениях, всякие там монстры вроде DEC Alpha. Сейчас совсем наоборот, она пыхтит, пытаясь зайти с рынка гаджетов и low-end.
"Хакеров" пересматриваю примерно раз в год начиная с 1995 🤩 благодаря им разобрался в архитектуре (та самая красная книга, которая не помещается на полку)
А я просто каждый год, а то и чаще. Фильм просто больно нравится. Бывает, вот хочу "Назад в будущее" пересмотреть, или там все фильмы Кевина Смита.
у "Хакеров" беда в 10+ переводах на русский. И сцену в статье, как только не переводили, для обывателей. В моем относительно приоритетном для меня переводе, есть только про чип Р6 и шину PCI. А вот про RISC, я узнал из статьи.
Спасибо за перевод.
есть только про чип Р6 и шину PCI
Когда я его смотрел, там говорилось "за этими компьютерами будущее". Видимо, переводчик с P6 и PCI ещё справился, а вот RISC не осилил и решил не, кхм, рисковать, вворачивая незнакомый ему термин в непонятном контексте.
Хотя по меркам 1995-го оно тоже смотрелось стрёмно. Вокруг тебя стационарные компы в лучшем случае 486-е, а чаще 286/386, первые пентиумы стоят космических денег и юзаются в редких мощных серверах, а эти смотрят на ноутбучек и рассказывают, как он там в несколько раз мощнее пентиума.
От сцены с книгами у меня всегда мурашки по коже, для меня именно это место сюжета сильнее всего передаёт дух эпохи раннего Интернета.
Фильм с какой-то своей атмосферой. Несмотря на некоторую стереотипность образов и совершенную вычурность насквозь фантастического/сказочного сюжета. Но! Всегда приятно, когда зло наказывают. Даже если ради этого надо накрутить всякого сюжетного трэша. Главное, показать побольше всяких загадочных картинок. Особенно "убило" эдакое картинное "хождение по системе". Но фильм забавный. И... все ещё такие молодые!
У нас зачем-то назвали фильм про Кевина Митника "Хакеры 2", хотя он никакого отношения к оригинальным "Хакерам" не имел. Это там где главного героя играл Скит Ульрих. (Разве что, Скит Ульрих играл вместе с Мэтью Лиллардом (вот он сидит на картинке с зубной щёткой) в фильме "Крик". Но это только очень косвенная связь.) Зато фильм оказался удивительно достоверен (не смотря на всю свою художественность) в плане противостояния Митника с Симоммурой.
не так уж много людей прочитали этот опус. думаю - поменьше тех кто смотрел фильм
кошмарное содержание, но так и не понятно почему RISC выигрывает CISC?!
Выигрыш RISC архитекура только для разработчиков этих чипов, так как они перекладывают аппаратную простоту архитектуры процессора на усложнение программной части. Объясняю популярно, к примеру берем инструкцию x86_64:
ADD [RBX + RAX *8], 0xFFFFFF
сколько понадобиться инструкции RISC-V заменить подобное
# Предположим, что x1 = RBX, x2 = RAX
# Шаг 1: Вычисляем адрес
SLLI x5, x2, 3 # Умножаем RAX (x2) на 8 (сдвиг влево на 3 бита), результат в x5
ADD x5, x5, x1 # Добавляем RBX (x1) к результату, получаем полный адрес в x5
# Шаг 2: Загружаем значение из вычисленного адреса
LW x3, 0(x5) # Загружаем значение по адресу (RBX + RAX 8) в x3
# Шаг 3: Добавляем константу
ADDI x3, x3, 0x0FFFFFFF # Добавляем 0x0FFFFFFF к загруженному значению в x3
# Шаг 4: Сохраняем результат обратно по тому же адресу
SW x3, 0(x5) # Сохраняем обновленное значение обратно по адресу (RBX + RAX 8)
5 инстуркции RISC-V против 1 инструкции CISC
Возникает вопрос, а сколько Вт потребуется для выполнения 5 инструкции RISC-V для выполнения аналогичной инструкции CISC? При этом не нужно забывать про объем оперативной память для этих инструкций и что еще эти инструкции нужно "загнать" в процессор и так далее...
Возникает вопрос, а сколько Вт потребуется для выполнения 5 инструкции RISC-V для выполнения аналогичной инструкции CISC?
Примерно столько же, более того, CISC имеет RISC-ядро, он разберёт эту команду на составляющие и выполнит как 5 RISC-операций. Тут выигрыш не "в лоб" по количеству операций, а в том, что
Если набор операций короткий, умный компилятор может лучше его оптимизировать. Всё-таки софтинка без ограничений по ресурсоёмкости с этим справляется получше, чем микрокод, засунутый в процессор.
Короткие операции фиксированной длины можно быстрее скармливать процессору.
Простой по архитектуре кристалл банально дешевле в производстве.
все перечисленное - это декларация
в реальности уже в ARM напоролись, что простое и безрассудное увеличение ядер в одном корпусе приводит к простою всех процессоров, так как простые инструкции требуют более интенсивной загрузки из памяти; и поэтому сейчас абсолютно все разработчики RISC-процессоров идут на хитрость - частота ядер низкая, а вот частота DDR значительно выше...
лишь по этой причине RISC архитектуры всегда будут догоняющими
Ну, это же не причина самого RISC или CISC. Это всего-лишь следствие слишком большого отрыва частоты ядра от частоты памяти. Вот на заре скорость памяти была соизмерима со скоростью ядра и никакие кеши не нужны были. Но так получилось, что молотилку разогнать получается быстро, а вот против физики зарядов конденсаторов решения нет. Вот и приходится делать костыли вроде дорогой быстродействующей памяти именуемой кешем. Кстати, многоядерные и многопроцессорные системы всегда будут иметь конкуренцию ядер за общие ресурсы, а если эти ресурсы ещё и медленные... Так что увеличение личного кеша ядра пока лишь единственное на данный момент реальное (но в то же время и дорогое и энергонеэффективное) решение коллизий доступа к общим ресурсам + программная оптимизация доступа к этим ресурсам разными ядрами.
Чтобы кусок кода появился в кеш-памяти для начало его нужно хотя бы один раз прочитать из оперативной памяти - иным способом она там не появиться.
Для CISC - процессора:
ADD [RBX + RAX * 8], 0x0FFFFFFF - это 7 байт памяти, то есть 1-2 обращения к оперативной памяти (взависимости от выравнивания по границе адреса ячейки памяти)
Тоже самое для RISC- процессора:
5 инструкции - это 6 х 4 = 24 байт, то есть 3-4 обращения к памяти (в зависимости от выравнивания по 4-байтной границе)
Так вот для многоядерных RISC-системах, чтобы они на равне тягались с CISC-системами требуется оперативная память с более высокой пропускной способностью. Поэтому вы не найдете сегодня RISC-процессор с частотой выше 3,5 ГГц на ядро. И это все вытекает из-за простоты аппаратной части процессора и усложнением программной части.
Разработчики процессров просто переложили ответственность: мол вот вам быстрый проц - покупайте, а почему медленно работает код - это вы виноваты
Поэтому вы не найдете сегодня RISC-процессор с частотой выше 3,5 ГГц на ядро.
Может... потому что их не выпускают? Те, кто могут себе сейчас позволить отличные от x86 ядра, навскидку: мобильные (Apple, Nintendo/nVIDIA) и дата-центры (Amazon AWS). Ни тем ни другим высокие частоты не нужны. Там еще у Power10 до 4 ГГц заявлены, но у Самсунга не самый удачный техпроцесс.
частота ядер низкая, а вот частота DDR значительно выше
и вот тут есть огроменный такой подводный камень- сам чип памяти внутри работает на достаточно низкой частоте, чот типа условных 400 мегагерц. подключили линии к vref, подождали, пока оно зарядится, подключили их к ячейкам, подождали, потом ацп там когда-нибудь померяют, что там было в ячейках, потом эти данные еще по чипу доползут до сериализатора, и вот он наконец-то выдаст на всех тех гигагерцах их внаружу. и поехали все снова, не забыв подождать, пока чип запишет прочитанные из ячеек данные обратно (потому что чтение их уничтожает). там просто параллельно (но медленно) читается много данных, и потом уже быстро выдается внаружу.
а лечится кэшами, да. коих сейчас все стали втыкать прям много. даже на видеокартах.
Забавное наблюдение: берём эти самые тайминги разных плашек памяти разного типа (речь за CAS Latency и все виды ОЗУ от SDRAM до DDR6), переводим указанные такты в абсолютное время, помножив на длину периода рабочей частоты и получаем числа примерно одного порядка. За последние 20+ лет физику заряда конденсаторов победить не удалось. Решают по классике: расширяя пакет одновременного доступа к матрице памяти и ускорение выдачи всего этого пакета в интерфейс.
ну так. физика же, ее победить сложно. разве что ацп стали побыстрее, почувствительнее да поточнее. вот и вся разница. но зато емкость ячеек стала ниже (:
Ну строго говоря не 20 лет, а примерно со времён 386, т.е. аккурат 40. В скорость конденсаторов DRAM упёрлись примерно тогда, и у старших 386 появился - тадам - кэш первого уровня, тогда ещё на материнке.
С другой стороны, был один фактор, который использовали на полную. А именно, напряжение. Скорость заряда/разряда конденсатора на dU прямо пропорциональна этому dU. Вот его постепенно и снижали, всего удалось примерно в 4 раза (с ~4.5В времён TTL до ~1.1 в DDR5). Правда, современные ~1.1V в DDR5 это уже слишком мало для надёжной передачи по шине, приходится поднимать...
Там ещё и с самой ёмкостью конденсатора игрались, меняя его геометрию. Удалось несколько поднять частоту, но это потребовало и уменьшение периода рефреша. Но начиная как раз примерно с SDRAM уже никакой особой революции именно в самой матрице уже не происходило, до недавних многоуровниевых. Поэтому я и ограничил срок 20 годами. А так да, первый кеш появился даже не в 386, а в 8086. Дада, пайплайн на 16 байт есть уже в 8086. Он, правда, тупой, обычная предвыборка исполняемого кода (обращения к ОЗУ за данными происходили непосредственно), но он позволял повысить скорость исполнения программы на определённый процент. Особенно у урезанного по шине варианта 8088.
Ну в 8086 профит от "кэша" был не в том, что он быстрее ОЗУ, а просто в освобождении шины для чтения/записи операндов.
И да, НЯП он был не 16 байт, а всего 6 (самая длинная инструкция 8086 как раз и занимала 6 байт). Это довольно элементарно проверялось самомодифицирующимся кодом, потому что этот "кэш" не отслеживал запись в память. Т.е. модификация ближайшей или следующей за ней инструкции изменяла память, но процессор выполнял старые инструкции.
Хм, действительно 6. Значит, меня покусал Манделла.
Ну в 8086 профит от "кэша" был не в том, что он быстрее ОЗУ, а просто в освобождении шины для чтения/записи операндов.
И более плотная загрузка медленной шины для исключения простоя когда ядру процессора шина не нужна (например, во время переваривания опкода).
Хм, действительно 6
А у урезанного по шине варианта 8088 - вообще четыре :Р
Казалось бы - нафига?...
Этот вопрос, видимо, им часто задавали, поэтому они на него даже отвечали когда-то: дескать, они изготавливали разные опытные кристаллы с разными же размерами этого префетч-буфера. И выяснили эмпирическим путём, что буфер больше шести байт для 8086 и больше четырёх для 8088 производительность не увеличивает.
Короткие операции фиксированной длины можно быстрее скармливать процессору.
зато код менее компактный, соответственно, в случае промаха предсказателя переходов больше из памяти доставать
зато код менее компактный
Цифры здесь говорят о том, что на x86 переменная длина инструкций не особо помогает.
Объясняю популярно, к примеру берем инструкцию x86_64:
ADD [RBX + RAX *8], 0xFFFFFF
5 инстуркции RISC-V против 1 инструкции CISC
Вопрос лишь в том, насколько часто такие инструкции как ADD [RBX + RAX *8], 0xFFFFFF будут встречаться в реальных программах. Мне почему-то думается что не очень. Идея RISC ведь тоже появилась не абы как. Были проанализированы сотни мегабайт реального кода, выдаваемого компиляторами. И уже на основе этого анализа оставлено только наиболее употребительное.
А ещё, для повышения эффективности кода к его размеру у РУКИ применено кодирование типа БОЛЬШОЙ_ПАЛЕЦ, где одно слово хранит сразу две команды (одна команда длиной в полуслово). Этот же трюк позволяет фетчить опкоды практически на 2х скорости на той же частоте. К тому же, при большой разнице между скоростями памяти и ядра, добавляется конвеер/очередь а выборка из памяти идёт ещё большей порцией за раз. Например, у STM32 внутренняя FLASH 64 бита (128 бит у быстрых серий) при 32 битной шине AHB.
данные во внутренних регистрах процессора сами по себе не окажуться, поэтому любые данные вначале загружаются в оперативную память, а потом загружаются во внутренние регистры; инструкция ADD - это пример, вместо нее может быть любая другая подобная инструкция
К слову, RISC это про уменьшеный набор команд и не подразумевает обязательное выполнение каждой команды за 1 такт, хотя конвеер обычно старается соблюдать это правило. Но вот, например, если взять MIPS R3000, то у него почти все команды однотактовые, а вот команды условного перехода или возврата их подпрограммы 2 такта. Но чтобы не обнулять конвеер зазря, у них сам переход происходит после выполнения следующей команды, параллельно с которой происходит суждение о переходе. Т.е. условная конструкция типа:
beq label ; или любой другой переход
nop ; эта инструкция будет исполнена в любом случаеЭто называется "branch delay slot". Компиляторы обычно туда ставят "nop", но в теории можно воткнуть любую однотактовую инструкцию. Или ещё есть так называемый "load delay slot" при загрузке из памяти в регистр:
lb v0, data(t0)
nop ; в v0 ещё ничего нет, содержимое будет доступно только следующей инструкцииБольше есть тут: https://habr.com/ru/articles/756314/
если сравнивать, то CISC - это экскаватор, а RISC - это лопата
VLIW и увеличение разрядности шины данных до ширины VLIW решает эту проблему ценой своей громоздкости, да.
PS Это ответ на опус, который автор перенёс из предыдущего поста сюда: https://habr.com/ru/articles/922974/comments/#comment_28502618
ну плашки памяти у вас все равно 64 битные, там профит в другом
Кто это сказал? Я могу использовать любой формат, если захочу.
PS Плашки 72 бита, если не использовать ЕСС.
PPS Нехорошо кардинально редактировать пост после появления ответа на него.
VLIW это максимально расточительное и нерациональное использование вычислительных элементов ядра.
del
История про то как архитектура становится политикой, а процессор, точкой напряжения между странами
и в том самом крупном плане
Хоть бы фотографию приложили
Неудачное всё-таки у него название, всё-равно читается как "риск ви". Надо бы поменять на нормальное "RISC-5".
А ещё Китай сделала свой вариант - RISC-X - чтобы ей не запретили открытую RISC-V.
Анджелина Джоли была права насчёт компьютеров