Русский
Русский
English
Статистика
Реклама

Risc

Перевод ARMv9 в чем преимущество?

06.04.2021 18:11:06 | Автор: admin

Что такое масштабируемые векторные расширения (Scalable Vector Extension)? Что они значат для индустрии и пользователей?

Если вы пользуетесь мобильным телефоном, то скорее вы знаете, что такое процессор ARM. Он является сердцем вашего смартфона, а недавно появился в новом поколении Mac. Процессоры ARM также появляются в серверах.

Мы находимся на пороге серьезных изменений в индустрии, которых не происходило уже несколько десятилетий. x86 доминирует в компьютерной индустрии уже продолжительное время, но активное развитие ARM, вероятно, станет серьезной проблемой для x86.

В этом году ARM выпустила архитектуру следующего поколения, которая задаст курс отрасли на следующее десятилетие, ARMv9. Это важное событие, которое заслуживает пристального внимания.

Есть много вещей, о которых стоит поговорить, но наиболее важной темой является стандартизация того, что мы называем масштабируемым векторным расширением (Scalable Vector Extension 2, SVE2). Вы наверняка слышали про наборы инструкций SIMD (Single Instruction Multiple Data, одиночный поток инструкций, множественный поток данных), такие как MMX, SSE, AVX, AVX-512 от Intel или Neon от ARM. Однако вы можете не знать, для чего они нужны. Я постараюсь объяснить, что отличает SVE/SVE2 от более старых наборов инструкций SIMD.

Знали ли вы, что Fujitsu сыграла важную роль во всем этом? Мы наблюдаем своего рода возвращение к супервычислениям старой школы, которые встречались в суперкомпьютерах Cray-1 несколько десятилетий назад. Фактически компания Cray не умерла и сейчас занимается созданием суперкомпьютеров на базе ARM: LRZ to Deploy HPEs Cray CS500 System with Arm Fujitsu A64FX Processors.

Суперкомпьютер Cray-1, 1976 год. Высота примерно 1.8м, диаметр 2.1м.

ARMv9 это процессор, который я могу купить в магазине?


Это не то же самое, когда Intel или AMD выпускают новый микропроцессор, который вы можете купить и установить в ПК для повышения производительности. ARMv9 не имеет физического воплощения. Это новая микропроцессорная архитектура, которая обратно совместима с предыдущими поколениями ARM, такими как ARMv8.

Позвольте мне объяснить, как это работает. Множество компаний по всему миру, таких как Qualcomm, Apple, Fujitsu Ampere Computing, Amazon, проектируют собственные микропроцессоры. Это многоступенчатый процесс. Например, ни Apple, ни AMD не производят собственные чипы. Вместо этого они разрабатывают дизайн микросхемы, а затем отправляют его на заводы, например, Global Foundries или TSMC. Там дизайн травят на кремниевых пластинах, которые затем разрезают на отдельные микрочипы и упаковывают.

Компания ARM Ltd. не похожа на Qualcomm или Ampere Computing. Они не производят готовые чертежи, которые можно передавать на завод. Вместо этого они продают чертежи интеллектуальных блоков. Компании вроде Apple могут купить эти блоки и объединить их в итоговый чертеж, который отправится на фабрики.

Система-на-Кристалле ARM Neoverse N1, произведенная TSMC
Но это все очень вариативно. Например, у вас есть чертежи реальных микропроцессорных ядер, таких как Neoverse N1. Другая компания может купить этот дизайн, открыть в инструментах для проектирования, скопировать четыре ядра, нарисовать несколько линий соединения, добавить кэш-памяти, и вот у них получился новый микропроцессор. В реальной жизни этот процесс, конечно, сложнее, но основную мысль, думаю, вы поняли.

ARMv9, как и предыдущий ARMv8, не законченный чертеж, который регламентирует соединение транзисторов. Это то, как вы размещаете транзисторы для достижения высокопроизводительной архитектуры. Мы называем это микроархитектурой.


ARMv9 больше похожа на договоренность между разработчиками компиляторов и архитекторами аппаратного обеспечения. Это своего рода соглашение о том, как в итоге должен выглядеть каждый конкретный процессор ARM. Какие инструкции нужно поддерживать и как они будут работать. Но в соглашении ничего не говорится о том, как это достигается с точки зрения транзисторов.

ARMv9 это архитектура центрального процессора, что-то более абстрактное. Это похоже на соглашение между аппаратным и программным обеспечением. Архитектура обозначает, какие регистры должны быть на микропроцессоре и сколько бит они должны содержать, какие инструкции необходимо поддерживать и куда записывать результат после выполнения инструкции.

Пример инструкций для загрузки чисел из памяти по адресам 14 и 23 в регистры x1 и x2 соответственно, сложения содержимого регистров и записи результата в x3.

load x1, 14       ; x1  memory[14]load x2, 24       ; x2  memory[24]add  x3, x1, x2   ; x3  x1 + x2

Чтобы узнать больше, читайте: How Does a Modern Microprocessor Work?

Архитектура процессора важна для разработчиков инструментов. Программное обеспечение, такое как компиляторы и линковщики, работает с заданной архитектурой. Это значит, что выпуск ARMv9 равнозначен выпуску нового стандарта для разработчиков программного и аппаратного обеспечения. Пока Apple, Ampere и Qualcomm производят оборудование, которое понимает инструкции, указанные в спецификации ARMv9, программное обеспечение, производящее код для этой спецификации, будет работать.

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

Что нового в ARMv9?


Чтобы показать, насколько большой вклад производит выпуск новой архитектуры, мы вспомним про ARMv8. ARMv8 была выпущена восемь лет назад и стала первой 64-битной архитектурой компании ARM Ltd. Микропроцессоры на базе ARMv7 были 32-битными. Это означало, что регистры внутри ЦП могли работать только с числами, которые содержали не более 32 двоичных цифр.

Появление ARMv8 было важным событием для Apple, так как это позволило им неожиданно рано для индустрии перейти на 64-битную архитектуру. Это дало iPhone и iPad фору. Несомненно, Apple хотела заниматься высокопроизводительными архитектурами как можно быстрее, поэтому они стремились создать процессоры ARM для настольных компьютеров.

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

ARMv9 это все про суперкомпьютеры. Вы можете подумать, что для вас как для пользователя телефона и настольного компьютера, это не имеет значения. Но вы ошибаетесь.

Я не рассказал, что такого особенного в векторах и что это такое. Они имеют большое значение для науки. Старые суперкомпьютеры, такие как Cray-1, были созданы для векторной обработки, то есть для обработки огромного количества векторов.

Когда я был подростком и читал о компьютерах Cray, я не понимал, что это значит. Раньше я фантазировал со своими друзьями о том, какую частоту кадров в секунду мы получим, играя в DOOM на Cray. Но, вероятно, мы бы не заметили разницы. Cray был хорош в научных вычисления, таких как прогнозирование погоды, всевозможные виды анализа и обработки данных. Все, что связано с огромными таблицами данных с большим количеством строк и столбцов, выигрывает от векторной обработки.

Именно это приходит в ARMv9 благодаря добавлению целого ряда новых инструкций, которые называются SVE2, или Scalable Vector Extension 2. Другими словами, процессоры ARM становятся все более похожими на старые суперкомпьютеры.

Для дополнительного чтения: ARM, x86 and RISC-V Microprocessors Compared.

Суперкомпьютер в кармане


Почему ARM сегодня выбирает архитектуру как у суперкомпьютеров? Что происходит?

Вы заметили, что такие вещи, как распознавание лиц и речи, автопилот и машинное обучение стали более распространенными? У вас есть умные помощники, такие как Siri, которые информируют вас о встречах и отвечают на вопросы. Сейчас это может показаться привычным, но вы задумывались, как раньше работали такие решения?

Всякие раз, когда вы что-то говорите своему цифровому помощнику, запись отправляется по сети в облако, где суперкомпьютер анализирует ваш голос, определяет, что вы сказали, и отправляет результат обратно на ваш телефон. Сегодня мы пытаемся распространить этот интеллект на большое количество устройств. Однако не все устройства могут иметь высокоскоростное подключение к интернету.

Кроме того, пользователи не хотят всегда быть подключенными к интернету, чтобы взаимодействовать со своими цифровыми помощниками, выполнять задачи распознавания речи и лиц. Мы хотим, чтобы эти задачи выполнялись на более дешевых и распространенных устройствах. Оказывается, эти задачи похожи на те, что решал Cray-1. Таким образом, все новое это хорошо забытое старое.

Читать далее: RISC-V Vector Instructions vs ARM and x86 SIMD.

ARM и высокопроизводительные вычисления


Следующим шагом после настольных компьютеров и серверов, естественно, являются высокопроизводительные вычисления (High Performance Computing, HPC). Настоящие суперкомпьютеры. В далеком прошлом в этом сегменте доминировали специальные аппаратные решения, такие как ARM, а затем появились крупные центры обработки данных с серийным оборудованием x86 и мощными видеокартами.

Intel и AMD хорошо зарабатывают на этом рынке, поскольку машинное обучение и анализ данных стали гораздо более распространенными и важными. Естественно, ARM хочет получить кусок этого рынка. Первым серьезным шагом стал микропроцессор Fujitsu A64FX на базе ARM.

У Fujitsu есть опыт построения Cray-подобных компьютеров с векторной обработкой. Они объединились с ARM, чтобы расширить процессоры ARM набором инструкций Scalable Vector Extension. Таким образом, это не изобретение ARM, а адаптация уже существующего набора инструкций для высокопроизводительных вычислений к процессорам ARM.

Эта комбинация, используемая для A64FX, стала основной для создания самого мощного суперкомпьютера в мире: Japans Fugaku gains title as worlds fastest supercomputer.

Процессор A64FX на архитектуре ARMv8, разработанный Fujitsu для высокопроизводительных вычислений. Это первый процессор с Scalable Vector Extension.

Но следует помнить об одном важном факте: это было расширением и не является частью спецификации ARMv8. То есть ваши iPhone или iPad с процессором на ARMv8 не может запускать код, созданный для суперкомпьютера Fugaku, потому что у них нет поддержки инструкций SVE.

Для сравнения, в ARMv9 такие инструкции стали частью стандарта. Именно поэтому я говорю, что ARM кладут суперкомпьютер в карман.

Но есть и более сложная история, которая требует более подробного рассмотрения. Как видите, ARM предлагает создавать процессоры, которые способны выполнять один и тот же код вне зависимости от их стоимости и мощности.

Они делают это таким образом, что прирост производительности обычного кода может превышать определенные ранее пределы. Подобные вещи невозможны с решениями, которые Intel и AMD использовали с инструкциями AVX для своих микропроцессоров x86.

Чтобы лучше понять почему, нам нужно рассмотреть различия и сходства между векторной обработкой и инструкциями SIMD. Но сначала рассмотрим, что такое вектор.


Вы можете смотреть на векторы по-разному. Например, как на набор цифр. Но на самом деле они указывают направление в пространстве, как стрелки. Координаты (x, y) точки указывают, где находится точка. Координаты (x, y) вектора указывают, как далеко растягивается вектор по осям. Причина, по которой векторы могут иметь больше чисел, заключается в том, что они не ограничены двухмерным или трехмерным пространством. Они могут существовать в воображаемом пространстве с сотнями, если не тысячами, измерений. В математике возможно все, что вы можете вообразить.

Что такое вектор?


Вектор это просто причудливый математический термин для списка чисел. Например:

[3, 5, 9]

Удобно работать со списками чисел, обращаясь к ним по имени или иному идентификатору. Например, два вектора с именами v1 и v2.

v1  [3, 2, 1]      v2  [1, 2, 2]

И вот способ выразить, что я складываю векторы и сохраняю результат в v3.

v3  v1 + v2  ; v3 должен быть [4, 4, 3]

Почему я использую стрелки ()? Это полезно при объяснении того, что происходит внутри компьютера, потому что обычно мы храним числа в некоторой области памяти. Эта память может быть пронумерована или названа. Внутри микропроцессора есть небольшая область памяти, которая разделена на фрагменты, называемые регистрами. В микропроцессорах ARM эти регистры имеют имена, такие как x0, x1, , x31 или v0, v1, , v31.

Чтобы иметь возможность выполнять операции сложения, вычитания или умножения, числа необходимо перенести из памяти в один из регистров. Вы не можете работать с числами, хранящимися в основной памяти. Процессор выполняет операции только над содержимым регистров.


Упрощенная схема микропроцессора. Числа из памяти передаются по цветным линиям, которые называются шинами. Регистры подают числа на вход математическим сопроцессорам или другим блокам, которые выполняют вычислительные операции.

Противоположность векторам скалярная величина. Это причудливое словосочетание для отдельных чисел. Итак, простой пример для скалярных операций с использованием стрелочной нотации.

x1  3        ; записать 3 в x1x2  4        ; записать 4 в x2x2  x1 + x2  ; сложение x1 и x2 дает 7

Векторы используются для многих вещей. Даже если вы не программист, вероятно, вы использовали приложение для работы с таблицами, например, Microsoft Excel. Столбец в таблице можно рассматривать как вектор. Обычно мы рассматриваем его как один логический элемент. Например, мы можем сложить все элементы в столбце или добавлять каждую ячейку столбца с каждой ячейкой на той же строке, но в другом столбце. Примерно это происходит внутри процессора, когда мы складываем два вектора. Вместе несколько столбцов образовывают таблицы. Говоря математическим языком, несколько векторов образуют матрицы. То есть набор чисел, организованных в строки и столбцы.

Представьте, что столбцы Amount и Unit Cost это векторы. Столбец Total Cost это результат поэлементного математического вычисления двух векторов.

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

Хотя современные компьютеры обычно не работают с матрицами, вычисления на матрицах можно ускорить с помощью векторов. Вот почему векторные инструкции важны для ускорения машинного обучения, распознавания изображений и речи. Математика векторов и матриц называется линейной алгеброй. У меня есть вступление для любопытных: The Core Idea of Linear Algebra.

Но не будем углубляться в математику. То, что нам нужно, связано с микропроцессорами. Инструкции в современном микропроцессоре, используемые для работы с векторами, называются SIMD.

SIMD против векторных инструкций


Технически ARM Neon и SVE являются формой SIMD (Single Instruction Multiple Data). Под этими инструкциями мы подразумеваем такие вещи, как сложение, вычитание и умножение. Таким образом, основная идея SIMD заключается в том, что вы отправляете одну инструкцию для процессора, а он выполняет одну и ту же операцию с несколькими значениями одновременно.

Один поток инструкций, один поток данных (SISD) и один поток инструкций множественные потоки данных (SIMD)
Подобные наборы инструкций существуют уже некоторое время. Вы, наверное, слышали про наборы инструкций MMX, SSE, а теперь и AVX на микропроцессорах x86 Intel и AMD. Они были созданы, чтобы выполнять обработку мультимедиа, такую как кодирование и декодирование видео. Инструкции ARM Neon наиболее похожи на них. Эти инструкции выглядят так:

LDR v0, [x4]    ; v0  memory[x4]LDR v1, [x6]    ; v1  memory[x6]ADD v4.16B, v0.16B, v1.16B STR v4, [x8]    ; v4  memory[x8]

В этом примере скалярные регистры x4, x6 и x8 содержат адреса в памяти, по которым располагаются числа в памяти.

Инструкция LDR загружает числа из памяти в регистр. Инструкция STR делает обратное: записывает числа из регистра в память.

Инструкция ADD выглядит странно. Почему там есть суффикс .16B после имени каждого регистра?

Дорожки в векторной обработке


Векторные регистры, такие как v0 и v1, имеют размер 128 бит. Что это значит? По сути, это максимальное количество двоичных разрядов, которые может содержать векторный регистр.

Это устанавливает верхний предел того, над сколькими числами мы можем выполнять операцию одновременно и сколько двоичных разрядов может иметь каждое из этих чисел. Например, если вы хотите складывать 64-битные числа, то вы сможете работать только с двумя, потому что в 128-битный регистр их помещается только два. Однако если числа будут меньше, то вы сможете уместить их больше. Например, при работе со значениями цвета мы обычно представляем компоненты красного, зеленого и синего как 8-битные значения. В 128-битный регистр их поместится 16.

128/8 = 16

Это должно дать вам подсказку. 16B обозначает шестнадцать байтовых элементов. Попробуйте угадать, что означает эта инструкция сложения.

ADD v4.2D, v0.2D, v1.2D

В терминах микропроцессора мы называем 32-битное число машинным словом (word), а 64-битное число двойным машинным словом (double-word). Таким образом, .2D означает два двойных слова, а .4S четыре одинарных.

128/32 = 4

Но почему эти суффиксы есть только у инструкции сложения? Почему нет у инструкций загрузки и сохранения? Потому что при работе с памятью нам не нужно рассматривать векторный регистр как состоящий из нескольких элементов.

Количество элементов, на которые мы разбиваем регистр во время вычисления, определяет, сколько дорожек будет настроено для вычислений. Подумайте о дороге, где числа, словно машины, идут параллельно по нескольким полосам. Ниже приведен пример этого. У нас есть регистры v1 и v2, которые используют для вычислений, а результат сохраняется в регистр v3. Таким образом, мы разбиваем на два элемента (.2D), и у нас есть две дорожки для вычислений. Каждая дорожка получает одно арифметико-логическое устройство (АЛУ).

Сколько АЛУ используется в SIMD-вычислениях. У нас есть две дорожки вычислений. Каждая дорожка обслуживается одним АЛУ.

Если вам не нравятся мои иллюстрации, то вот иллюстрация ARM, которая демонстрирует задумку на четырех дорожках.

Сложение регистров v8 и v9 с четырьмя дорожками

Проблемы с инструкциями SIMD


Инструкции SIMD, подобные тем, которые вы видите ниже, могут выполняться с разными аргументами.

ADD v4.2D, v0.2D, v1.2D ADD v4.4S, v0.4S, v1.4S

Однако они кодируются как отдельные инструкции. Это быстро выходит из-под контроля, что хорошо видно на примере x86. Intel начала с MMX, затем появились SSE, SSE2, AVX, AVX2 и наконец AVX-512. MMX, например, имел 64-битные векторные регистры, поэтому вы могли выполнять параллельную работу над двумя 32-битными регистрами или восемью 8-битными.

Со временем, когда транзисторов становилось все больше, было принято решение сделать новые векторные регистры большего размера. Например, SSE2 имеет 128-битные регистры. В конце концов этого оказалось недостаточно, и мы получили AVX, а AVX2 предоставил нам 256-битные регистры. Теперь, наконец, AVX-512 представил нам невероятные 512-битные регистры. Итак, теперь мы можем вычислять шестьдесят четыре 8-битных значения цвета параллельно.

Каждый раз, когда Intel делала доступными регистры большего размера, им приходилось добавлять множество новых инструкций. Почему? Потому что длина векторного регистра прописана в инструкции SIMD. Например, инструкция ADD потребуется для:

  1. Каждого регистра длиной 64, 128, 256 или 512 бит.
  2. Для каждого из регистров нужен отдельный вариант с нужным числом дорожек.

Таким образом, добавление инструкций SIMD привело к резкому увеличению числа инструкций, особенно для x86. И конечно же, не каждый процессор поддерживает эти инструкции. Только новые будут поддерживать AVX-512.

Почему ARM не следует стратегии AMD и Intel


Эта стратегия не работает для ARM. У Intel и AMD простая миссия. Они просто пытаются сделать самые мощные узкоспециализированные процессоры, которые они могут выпустить в любое время в магазин.

ARM, напротив, пытается удовлетворить широкий спектр потребностей. ARM работает как на крошечных встраиваемых устройствах, так и на суперкомпьютерах, таких как Fugaku. ARM может предложить дизайн процессора для сервера с использованием 512-битных векторов, но его поддержка на крошечном ARM, предназначенном для работы в бюджетном телефоне, будет невозможна. Конечно, ARM может сделать доступным множество различных наборов инструкций.

И действительно, ARM предлагает разные профили для разных сегментов рынка. Но ARM по-прежнему заинтересованы в том, чтобы одно программное обеспечение могло работать с широким спектром их процессоров.

SVE и SVE2 позволяют ARM задавать разную физическую длину векторных регистров для каждого типа микросхем. В SVE/SVE2 векторный регистр должен иметь длину от 128 до 2048 бит. Для смартфоном с низким энергопотреблением они могут продавать дизайны с 128-битными векторными регистрами, а для суперкомпьютеров с 2048-битными.

Красота SVE в том, что один код будет работать как на суперкомпьютере, так и на дешевом телефоне. Это невозможно с инструкциями SIMD x86. Хотя я не являюсь экспертом по асемблерному коду ARM, судя по тому, как выглядит код при использовании Neon и SVE, мне кажется, что последний будет более эффективным даже при равной длине векторного регистра.

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

SVE в действии


Если мы посмотрим на инструкции Neon, то они кодируют количество дорожек так же, как указано в предыдущем примере.

ADD v4.2D, v0.2D, v1.2D ADD v4.4S, v0.4S, v1.4S

Но если мы переведем это в инструкции SVE, то мы увидим что-то подобное.

ADD v4.D, v0.D, v1.D ADD v4.S, v0.S, v1.S

Это означает, что мы больше не указываем, сколько дорожек вычислений мы выполняем. Используя инструкции SVE при компиляции, мы не знаем, сколько дорожек будет использоваться, поскольку не знаем длину векторного регистра.

Предикация


Вместо этого в SVE используется то, что мы называем предикацией. Есть набор специальных регистров p0, p1, , p15, которые работают как маски для вычислительных дорожек. Их можно использовать для включения или выключения дорожек. Таким образом, использовавшаяся ранее инструкция сложения выглядела бы так:

ADD v4.D, p0/M, v0.D, v1.D

Теперь у нас есть дополнительный аргумент p0/M, который позволяет процессору сохранять результаты сложения v0 и v1 в v4 только когда соответствующий элемент p0 равен логической единице (истина). В псевдокоде это выглядит следующим образом.

while i < N   if p0[i] == 1      v4[i] = v0[i] + v1[i]   else      v4[i] = v0[i]   end   i += 1end

Регистр предикатов используется, например, для загрузки и сохранения данных. Пример для загрузки данных из памяти.

LD1D z1.D, p0/Z, [x1, x3, LSL #3]

Здесь происходит несколько процессов, поэтому необходимо некоторое объяснение. [x1, x3, LSL #3] это типичный для ARM способ указания адреса памяти. Это можно прочесть так:

base_address = x1 + x3*2^3z1  memory[base_address]

Но поскольку мы используем предикат, то это не совсем правильно. Нам нужно отфильтровать то, что загружается. Более точно это выглядит так:

base = x1 + x3*2^3while i < N   if p0[i] == 1      v1[i] = memory[base + i]   else      v1[i] = 0   end   i += 1end

Эта концепция с масками существует во многих языках высокого уровня например, в Python, R и Julia. Пример на языке высокого уровня может помочь донести идею. Пример из командной строки Julia, но должно быть аналогично в Python и R.

julia> mask = [false, true, true, false];julia> A = [2, 4, 8, 10];julia> B = [1, 3, 7, 9];julia> A[mask]2-element Vector{Int64}: 4 8 julia> B[[true, false, false, true]]2-element Vector{Int64}: 1 9 julia> A[mask] + B[mask]2-element Vector{Int64}:  7 15

В этом примере вы видите, что у нас есть векторы с четырьмя элементами. Мы используем маску, аналогичную регистрам предикатов, для выбора двух средних элементов.

Таким образом, мы можем выполнить сложение только двух средних значений.

Как работать с вектором неизвестной длины


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

Это помогает нам значительно упростить код векторной обработки и избежать необходимости знать точную длину вектора. Допустим, нам нужно обработать шесть 32-битных значений. То есть N = 6, и это единственное, что вы знаете во время компиляции. Инструкции Neon будут выглядеть так:

ADD v4.4S, v0.4S, v1.4S  ; v4  v0 + v1

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

С SVE этого делать не придется. Вместо этого нам приходит на помощь волшебная инструкция WHILELT. Вот пример:

WHILELT p3.s, x1, x4

Но что она делает? Я объясню на примере псевдокода. Допустим, есть M дорожек для векторной обработки. Вы не знаете значение M до начала выполнения, но, допустим, что M = 4. Тем не менее, мы знаем количество элементов, которые хотим обработать, то есть N = x4 = 6. Инструкция WHILELT (WHILE Less Than, пока меньше чем) работает так:

i = 0while i < M   if x1 < x4      p3[i] = 1   else      p3[i] = 0  end  i += 1  x1 += 1end

Таким образом, если мы представим выполнение этих векторных операций в цикле, то на первой итерации p3 будет выглядеть так:

x1 = 0p3 = [1, 1, 1, 1]

На второй итерации в какой-то момент x1 станет больше, чем x4, поэтому получаем следующее:

p3 = [1, 1, 0, 0]

Таким образом, в коде не нужно явно указывать, на скольких дорожках мы работаем. Инструкция WHILELT гарантирует, что все дорожки включены, пока мы не дойдем до конца.

Так работает вся обработка SIMD. Вы обрабатываете партии чисел. Так, например, если вам нужно обработать 20 элементов, а ваш векторный регистр вмещает 4 дорожки, то вы можете сделать всю работу за 5 итераций (54 = 20). Но что если у вас 22 элемента?

Вы не можете выполнить полный пакет из четырех элементов. Таким образом, вам нужно доделать остатки вручную, по одному элементу за раз. С регистрами предикатов такой проблемы нет. Вы просто убираете из маски последние элементы. Это работает и с записью элементов в память.

Операции загрузки и сохранения


Другой важной особенностью SVE-инструкций является поддержка того, что мы называем операциями сборки-разборки (gather-scatter). Это означает, что вы можете заполнить векторный регистр данными, которые распределены по нескольким ячейкам памяти, всего за одну операцию. Точно так же вы можете записывать результаты из вектора в несколько местоположений. Принцип аналогичен тому, что мы обсуждали с предикатами.

Почему это полезно? В языках программирования более высокого уровня данные хранятся обычно следующим образом.

struct Sale {    int unit_price;    int sold_units;    int tax;}Sale sales[1000];

Допустим, у нас тысячи таких объектов. Обычно мы хотим проводить расчеты между связанными полями. Например, умножить цену unit_price на количество проданных единиц sold_units. Это значит, что вы хотите, чтобы в одном векторном регистра были цены за единицу, а в другом количество проданных единиц. Однако значения этих полей не лежат в памяти последовательно. Они чередуются.

Есть много таких деталей, которые позволяют применять SVE-инструкции к гораздо большее разнообразному коду. Можно векторизовать больше циклов for, что дает больше возможностей для повышения производительности.

Что предлагает SVE2?


Здесь, вы, естественно, задаетесь вопросом, а что добавляет SVE2, чего еще нет в SVE?

Расширение SVE было необязательным для архитектуры ARMv8. В то время SVE2 это часть стандарта. Это означает, что Neon и SVE получили еще более тесную интеграцию. В SVE добавлены инструкции, которые делают SVE2 заменой Neon. Теперь вы можете делать все, в чем был хорош Neon с помощью SVE2.

Помните, SVE создавался только для суперкомпьютерных вещей, а для мультимедийных рабочих нагрузок, для которых создавался Neon? Мультимедийным материалам обычно не нужны длинные регистры. Рассмотрим цветной пиксель, закодированный как RGBA. Это четыре 8-битных значения, которые помещаются в 32-битный регистр.


Каждый пиксель состоит из четырех компонент: красный, зеленый, синий цвета и прозрачность. Каждый байт должен вычисляться независимо. Мы можем сделать это, используя 32-битный векторный регистр с 4 дорожками.

Однако с SVE2 эти задачи, которые больше подходят для коротких векторных регистров, также хорошо работают с векторными регистрами с переменной длиной.

Это дает ARM отличный набор инструкций, который может работать как с наиболее энергоэффективными, так и с наиболее производительными микросхемами. При этом пользователям необходимо выполнить компиляцию только один раз. Помимо этого, получается более простой код с точки зрения компилятора. А ARM не нужно участвовать в этой гонке вооружений с инструкциями SIMD, в которой участвуют Intel и AMD.

Им не нужно каждые несколько лет добавлять множество новых SIMD-инструкций. SVE2 дает фундамент с большой стабильностью и хорошим пространством для роста.

Последствия для пользователей, разработчиков и отрасли


Для разработчиков это значит, что написание и оптимизация кода ARM станет проще. Разработка программ для машинного обучения, распознавания лиц и голоса станет проще. Не придется беспокоиться, поддерживает ли целевая платформа нужные инструкции.

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

ARM также будет все больше вытеснять Intel и AMD из прибыльного бизнеса в центрах обработки данных. Я не являюсь экспертом по дизайну микросхем, но, видя, как RISC-V использует этот набор инструкций и понимает все преимущества, мне кажется, что Intel и AMD совершили ошибку, когда отказались от ARM. Их стратегия с SIMD не кажется мне разумной. Подозреваю, что эта ошибка будет их преследовать.

Подробнее..

IMac G5 ретроспектива

30.11.2020 18:20:43 | Автор: admin

Привет человеки,
Все течет все изменяется, вот и эра эпл на базе x86 совместимых процессоров подходит к концу.
А я хочу устроить некоторую ретроспективу и познакомить Вас с последним представителем линейки iMac на базе RISC процессора PowerPC 970, самое интересное, что устройство вставшее в строй 15 лет назад еще что-то может и вполне работоспособно. Такие задачи как: набор текста, прослушивание музыки, чтение этих ваших интернетов (с некоторыми ограничениями), все это возможно на данном устройстве. А так же рассмотрим характеристики и не погнушаемся разобрать сей компьютер.


Итак 2005 год, на рынке ПК превалирует Intel со своими Pentium 4 Extreme, AMD выступает с вполне приличным Athlon 4800+, Nokia выпускает бешеный коммуникатор раскладушку Nokia 9300i, а до выхода первого Iphone остается еще 2 года, но работы уже идут.
Apple решает отказаться от процессоров PowerPC в пользу Intel. На это было несколько причин, но основные, на мой взгляд, были следующими: во первых, эпл надоело выступать в роли догоняющих поскольку Интел и АМД с каждым годом только увеличивали отрыв в плане производительности, а во вторых PowerPC процессоры имеющие на тот момент сравнимую производительность с дескотопными процессорами от конкурентов, уступали им по энергоэффективности и были довольно горячими, что делало их неконкурентоспособными при использовании в портативных устройствах. Именно тогда выходит в продажу последний iMac G5.

Характеристики


Модель: iMac G5 iSight
ЦП: PowerPC G5 970FX 2.1Ггц шина 700Мгц
Оперативная память: 2,5 ГБ 533 MHz PC2-4200 DDR2
Видеокарта: ATI Radeon X600 XT 128 MB DDR SDRAM PCIE
Жесткий диск: WD 250 ГБ
Привод оптических дисков: CD/DVD-R
Монитор: 20", 1680 1050 widescreen 16:10, 280 cd/m, contrast ratio of 800:1
Сетевые устройства: AirPort Extreme 802.11b/g, 10/100BASE-T Ethernet
Разьемы: 3x USB 2.0, 2x FireWire 400, Audio input/audio output, Mini-VGA
Камера: iSight 640x480
ОС: Mac OS X 10.4.2 Tiger

Внешний вид


Хоть я и не являюсь любителем техники Apple, я не могу не отметить неизменного качества дизайна и исполнения всех современных продуктов этой компании, и iMac G5 не был исключением.



Корпус изготовлен из прозрачного, глянцевого пластика с белой подложкой, как зеркало, только вместо амальгамы белая краска. Этот подход добавляет устройству какого то волшебства, делая его прозрачным по краям. В дизайне компьютера и периферии преобладают округлые формы, все просто и лаконично, никаких вычурных добавок. В плане эргономики вроде тоже все не плохо, но мне не очень понятно решение выноса кнопки включения на тыльную сторону и как мне кажется пару USB портов на торце не помешало бы.
Отличный монитор, насколько я могу судить, яркие, сочные цвета, контраст 800:1, углы обзора до 170 градусов и не плохой запас яркости 280 cd/m.
Операционная система Mac OS X под стать железу элегантна и красива, ничего лишнего. Но с другой стороны она на мой взгляд менее интуитивно понятна, чем Windows. Например, мой сын включил каким то образом аудио сопровождение действий пользователя (помощь для плохо видящих пользователей), а я будучи вполне уверенным в себе пользователем windows так и не нашел как это отключить.

Функционал


Софт установленный по умолчанию вполне достаточен для неприхотливого пользователя. Mail 2, Itunes, Safari, DVD Player, iChat AV, Automator, VoiceOver,Photo View, QuickTime и даже Garage Band.
Работу некоторых приложений я рассмотрел в видео:

Разборка


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

Для того чтобы разобрать iMac G5 нужно открутить 6 винтов в нижней части корпуса.



Далее мы можем извлечь дополнительную планку памяти:



Корпус компьютера открывается как коробка конфет



После этого перед нами предстает LCD панель и защитная, экранирующая пленка



Под плёнкой уже можно обноружить основную плату



Ну а отключив и сняв LCD дисплей мы можем иметь счастье лицезреть ее целиком.
хочу обратить Ваше внимание на два кулера по бокам, один охлаждает жесткий диск,
а второй DVD-привод



К плате крепятся два, довольно массивных радиатора, один для чипсета и один для процессора



Чипсет



Чип видеокарты ATI



Распянные чипы RAM



Процессор PowerPC 970



Возможно родная CMOS батарейка, все еще полностью заряженная



Порты ввода/вывода

Сборка происходила в обратном порядке, как этого и следовало ожидать.

Если интересно, можете посмотреть видео версию разборки и сборки здесь.

Заключение


Как мы убедились iMac G5 отлично сложен и даже не смотря на свой почтенный, для компьютера возраст, все еще может кое что предложить своему пользователю. Интересно, сможет ли похвастаться тем же iMac 2020 года на процессоре от Intel через 15 лет, но тут уж, как говорится: " Поживем увидим"

Всем спасибо за внимание!
Подробнее..

Перевод Почему чип Apple M1 такой быстрый?

23.01.2021 08:13:50 | Автор: admin

Опыт использования новых маков с М1 начинает расставлять точки над i. Эти чипы быстрые. Очень быстрые. Но почему? В чем магия?

Я смотрел видео на Youtube, где автор купил iMac в прошлом году максимальной конфигурации. Машина с 40+ Gb ОЗУ стоила ему около 4000$. Он смотрел с недоверием, как его гипердорогой iMac был разнесен в пух и прах новеньким Mac mini с М1 на борту, который стоил около 700$.

В реальном мире, тест за тестом, макбуки с М1 не просто превосходят топовые компьютеры Intel прошлых поколений. Компьютеры Mac просто уничтожают их. С недоверием люди стали спрашивать, как такое возможно?

Если вы не один из этих людей, то вы пришли в правильное место. Здесь я расскажу простыми словами, что же такого сделали Apple с их М1. Особенно многих интересуют следующие вопросы:

  • В чем техническая причина того, что чип М1 такой быстрый?

  • Сделали ли Apple нечто экзотическое, чтобы добиться такого эффекта?

  • Легко ли будет Intel и AMD сделать то же самое, чтобы оставаться в гонке?

Конечно, вы пробовали гуглить эти вопросы. Если вы попытаетесь понять, что сделали Apple за поверхностными пояснениями, вас очень быстро завалит обилием технического жаргона. Например, М1 использует блоки декодирования (very wide instruction decoders), огромный буфер переупорядочивания (reorder buffer, ROB) и т.д. Если вы не компьютерный гик, то подобные термины будут для вас просто чепухой.

Чтобы полностью погрузиться в тему, рекомендую к прочтению мою статью What Does RISC and CISC Mean in 2020?. В статье я объясняю, что такое микропроцессор CPU, а также разбираю концепции:

  • архитектура набора команд ISA

  • работа конвейера (Pipelining)

  • архитектура хранения и загрузки (load/store)

  • Микрокод vs микро-операции

Но если вы нетерпеливы, я опишу здесь кратко материал, достаточный для понимания этой статьи.

Что такое микропроцессор CPU?

Обычно, когда мы говорим о чипах от Intel или AMD, мы подразумеваем центральный процессор CPU. Как я уже писал в своей статье RISC vs CISC, процессор загружает инструкции из памяти, а затем каждая из них выполняется последовательно.

Очень простой RISC чип, не М1. Инструкции перемещаются из памяти по голубым линиям в регистры. Декодер определяет, чем является каждая инструкция, и активирует различные части CPU через красные линии. ALU складывает и отнимает числа из регистров.Очень простой RISC чип, не М1. Инструкции перемещаются из памяти по голубым линиям в регистры. Декодер определяет, чем является каждая инструкция, и активирует различные части CPU через красные линии. ALU складывает и отнимает числа из регистров.

CPU на самом базовом уровне - это устройство с несколькими именованными ячейками памяти, называемыми регистрами, и некоторым количеством вычислительных юнитов, названных арифметико-вычислительным устройством ALU. ALU выполняет сложение, вычитание и другие простые математические операции. Тем не менее, эти устройства лишь соединены с регистрами CPU. Если вы хотите сложить два числа, то вы должны сначала их получить из памяти, а затем положить в регистры. Ниже приведено несколько примеров типичных инструкций, которые и RISC процессор, и М! В том числе выполняет:

load r1, 150load r2, 200add  r1, r2store r1, 310

Здесь r1 и r2 - это регистры, о которых я говорил ранее. Современные RISC процессоры не способны выполнять операции над числами, которых нет в регистрах. Если даже числа лежат в оперативной памяти, то они все равно недоступны для CPU. Сначала их нужно поместить в два соответствующих регистра. В примере выше мы сначала сохраняем число из ячейки 150 в оперативной памяти в регистр r1, затем делаем то же самое для числа из ячейки 200 и сохраняем в регистре r2. Только после этого числа могут быть сложены инструкцией add.

Старый механический калькулятор с двумя регистрами: регистр для хранения результата (the accumulator) и регистр входящей информации. Современные CPU имеют больше дюжины регистров и они цифровые, а не механические.Старый механический калькулятор с двумя регистрами: регистр для хранения результата (the accumulator) и регистр входящей информации. Современные CPU имеют больше дюжины регистров и они цифровые, а не механические.

Концепция регистров стара. Например, на этом старом калькуляторе регистр - это механизм, который удерживает число, используемое в операции. Прямо как настоящий кассовый аппарат. Регистр - это расположение, где вы регистрируете входящее число.

M1 - это не центральный процессор

Очень важная вещь, которую нужно запомнить: М1 - это не только CPU. Это система множества чипов, лежащих в одной кремниевой обертке. CPU же - это один из этих чипов. Технически, М1 - это весь компьютер на одном чипе. Он содержит CPU, графический процессор GPU, память, контроллеры входа/выхода и множество других вещей, делающих компьютер компьютером. Это мы называем системой на чипе (system on the chip, SoC).

М1- система на чипе. Это значит, что все необходимое для компьютера - уже на чипе.М1- система на чипе. Это значит, что все необходимое для компьютера - уже на чипе.

Сегодня, если вы покупаете чип - Intel или AMD - фактически вы покупаете большое число микропроцессоров в одной обертке. В прошлом у компьютеров было несколько физически отдельных чипов на материнской плате.

Пример материнской платы. Память, CPU, графическая карта, контроллеры входа/выхода, сетевая карта и множество других компонентов присоединены к материнской плате для связи друг с другом.Пример материнской платы. Память, CPU, графическая карта, контроллеры входа/выхода, сетевая карта и множество других компонентов присоединены к материнской плате для связи друг с другом.

Сегодня у нас есть возможность поместить множество транзисторов на один чип, поэтому и Intel и AMD стали производить чипы со множеством микропроцессоров. Мы называем их ядрами процессора. Одно ядро, по сути, это полностью независимый чип, который может читать инструкции и исполнять их. Микрочип с несколькими CPU.

Многоядерный процессор.Многоядерный процессор.

Долгое время это было сутью игры за повышение мощности: просто добавь еще ядер в CPU. Но кто-то взбунтовался в рядах производителей: один игрок на рынке чипов пошёл по своему пути.

Не такой уж засекреченный неоднородный способ вычислений от Apple

Вместо того, чтобы следовать аренду добавления ядер в процессор, Apple выбрала иную стратегию: они стали добавлять больше специализированных процессоров для выполнения конкретных задач. Преимущество заключается в том, что специализированные чипы, как правило, существенно быстрее выполняют свою задачу, затрачивая меньше энергии, чем CPU общего назначения.

Об этом способе было известно давно. Много лет уже как специализированные чипы GPU выполняют определенную задачу - обработку графики. Графические процессоры от Nvidia и AMD делают это гораздо быстрее, чем мог бы делать центральный процессор.

Apple лишь пошла более радикально по этому пути. Вместо множества ядер общего назначения, чип М1 внутри содержит:

  • Центральный процессор CPU - мозги системы на чипе. Выполняет большинство задач компьютера и программ

  • Графический процессор GPU - используется в обработке графики и изображения, в том числе и в играх.

  • Блок обработки изображений ISP - используется для увеличения производительности во время работы приложений по обработке графики.

  • Обработчик цифровых сигналов (digital signal processor, DSP) - Выполняет более сложные математические функции, чем центральный процессор, включая декомпрессию музыкальных файлов.

  • Блок нейронной обработки (Neural processing unit, NPU) - используется в топовых смартфонах, чтобы ускорить работу машинного обучения и AI.

  • Кодировщик видео (Video encoder/decoder) - для энергоэффективного преобразования видео разных форматов.

  • Блок безопасности (Secure Enclave) - шифрование, аутентификация и безопасность.

  • Блок единой памяти (Unified memory) - позволяет модулям чипа взаимодействовать максимально быстро.

Это только часть объяснения, почему люди, которые занимаются видео и графикой на компьютерах с процессором М1, отмечают прирост производительности. Дело в том, что задачи выполняются на том процессоре, который для этого был создан. Это позволяет относительно недорогому Mac mini с М1 на борту обработать графику, даже не вспотев, тогда как дорогой iMac с Intel запускает все свои кулеры охлаждения на полную мощность и все равно отстает от М1. Прочесть больше о неоднородном (heterogeneous) вычислении можно здесь: Apple M1 foreshadows Rise of RISC-V.

Синие блоки - это чипы центрального процессора, а зелёные - графического.Синие блоки - это чипы центрального процессора, а зелёные - графического.

В чем особенность архитектуры Единой Памяти (UMA) от Apple?

Я немного лукавлю, когда говорю Архитектура Единой Памяти (Unified Memory Architecture, UMA). Чтобы объяснить почему, вернемся на пару шагов назад.

Долгое время недорогие компьютеры имели центральный процессор с интегрированным графическим на одном чипе. Он работал медленно. В прошлом, когда говорили интегрированная графика, подразумевали слабая графика. Эти процессоры были слабы по нескольким причинам. Первая заключается в том, что память для центрального процессора и графического была разделена. Если данные от центрального процессора должны были быть переданы графическому, то он не мог просто сказать На, держи и используй. CPU должен был явно скопировать этот блок данных в память графического процессора.

CPU не требует большого объема данных, но хочет получать их быстро.CPU не требует большого объема данных, но хочет получать их быстро.

CPU и GPU работают с памятью по-разному. Позволим себе привести аналогию из жизни: CPU хочет, чтобы официант подал блюдо как можно быстрее, и маленькие порции не заботят процессор. Представьте себе небольшой французский ресторан, где официанты катаются на роликах.

Так графический процессор хочет видеть порцию данных. Чем больше, тем веселее.Так графический процессор хочет видеть порцию данных. Чем больше, тем веселее.

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

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

Вторая причина слабой графики - производимое тепло мощными GPU. По этой причине нельзя было их интегрировать с CPU, не получив проблем с охлаждением. Большинство графических дискретных карт выглядит так, как карта ниже: огромные монстры с массивными кулерами. У них есть специально выделенная память, чтобы обрабатывать огромные блоки данных.

GeForce RTX 3080.GeForce RTX 3080.

Поэтому эти карты выдают высокую производительность. Однако у них есть ахиллесова пята: если они хотят получить какие-либо данные из памяти CPU, то эти данные передаются по медным путям, называемым шиной PCIe. Попробуйте после долгой работы попить воду через тонкую соломинку. Она быстро дойдет до вашего рта, но пропускная способность будет недостаточной.

Блок единой памяти (UMA) Apple пытается решить эти проблемы без недостатков старомодной общей памяти. Они достигают этого следующим образом:

  1. Больше нет специально ограждённых блоков памяти для CPU или GPU. Память доступна для обоих процессоров. Они используют одни и те же ячейки памяти, копирования больше нет.

  2. Apple ставят память, которая способа выдавать большие порции данных быстро. В техническом лексиконе это называется низкой задержкой и высокой пропускной способностью (low latency and high throughput). Как следствие, соединения между двумя раздельными областями памяти не требуется.

  3. Apple сумели снизить потребление энергии у GPU, поэтому относительно производительные графические процессоры теперь можно интегрировать на чип без перегрева. Процессоры ARM производят в целом меньше тепла, соответственно графический чип может позволить себе нагреться сильнее до допустимых температур, чем такой же чип на матрице от Intel или AMD.

Некоторые скажут, что единая память UMA - это не новинка, и это будет правдой. Различные системы в прошлом имели схожую архитектуру, однако в них, во-первых, требования к памяти не так сильно отличались, как требования от CPU и GPU. Во вторых, то, что Nvidia называют единой памятью, на самом деле не совсем таковой являлось. В мире Nvidia единая память - это когда программное обеспечение и железо работают так, чтобы бесшовно копировать данные между раздельными областями памяти CPU и GPU. С точки зрения программистов единая память от Apple и от Nvidia работают одинаково, но под капотом совершенно разная архитектура.

Конечно, есть и обратная сторона такой архитектуры памяти Apple. Обеспечение широкой пропускной способности памяти требует полной интеграции, что подразумевает отсутствие возможности апгрейда железа. Apple стремится минимизировать риски, в том числе работая над увеличением скорости работы SSD дисков.

Так компьютеры Apple работали с видео до появления архитектуры единой памяти. Одна из опций - использовать внешнюю видеокарту, работающую по порту Thunderbolt 3. Есть разные предположения о том, как эта же система будет работать в будущем с М1.Так компьютеры Apple работали с видео до появления архитектуры единой памяти. Одна из опций - использовать внешнюю видеокарту, работающую по порту Thunderbolt 3. Есть разные предположения о том, как эта же система будет работать в будущем с М1.

Если системы SoC такие умные, то почему Intel и AMD не следуют той же стратегии?

Что же такого Apple делает, что не могут делать другие производители? В некоторой степени, делают. Многие производители добавляют все чаще специализированные со-процессоры. AMD тоже начали ставить более мощные графические процессоры в свои чипы, а также они постепенно двигаются к некоторой форме систем на чипе, называемых Accelerated Processing Unit APU, которые являются тоже комбинацией CPU и GPU на одном чипе.

APU от AMD Ryzen. CPU и GPU (Radeon Vega) расположены на одной матрице, но этот чип все равно не содержит других со-процессоров, IO контроллеров и единой памяти.APU от AMD Ryzen. CPU и GPU (Radeon Vega) расположены на одной матрице, но этот чип все равно не содержит других со-процессоров, IO контроллеров и единой памяти.

Есть еще одна важная причина, почему AMD не спешат. Чип SoC - это весь компьютер на одном чипе. Это затрудняет бизнес для нынешних производителей компьютеров вроде HP или Dell. Позвольте мне прояснить позицию: если весь ваш бизнес заточен под производство двигателей для машины, то это будет необычно начинать производить и продавать целые машины.

В случае ARM же, напротив, это не проблема. Производители компьютерных деталей могут просто купить лицензию на производство ARM и другие чипы и производить SoC с теми компонентами, которые они подчищают полезными. Затем они отправят готовые макеты на завод производства полупроводников вроде GlobalFoundries или TSMC, которые уже сегодня производят чипы для ARM и Apple.

Завод по производству полупроводников TSMC в Тайване. Завод провизводит чипы для AMD, Apple, Nvidia и Qualcomm.Завод по производству полупроводников TSMC в Тайване. Завод провизводит чипы для AMD, Apple, Nvidia и Qualcomm.

Здесь возникает большая проблема, связанная с бизнес-моделью Intel и AMD. Их модель основана на продаже процессоров общего назначения, которые покупатели просто вставляют в материнские платы. Любой желающий может просто купить материнскую плату, память, CPU и видеокарту от любого производителя и собрать их в одном компьютере.

Однако мы уже уходим от этого подхода. В новом мире SoC вы не собираете компоненты от разных производителей. Вместо этого вы собираете интеллектуальную собственность на производство. Вы покупаете чертежи видеокарты, CPU, модема, IO контроллеров и других деталей компьютера от разных вендоров и интегрируете их в собственном SoC. Сейчас ни Intel, ни AMD, ни Nvidia не планируют продавать лицензию на интеллектуальную собственность на производство SoC Dell, HP или любому другому производителю.

Конечно, Intel и AMD могут начать продавать произведенные SoC. Но из каких компонентов они будут состоять? У сборщиков компьютеров есть свои соображения на этот счет. В итоге эта ситуация может перерасти в конфликт между Intel, AMD, Microsoft, потому что произведенные чипы нуждаются и в программном обеспечении.

Для Apple все просто - они контролируют весь процесс производства. Они предоставляют, например, библиотеку Core ML для машинного обучения. Сторонние разработчиков не задумываются даже, работает ли их код с Core ML на CPU от Apple или Нейронном чипе (Neural Engine).

Гонка наращивания мощности CPU

Неоднородные вычисления (heterogeneous computing) - это только лишь одна из причин. Ядра общего назначения процессора М1, называемые Firestorm, действительно быстры. Это главное отличие от ARM процессоров прошлого, которые были слабы по сравнению с процессорами Intel и AMD.

Firestorm обгоняет большинство процессоров Intel и самый быстрый чип от AMD - Ryzen. Народная мудрость гласит, что этого никогда не должно произойти. Прежде чем поговорить о том, что делает Firestorm таким быстрым, важно понять концепции увеличения мощности процессора. В принципе, вы можете комбинировать два пути увеличения скорости:

  1. Быстрее выполнять инструкции в последовательности.

  2. Выполнять инструкции параллельно.

В далеких 80-х это было легко. Просто увеличьте частоту процессора, и инструкции будут выполнены быстрее. Цикл процессора - это когда чип выполняет какую-то операцию. Но эта операция может быть очень маленькой. Таким образом, инструкция может потребовать несколько тактов выполнения, так как состоит из нескольких мелких операций.

Тем не менее, сегодня увеличение частоты процессора становится почти неосуществимым. Это тот самый Конец закона Мура, о котором люди твердят последнее десятилетие. Таким образом, у нас остается только увеличивать количество выполняемых инструкций в параллели.

Много ядер или процессоры исполнения вне очереди ОоОЕ?

Как уже говорили, есть две опции:

  • Увеличить количество ядер в процессор, чтобы каждое работало в параллели и независимо.

  • Научить каждое ядро выполнять несколько инструкций параллельно.

С точки зрения разработчика, добавить ядер - это как добавить потоки (thread) выполнения. Каждое ядро работает как физический поток. Если вы не знаете, что такое поток, то можете воспринимать его как процесс, который выполняет какую-то задачу. С двумя ядрами CPU может выполнять две задачи параллельно в два потока. Задачей же может быть две какие-либо программы или одна и та же программа, запущенная дважды. Каждый поток имеет свое место в последовательности программных инструкций и временно хранит результаты выполнения.

В принципе, процессор может иметь одно ядро и выполнять программы в несколько потоков. В таком случае процессор прерывает один поток и сохраняет его состояние перед переключением на другой поток. Позже он переключится назад. Такая схема более-менее работоспособна, пока процессор не начинает часто переключаться из-за:

  • ожидания ввода данных пользователем

  • данных, которые приходят медленно из-за плохого интернета и других подобных случаев.

Это называется логическими потоками. Физические же потоки используют физические ядра для ускорения работоспособности.

Для разработчиков проблему составляют логические потоки, ведь под них необходимо специально писать мультипоточный код. Это сложно, а в прошлом это было едва ли не самой сложной задачей. Тем не менее, сервер со множеством логических потоков - это не сложно: каждый веб-запрос пользователя обрабатывается отдельным потоком. Таким образом, множество физических ядер дает ощутимое преимущество. Особенно для облачных вычислений.

Процессор ARM Ampere Altra Max имеет на борту очень много физических ядер и был разработан специально для облачных решений.Процессор ARM Ampere Altra Max имеет на борту очень много физических ядер и был разработан специально для облачных решений.

Вот поэтому мы и видим процессоры ARM с безумными 128-мью ядрами. Этот чип был специально разработан для облаков. Вам не нужно сумасшедшую мощность от одного ядра, потому что в облачных сервисах важно наличие как максимального количества физических ядер на 1 Ватт мощности, чтобы обработать как можно больше запросов пользователей. Более подробно о многоядерных процессорах можно прочесть в статье Are Servers Next for Apple?.

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

Программы для пользовательского рынка обычно не используют много ядер компьютера. Например, игры работают прекрасно и на восьмиядерных процессорах, а 128 ядер - это трата ресурсов. Тут лучше меньше ядер, но более мощных.

Как работают процессоры Out-of-Order

Чем больше параллельно выполняемых инструкций, тем быстрее процессор. Принцип выполнения Out-of-order execution (ОоОЕ) заключается в том, что инструкции выполняются параллельно и при этом эта параллельность незаметна разработчикам программного обеспечения. Об альтернативном решении можно почитать здесь: Very Long Instruction Word Microprocessors.

Разработчики не должны писать код, чтобы воспользоваться преимуществами ОоОЕ. С точки зрения разработчика это выглядит так, как будто каждое ядро работает быстрее. Прошу заметить, что это не прямая альтернатива физическим потокам. Можно использовать оба варианта в зависимости от проблемы, которую необходимо решить. Чтобы понять, как работает ОоОЕ, нужно понимать принцип работы памяти компьютера. Запрашивание данных из одного расположения работает медленно, а процессор способен запрашивать данные параллельно. Следовательно, передача 1 байта информации займет столько же времени, сколько и 100 следующих байт.

Роботы на складе онлайн-магазина Komplett.no, Норвегия.Роботы на складе онлайн-магазина Komplett.no, Норвегия.

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

Данные пересылаются по шине данных (databus). Это похоже на дорогу или трубу между памятью и компонентами процессора, куда данные отправляются. В реальности мы имеем даже медные дорожки на плате. Чем шире шина, тем больше байт одновременно мы можем передать.

Процессор получает блок инструкций для выполнения полностью, но выполняет их одну за другой. Современные процессоры могут выполнять их по принципу Out-of-Order-execution. Это значит, что процессор анализирует инструкции на предмет зависимости между операциями.

01: mul r1, r2, r3    // r1  r2  r302: add r4, r1, 5     // r4  r1 + 503: add r6, r2, 1     // r6  r2 + 1

Умножение - довольно тяжелая операция, она требует несколько тактов процессора. Вторая операция из последовательности выше вынуждена подождать, когда будет выполнена первая операция, так как ей требуется ее результат. Но третья операция не зависит от первых двух. Следовательно, процессор с ОоОЕ может выполнить третью операцию параллельно первым двум в отдельном потоке.

В жизни инструкций может быть тысячи, но процессор все равно способен анализировать зависимости между ними. Процессор смотрит на входные данные каждой инструкции, зависят ли они от результатов других инструкций. Например, инструкция add r4, r1, 5 зависит от значения в регистре r1, которое является результатом операции умножения. Все эти связи складываются в проработанный граф операций, с которым CPU вполне справляется: узлы - это инструкции, а линии соединения - регистры.

CPU анализирует этот граф связей, чтобы понять, какие инструкции можно выполнять параллельно, а какие - отложить, так как их входные данные еще не были получены. Большинство операций будет выполнено еще до того, как процессор обозначит их завершенными. Со стороны же всё выглядит так, как будто инструкции были выполнены в том же порядке, в котором они были поданы процессору.

В принципе, у вас есть две формы параллелизма: одну разработчики программ должны учитывать при написании кода, а вторая - неявная, которая полагается на множество транзисторов, выполняющих их на CPU с помощью магии Out-of-Order-Execution. Для небольших процессоров с малым количеством транзисторов это не будет работать эффективно.

Именно магия OoOE и делает процессор М1 таким быстрым. На данный момент этот процессор быстрее чем любое решение от Intel или AMD, и все складывается так, как будто они и не догонят никогда Apple. Чтобы понять почему, мы должны погрузиться немного в детали.

Инструкции ISA и микро-операции

Я пропустил некоторые детали о работе ОоОЕ. Программы, загруженные в память, были собраны для конкретной архитектуры процессора ISA. Например, для x86, ARM, PowerPC, 68K, MIPS, AVR и других.

Для процессора x86 операция извлечения числа из памяти выглядит так:

MOV ax, 24

У x86 регистры названы как ax, bx, cx и dx (мы ведь помним, что это именованные ячейки памяти в CPU). Такая же операция для процессора ARM будет выглядеть так:

LDR r0, 24

Процессоры Intel и AMD построены на x86 архитектуре, а М1 от Apple - ARM. Внутри эти процессоры работают совершенно иначе, но программисты этого не видят. Мы описываем их работу микро-операциями (micro-ops, ops). С этими инструкциями железо Out-of-Order и работает.

Но почему ОоОЕ не может работать с обычным машинным кодом? Это потому что процессор вынужден хранить различную дополнительную информацию к инструкциям, чтобы иметь возможность выполнять их параллельно. Таким образом, обычная ARM инструкция может быть длиной 32 бита максимум (последовательность из 32 цифр: 0 и 1), а инструкции из микро-операций могут быть гораздо длиннее. Они содержат информацию о порядке исполнения.

01: mul r1, r2, r3    // r1  r2  r302: add r4, r1, 5     // r4  r1 + 503: add r1, r2, 1     // r1  r2 + 1

Как вы помните, мы выполняем операции 01 и 03 параллельно. И обе операции хранят результат своей работы в регистре r1. Если мы запишем результат 03 перед тем, как начнет выполняться операция 02, то вторая операция получит неверные входные данные. Следовательно, соблюдать очередность исполнения очень важно.Очередность выполнения хранится вместе с самой микро-операцией, а также хранятся и зависимости операций друг от друга.

Поэтому мы не можем написать программу специально под микро-операции, так как они содержат очень много дополнительной специфичной информации. Для двух различных ARM процессоров последовательность микро-операций может быть очень разной.

CPU может выполнять микро-операции очень быстро, потому что микро-операция - это одинарная очень простая операция. Обычно инструкции ISA могут быть очень сложными. Они состоят из множества команд, которые переводятся в микро-операции. Само слово микро происходит от сути операции, а не занимаемой ею памяти.

Для процессоров CISC зачастую нет других решений, кроме микро-операций, формирующих длинные последовательные цепочки. Это исключает использование ОоОЕ. Процессоры RISC же могут выбирать. Например, некоторые небольшие ARM процессоры не используют микро-операции. Но также они и не выполняют код с помощью ОоОЕ.

Почему выполнение ОоОЕ процессорами Intel и AMD уступает чипу М1?

Вы может быть удивлены, почему это имеет значение? Почему эта деталь важна для понимания, из-за чего Apple превосходит Intel и AMD? Суть заключается в том, как быстро вы сможете заполнить буфер микро-операций. Если у вас большой объем памяти, то ОоОЕ сможет быстрее найти независимые цепочки инструкций, которые могут быть выполнены параллельно. Но это имеет мало смысла, если у вас не получается быстро заполнять освободившееся пространство памяти после выполнения инструкций. Способность быстро заполнять буфер полагается на способность быстро нарезать машинный код на микро-операции. Устройства, которые этим занимаются, называются декодерами (decoder).

И тут мы наконец-то видим киллер-фичу процессора М1. Самый большой и подлый процессор Intel имеет на борту 4 декодера. А чип М1 - неслыханные 8 декодеров - значительно больше, чем кто бы то ни было до этого. Так можно заполнять буфер гораздо быстрее. Помимо этого, буфер для инструкций у чипа М1 больше в три раза, чем у среднего чипа в индустрии.

Почему Intel и AMD не могут добавить больше декодеров?

Здесь мы можем заметить месть процессоров RISC и начинаем понимать, почему чип М1 построен на базе ARM архитектуры. Видите ли, инструкция для процессора x86 может быть от 1 до 15 байтов длиной. Инструкция для RISC же фиксированной длинны - 4 байта. Почему это важно для нас? Дело в том, что разделение потока байтов на ограниченные инструкции, чтобы накормить ими восемь декодеров процессора параллельно, становится тривиальной задачей, если инструкции всегда одной и той же длины.

Тем не менее, декодеры в x86 не знают, где начнется следующая инструкция. Получается, что декодерам приходится анализировать и длину инструкций. Intel и AMD решила эту задачу топорно: декодер постоянно пытается определить, является ли выполняемая операция начальной точкой инструкции. Таким образом, процессор совершает очень много неудачных попыток. Это создает очень запутанную и сложную стадию декодирования, и из-за этого действительно сложно добавить больше декодеров. Но для Apple же это становится тривиальной задачей. Фактически, 4 декодера - это максимальное число возможных декодеров для Intel и AMD.

Это и есть главная причина, почему М1 ядра Firestorm могут обрабатывать в два раза больше инструкций, чем Intel и AMD, на той же частоте процессора.

Одни могут возразить, что инструкции CISC содержат больше микро-операций. х86 инструкция превращается в две микро-операции, тогда как ARM инструкция - это одна микро-операция. Затем 4 декодера х86 обработают такое же количество микро-операций за такт, какое 8 декодеров у CPU. К сожалению, такое происходит редко в жизни. Очень оптимизированный код для x86 редко использует сложные CISC инструкции, которые могли бы быть переведены во множество микро-операций. Фактически, большая часть этих инструкций будет переведено в одинарные микро-операции.

Тем не менее, эти простые инструкции х86 не помогают Intel и AMD. Несмотря на то, что инструкции длиной в 15 байтов - редкость, декодеры все равно должны быть готовы их обработать, и это и мешает производителям добавлять больше декодеров.

Но ядра процессора AMD Zen3 ведь быстрее, так?

Насколько я помню из последних бенчмарков, новейшие ядра AMD Zen3 немного быстрее, чем ядра М1 Firestorm. Но здесь есть небольшой трюк - ядра Zen3 работают на частоте 5 Гц, тогда как Firestorm работают на частоте 3.2 Гц. Ядра Zen3 лишь немного превосходят Firestorm, несмотря на то, что работают на частоте выше на 60%.

Но почему же Apple тоже не повышает частоту процессора? Ответ прост - чип станет горячее. Это одна из особенностей Apple - их компьютеры не требуют сильного охлаждения, в отличие от Intel и AMD. В сущности, ядра Firestorm превосходят Zen3, тогда как Zen3 вынужден оставаться в игре за счет гораздо большего перегрева. Apple просто не выбирают этот путь.

Если Apple захотят больше мощности, они добавят больше ядер, и это позволит дать больше производительности, не увеличивая сильно потребление энергии.

Будущее

Похоже, что AMD и Intel загнали себя в угол по двум фронтам:

  • У них нет бизнес-модели, чтобы так же легко продолжать стратегию разнородных вычислений (heterogenous computing) и следовать SoC разработкам.

  • Их устаревший набор инструкций CISC теперь преследует их, не позволяя улучшать мощности Out-of-Order.

Это не значит, что игра окончена. Они могут увеличивать частоту процессора и применять больше охлаждения, подбрасывать больше ядер и наращивать объем кэша CPU. В любом случае, оба производителя в невыгодном положении. Intel даже хуже, ведь они на данный этап официально проигрывают гонку производительности, а их GPU очень слабы для интеграции в чипах SoC.

Проблема с подбрасыванием большего числа ядер заключается в том, что ядер становится слишком много. Это хорошо только для серверных станций. Тем не менее, Amazon и Ampere атакуют рынок с их монструозными 128-ядерными процессорами. Это схоже с ситуацией, когда вы боретесь на восточном и западном фронте одновременно.

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

Подробнее..

Перевод Что означает RISC и CISC?

14.02.2021 10:08:56 | Автор: admin

Многие говорят, что разница между RISC и CISC стала несущественной. Так ли это? И если нет, то в чем разница между современными RISC и CISC процессорами?

Компания Apple выпустила процессор Apple Silicon M1, который произвел фурор. Теперь вы можете задаться вопросом, чем он отличается от процессоров Intel и AMD? Вероятно, вы слышали, что M1 процессор с архитектурой ARM, а ARM это RISC, в отличие от Intel и AMD.

Если вы читали про разницу между микропроцессорами RISC и CISC, то вы знаете, что множество людей утверждают об отсутствии практической разницы между ними в современном мире. Но так ли это на самом деле?

Хорошо, сейчас вы немного запутались и хотите исчерпывающих ответов. Эта статья отличное начало.

Я разобрал сотни комментариев по этой теме и столько же написал в ответ. Некоторые из них были от инженеров, которые причастны к созданию этих микропроцессоров.

Я начну с базовых вещей, которые необходимо понять, прежде чем начать отвечать на интересующие вопросы о разнице RISC и CISC.

Вот темы, которые будут рассмотрены в данной статье:

  • Что такое микропроцессор?
  • Что такое архитектура набора команд (ISA)?
  • Зачем выбирать ISA?
  • В чем разница между наборами команд RISC и CISC?
  • Философия CISC.
  • Философия RISC.
  • Конвейеризация.
  • Архитектура Load / Store.
  • Сжатый набор инструкций.
  • Микрокод и микрокоманды.
  • Чем отличаются микрокоманды от инструкции RISC?
  • Гипертрединг (аппаратные потоки).
  • Действительно ли стоит различать RISC и CISC?

Я использую данные темы в заголовках, поэтому вы можете читать только про то, что вам интересно.

Что такое микропроцессор?


Давайте сначала разберемся что такое микропроцессор. Вероятно, у вас уже есть предположения, иначе вы не открыли бы эту статью.

В общем случае процессор это мозг компьютера. Он читает инструкции из памяти, которые указывают, что делать компьютеру. Инструкции это просто числа, которые интерпретируются специальным образом.

В памяти нет ничего, что позволяло бы отличить обычное число от инструкции. Поэтому разработчики операционных систем должны быть уверены, что инструкции и данные лежат там, где процессор ожидает их найти.

Микропроцессоры (CPU) выполняют очень простые операции. Вот пример нескольких инструкций, которые выполняет процессор:

load r1, 150load r2, 200add r1, r2store r1, 310

Это человекочитаемая форма того, что должно быть просто списком чисел для компьютера. Например, load r1, 150 в обычном RISC микропроцессоре представляется в виде 32-битного числа. Это значит, что число представлено 32 символами, каждый из которых 0 или 1.

load в первой строчке перемещает содержимое ячейки памяти 150 в регистр r1. Оперативная память компьютера (RAM) это хранилище миллиардов чисел. Каждое число хранится по своему адресу, и так микропроцессор получает доступ к правильному числу.

Упрощенная диаграмма операций в микропроцессоре. Инструкции помещаются в регистр инструкций, где происходит декодирование. Декодер активирует нужные части процессора и операция выполняется.

Далее вы можете заинтересоваться, что такое регистр. Эта концепция достаточно старая. Старые механические кассовые аппараты были основаны на этой концепции. В те времена регистр был чем-то вроде механического приспособления, в котором хранилось число, с которым вы хотели работать. Часто в таких аппаратах был аккумуляторный регистр, в который вы могли добавлять числа, а регистр сохранял сумму.

Арифметический калькулятор Феликс. Русский механический калькулятор. Внизу виден аккумуляторный регистр, сохранявший до тринадцати десятичных знаков. Наверху входной регистр, вмещающий пять знаков. Слева внизу счетный регистр.

Ваши электронные калькуляторы работают по такому же принципу. Чаще всего на дисплее отображается содержимое аккумуляторного регистра, а вы выполняете действия, которые влияют на его содержимое.

Аналогичное справедливо для микропроцессора. В нем есть множество регистров, которым даны имена например, A, B, C или r1, r2, r3, r4 и так далее. Инструкции микропроцессора обычно производят операции над этими регистрами.

В нашем примере add r1, r2 складывает содержимое r1 и r2 и полученный результат записывает в r1.

В конце мы сохраняем полученный результат в оперативной памяти в ячейке с адресом 310 с помощью команды store r1, 310.

Что такое архитектура набора команд (ISA)?


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

Существует фиксированное количество команд, которые понимает процессор. И вы как программист не можете его расширить.

В мире представлено множество различных микропроцессоров, и они не используют одинаковый набор команд. Иными словами, они интерпретируют числа в инструкции по-разному.

Одна архитектура микропроцессора трактует число 501012 как add r10, r12, а другая архитектура как load r10, 12. Комбинация инструкций, которые понимает процессор, и регистров, которые ему доступны, называется архитектурой набора команды (Instruction Set Architecture, ISA).

Микропроцессоры, например, Intel и AMD, используют архитектуру набора команд x86. А микропроцессоры, например, A12, A13, A14 от Apple, понимают набор команд ARM. Теперь в список ARM-процессоров можно включить M1.

Это те микропроцессоры, которые мы называем Apple Silicon. Они используют архитектуру набора команд ARM, как и множество других микропроцессоров телефонов и планшетов. Даже игровые приставки, такие как Nintendo и самый быстрый суперкомпьютер, используют набор команд ARM.

Набор команд x86 и ARM не является взаимозаменяемым. Программа компилируется под определенный набор команд, если, конечно, это не JavaScript, Java, C# или что-то подобное. В этом случае программа компилируется в байт-код, который похож на набор команд для несуществующего процессора. Для запуска такого кода требуется Just-In-Time компилятор или интерпретатор, который транслирует байт-код в инструкции, понятные для микропроцессора в вашем компьютере.

Это значит, что большинство программ, доступных на Mac, не будут запускаться на Mac с M1. Программы рассчитаны на набор инструкций x86. Чтобы решить эту проблему, программы перекомпилируются с использованием нового набора инструкций. У Apple есть козырь в рукаве, который называется Rosetta 2. Это решение позволяет транслировать инструкции x86 в инструкции ARM.

Почему произошел переход на совершенно другой набор команд?


Закономерный вопрос. Зачем использовать новый набор команд для Mac? Почему Apple не могла использовать набор команд x86 в микропроцессорах Apple Silicon? Так бы отпала необходимость в перекомпиляции или трансляции с помощью Rosetta 2.

Что ж. Архитектура набора команд сильно влияет на архитектуру процессора. Использование определенной архитектуры набора команд может усложнить или упростить задачу по созданию высокопроизводительного или энергоэффективного процессора.

Второй важный момент заключается в лицензировании. Apple не может свободно создавать свои процессоры с набором команд x86. Это часть интеллектуальной собственности Intel, а Intel не хочет конкурентов. Для сравнения, компания ARM не производит собственных микропроцессоров. Они занимаются проектированием архитектуры набора команд и предоставляют эталонные образцы микропроцессоров, которые ее реализуют.

Таким образом, ARM делает то, что вы хотите. Этого хочет и Apple. Они хотят создавать собственные решения для компьютеров со специализированным оборудованием для машинного обучения, криптографии и распознавания лиц. Если вы используете x86, то вам придется делать это на внешних чипах. Из соображений эффективности Apple хочет сделать все на одной большой интегральной схеме, то есть на том, что мы называем системой на кристалле (System-On-a-Chip, SoC).

Разработка началась со смартфонов и планшетов. Эти устройства слишком маленькие и не позволяют сделать множество чипов на одной большой материнской плате. Вместо этого необходимо уместить буквально все в один чип, который содержит микропроцессор, графический ускоритель, оперативную память и другое специализированное оборудование.

Материнская плата ПК, где графический ускоритель, сетевая карта и модули памяти подключаются через разъемы. Она слишком большая для планшетов и смартфонов, которые используют систему на кристалле.

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

Но давайте не будем отходить в сторону от главной темы. Архитектуры набора команд обычно следуют разным основополагающим философиям. Набор команд x86 это то, что мы называем архитектурой CISC, в то время как архитектура ARM следует принципам RISC. В этом заключается большая разница.

Инструкции CISC могут быть любой длины. Максимальная теоретическая длина инструкции x86 может быть бесконечной, но на практике не превышает 15 байт. Инструкции RISC имеют ограниченную длину.

В чем разница между набором команд RISC и CISC?


Аббревиатура CISC обозначает Complex Instruction Set Computer, а RISC Reduced Instruction Set Computer.

Сегодня объяснить разницу между этими наборами команд сложнее, чем во время их появления, так как в процессе развития они заимствовали идеи друг у друга. Более того, проводилась маркетинговая кампания по размытию границ между ними.

Минуем маркетинговую дезинформацию


Пол ДеМоне (Paul DeMone) написал статью в 2000 году, которая дает некоторое представление о существовавшем тогда маркетинговом давлении.

В 1987 году лучшим среди x86 был процессор Intel 386DX, а среди RISC MIPS R2000.

Несмотря на то, что процессор Intel имеет вдвое больше транзисторов (275 000 против 115 000 у MIPS) и вдвое больше кэш-памяти, процессор x86 проигрывает во всех тестах производительности.

Оба процессора работают на частоте 16 МГц, но RISC-процессор показывал результаты в 2-4 раза лучше.

Поэтому неудивительно, что в начале 90-х распространилась идея, что процессоры RISC значительно производительнее.

У Intel возникли проблемы с восприятием на рынке. Им было сложно убедить инвесторов и покупателей в том, что процессоры на устаревшей архитектуре CISC могут быть лучше процессоров RISC.

Так Intel стала позиционировать свои процессоры как RISC с простым декодером, который превращал команды CISC в команды RISC.

Таким образом, Intel выставила себя в очень привлекательном виде. Компания заявляла, что покупатель получает технологически совершенные процессоры RISC, которые понимают знакомый многим набор команд x86.

Давайте проясним один момент. Внутри процессора x86 нет RISC-составляющей. Это просто маркетинговый ход. Боб Колвеллс (Bob Colwells), один из создателей Intel Pentium Pro с RISC-составляющей, сам говорил об этом.

Теперь вы знаете, как эта ложь распространилась по интернету, да, Intel сделала удачный маркетинговый ход. Он сработал, потому что в нем есть доля правды. Но чтобы действительно понять разницу между RISC и CISC, вам нужно избавиться от этого мифа.

Мысль о том, что внутри CISC-процессора может быть RISC, только запутает вас.

Философия CISC


Давайте поговорим о том, что из себя представляют RISC и CISC. И то, и другое философия того, как нужно проектировать процессоры.

Взглянем на философию CISC. Эту философию сложно определить, так как микросхемы, которые мы определяем как CISC, очень разнообразны. Однако в них можно выделить общие закономерности.

В конце 1970, когда началась разработка CISC-процессоров, память была очень дорогой. Компиляторы тоже были плохие, а люди писали на ассемблере.

Так как память была дорогой, люди искали способ минимизировать использование памяти. Одно из таких решений использовать сложные инструкции процессора, которые делают много действий.

Это также помогло программистам на ассемблере, так как они смогли писать более простые программы, ведь всегда найдется инструкция, которая выполняет то, что нужно.

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

В программировании повторяющийся код выносится в отдельные подпрограммы (функции), которые можно вызывать множество раз.

Идея микрокода очень близка к этому. Для каждой инструкции из набора создается подпрограмма, которая состоит из простых инструкций и хранится в специальной памяти внутри микропроцессора.

Таким образом, процессор содержит небольшой набор простых инструкций. На их основе можно создать множество сложных инструкций из набора команд с помощью добавления подпрограмм в микрокод.

Микрокод хранится в ROM-памяти (Read-Only Memory, только для чтения), которая значительно дешевле оперативной памяти. Следовательно, уменьшение использования оперативной памяти через увеличение использования постоянной памяти выгодный компромисс.

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

Разработчики стали думать, что существует другой, более простой способ справиться с этими трудностями.

Философия RISC


Оперативная память стала дешеветь, компиляторы стали лучше, а большинство разработчиков перестало писать на ассемблере.

Эти технологические изменения спровоцировали появление философии RISC.

Сперва люди анализировали программы и заметили, что большинство сложных инструкций CISC не используются большинством программистов.

Разработчики компиляторов затруднялись в выборе правильной сложной инструкции. Вместо этого они предпочли использовать комбинацию нескольких простых инструкций для решения проблемы.

Вы можете сказать, что здесь применимо правило 80/20: примерно 80% времени тратится на выполнение 20% инструкций.

Идея RISC заключается в замене сложных инструкций на комбинацию простых. Так не придется заниматься сложной отладкой микрокода. Вместо этого разработчики компилятора будут решать возникающие проблемы.

Есть разногласия в том, как понимать слово сокращенный (reduced) в аббревиатуре RISC. Люди думают, что сокращено количество инструкций. Но более правильная интерпретация это уменьшение сложности команд.

RISC-код может быть непростым для человека. Много лет назад я совершил ошибку, когда решил, что самостоятельное написание ассемблерного кода для PowerPC (архитектура IBM RISC с огромным количеством инструкций) сэкономит мое время. Это принесло мне множество лишней работы и разочарований.

Одним из аргументов RISC было то, что люди перестали писать ассемблерный код, поэтому необходимо создать набор инструкций, удобный для компиляторов. Архитектура RISC оптимизирована для компиляторов, но не для людей.

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

Конвейеризация: инновация RISC


Еще одна основная идея RISC это конвейеризация. Для объяснения я проведу небольшую аналогию.

Представьте процесс покупки в продуктовом магазине. Хотя этот процесс отличается от страны к стране, я расскажу на примере родной Норвегии. Действия на кассе можно разделить на несколько шагов.

  1. Переместить покупки на конвейерную ленту и отсканировать штрих-коды на них.
  2. Использовать платежный терминал для оплаты.
  3. Положить оплаченное в сумку.

Хорошее векторное изображение, созданное на pch.vector (источник: www.freepik.com)

Если такое происходит без конвейеризации, то следующий покупать сможет переместить вещи на ленту только после того, как текущий покупатель заберет свои покупки. Аналогичное поведение изначально встречалось в CISC-процессорах, в которых по умолчанию нет конвейеризации.

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

Представим, что каждое действие занимает фиксированный промежуток времени или один такт. Это значит, что обслуживание одного покупателя занимает три такта. Таким образом, за девять тактов будут обслужены три покупателя.

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

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

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

Мы можем сказать, что работа с кассой занимает три такта, но пропускная способность кассы один покупатель в такт.

В терминологии микропроцессоров это значит, что одна инструкция выполняется три такта, но средняя пропускная способность одна инструкция в такт.

В этом примере я сделал предположение, что обработка каждого этапа занимает одинаковое количество времени. Иными словами, перенос продуктов из корзины на ленту занимает столько же времени, сколько оплата покупок.

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

Проектировщики RISC прекрасно это понимали, поэтому попытались стандартизировать время выполнения каждой инструкции. Они разделены на этапы, каждый из которых выполняется примерно одинаковое количество времени. Таким образом, ресурсы внутри микропроцессора используются по максимуму.

Если рассмотреть ARM RISC-процессор, то мы обнаружим пятиступенчатый конвейер инструкций.

  • (Fetch) Извлечение инструкции из памяти и увеличение счетчика команд, чтобы извлечь следующую инструкцию в следующем такте.
  • (Decode) Декодирование инструкции определение, что эта инструкция делает. То есть активация необходимых для выполнения этой инструкции частей микропроцессора.
  • (Execute) Выполнение включает использование арифметико-логического устройства (АЛУ) или совершение сдвиговых операций.
  • (Memory) Доступ к памяти, если необходимо. Это то, что делает инструкция load.
  • (Write Back) Запись результатов в соответствующий регистр.

Инструкции ARM состоят из секций, каждая из которых работает с одним из этих этапов, а выполнение этапа обычно занимает один такт. То есть инструкции ARM очень удобно конвейеризировать.

Более того, каждая инструкция имеет одинаковый размер, то есть этап Fetch знает, где будет располагаться следующая инструкция, и ему не нужно проводить декодирование.

С инструкциями CISC все не так просто. Они могут быть разной длины. То есть без декодирования фрагмента инструкции нельзя узнать ее размер и где располагается следующая инструкция.

Вторая проблема CISC сложность инструкций. Многократный доступ к памяти и выполнение множества вещей не позволяют легко разделить инструкцию CISC на отдельные части, которые можно выполнять поэтапно.

Конвейеризация это особенность, которая позволила первым RISC-процессорам на голову обогнать своих конкурентов в тестах производительности.

Складской робот как аналогия для конвейеризации. Использовалась в одной из моих новых статей.

В качестве альтернативного объяснения конвейеризации я написал историю, построенную на аналогии со складским роботом: Why Pipeline a Microprocessor?

Архитектура Load / Store


Чтобы количество тактов, необходимых для каждой инструкции, было примерно одинаковым и удобным для конвейеризации, набор инструкций RISC четко отделяет загрузку из памяти и сохранение в память от остальных инструкций.

Например, в CISC может существовать инструкция, которая загружает данные из памяти, производит сложение, умножение, что-нибудь еще и записывает результат обратно в память.

В мире RISC такого быть не может. Операции типа сложения, сдвига и умножения выполняются только с регистрами. Они не имеют доступа к памяти.

Это очень важный момент для конвейеризации. Иначе инструкции в конвейере могут зависеть друг от друга.

Большое количество регистров


Большая проблема для RISC это упрощение инструкций, что ведет к увеличению их количества. Больше инструкций требуют больше памяти недорогой, но медленной. Если программа RISC потребляет больше памяти, чем программа CISC, то она будет медленнее, так как процессор будет постоянно ждать медленного чтения из памяти.

Проектировщики RISC сделали несколько замечаний, которые позволили решить эту проблему. Они заметили, что множество инструкций перемещают данные между памятью и регистрами, чтобы подготовиться к выполнению. Имея большое количество регистров, они смогли сократить количество обращений к памяти.

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

Инструкции в RISC проще. В них нет большого количества разных режимов адресации, поэтому, например, среди 32-битных команд есть больше бит, чтобы указать номер регистра.

Это очень важно. В процессоре с легкостью могут разместиться сотни регистров. Это не так сложно и не требует большого количества транзисторов. Проблема заключается в недостатке бит, указывающих адрес регистра. Так, например, в x86 есть только 3 бита для указания регистра. Это дает нам всего 23 = 8 регистров. Процессоры RISC экономят биты из-за меньшего количества способов адресации. Таким образом, для адресации используется 5 бит, что дает 25 = 32 регистра. Очевидно, что это пример и значения могут отличаться, но тенденция сохраняется.

Сжатый набор инструкций


Сжатый набор инструкций это относительно новая идея для мира RISC, созданная для решения проблемы большого потребления памяти, с которой не сталкиваются CISC-процессоры.

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

Это несколько переработанная идея CISC, так как CISC инструкции могут быть как очень короткими, так и очень длинными.

Процессоры RISC не могут добавить короткие инструкции, так как это усложняет работу конвейеров. Вместо этого проектировщики решили использовать сжатые инструкции.

Это означает, что подмножество наиболее часто используемых 32-битных инструкций помещается в 16-битные инструкции. Таким образом, когда процессор выбирает инструкцию, он может выбрать две инструкции.

Так, например, в RISC-V есть специальный флаг, который обозначает, сжатая это инструкция или нет. Если инструкция сжатая, то она будет разобрана в две отдельные 32-битные инструкции.

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

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

Более того, сжатая инструкция имеет доступ только к 8 наиболее используемым регистрам, а не ко всем 32. Также я не смогу загрузить константы с большим числом или с большим адресом в памяти.

Таким образом, компилятор или сборщик должен решить, стоит ли упаковывать конкретную пару инструкций вместе или нет. Сборщик должен искать возможности для выполнения сжатия.

Хотя это все выглядит как CISC, это не он. Большая часть микропроцессора, конвейер команд и прочее используют 32-битные инструкции.

В ARM вам даже нужно переключать режим для выполнения сжатых инструкций. Сжатый набор инструкций на ARM называется Thumb. Это тоже сильно отличается от CISC. Вы не будете инициировать изменение режима для выполнения одной короткой инструкции.

Сжатые наборы инструкций изменили положение дел. Некоторые варианты RISC используют меньше байт, чем те же программы на x86.

Большие кэши


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

Идея кэширования заключается в том, что большинство программ запускают небольшую часть себя гораздо чаще, чем остальную часть. Часто небольшие части программы повторяются бесчисленное количество раз, например, в случае циклов.

Следовательно, если поместить наиболее часто используемые части программы в кэш, то можно добиться значительного прироста скорости.

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

Таким образом, имея большие кэши, процессоры RISC компенсировали то, что их программы больше, чем программы RISC.

Однако со сжатием инструкций это уже не так.

CISC наносит ответный удар микрооперации


Конечно, CISC не сидел сложа руки и не ждал, когда RISC его повергнет. Intel и AMD разработали собственные стратегии по эмуляции хороших решений RISC.

В частности, они искали способ конвейеризации инструкций, который никогда не работал с традиционными инструкциями CISC.

Было принято решение сделать внутренности CISC-процессора более RISC-похожими. Способ, которым это было достигнуто, разбиение CISC-инструкции на более простые, названные микрооперациями.

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

Мое иллюстрированное руководство по микрооперациям: What the Heck is a Micro-Operation?

В чем различие микроопераций и микрокода?


Микрокод это маленькие программы в ROM-памяти, которые выполняются для имитации сложной инструкции. В отличие от микроопераций их нельзя конвейеризировать. Они не созданы для этого.

На самом деле микрокод и микрооперации существуют бок о бок. В процессоре, который использует микрооперации, программы микрокода будут использоваться для генерации серии микроопераций, которые помещаются в конвейер для последующего выполнения.

Имейте в виду, что микрокод в традиционном CISC-процессоре должен производить декодирование и выполнение. По мере выполнения микрокод берет под свой контроль различные ресурсы процессора, такие как АЛУ, регистры и так далее.

В современных CISC микрокод выполнит работу быстрее, потому что не использует ресурсов процессора. Он используется просто для генерации последовательности микроопераций.

Как микрооперации отличаются от RISC-инструкций


Это самое распространенное заблуждение. Люди думают, что микрооперации это то же самое, что и RISC-инструкции. Но это не так.

Инструкции RISC существуют на уровне набора команд. Это то, с чем работают компиляторы. Они думают о том, что вы хотите сделать, а мы пытаемся оптимизировать это.

Инструкции прибывают из памяти, обычно из высокоскоростного кэша. Далее они входят в декодер, который разбивает каждую инструкцию на одну или несколько микроопераций. Хотя они выполняют меньше одной инструкции, они значительно больше.

Микрооперация это нечто совершенно иное. Микрооперации, как правило, большие. Они могут быть больше 100 бит. Неважно, насколько они большие, потому что они существуют временно. Это различает их от инструкций RISC, которые составляют программы и могут занимать гигабайты памяти. Инструкции не могут быть сколь угодно большими.

Микрооперации специфичны для каждой модели процессора. Каждый бит указывает часть процессора, которую необходимо включить или выключить при исполнении.

В общем случае нет необходимости в декодировании, если можно сделать большую инструкцию. Каждый бит отвечает за определенный ресурс в процессоре.

Таким образом, разные процессоры с одинаковым набором команд будут иметь разные микрокоды.

Фактически многие высокопроизводительные RISC-процессоры превращают инструкции в микрооперации. Это потому что микрооперации даже проще, чем инструкции RISC. Но использование микроопераций не является обязательным. Процессор ARM с меньшей производительностью может не использовать микрооперации, а процесс с более высокой производительностью и теми же инструкциями может использовать.

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

Фактически некоторые RISC-процессоры используют микрокод для некоторых инструкций, как CISC-процессоры. Одним из таких примеров является сохранение и восстановление состояния регистров при вызове подпрограмм. Когда одна программа переходит к другой подпрограмме для выполнения задачи, эта подпрограмма будет использовать некоторые регистры для локальных вычислений. Код, вызывающий подпрограмму, не хочет, чтобы его данные в регистрах изменялись случайным образом, поэтому он должен их сохранить в памяти.

Это настолько частое явление, что добавление конкретной инструкции для сохранения нескольких регистров в память было слишком заманчивым. В противном случае эти инструкции могут съесть много памяти. Поскольку это предполагает многократный доступ к памяти, имеет смысл добавить это как программу микрокода.

Однако не все RISC процессоры делают это. Например, RISC-V пытается быть более чистым и не имеет специальной инструкции для этого. Команды RISC-V оптимизированы для конвейеризации. Более строгое следование философии RISC делает конвейеризацию более эффективной.

Гипертрединг (аппаратные потоки)


Еще один трюк, которая используется CISC, это гипертрединг.

Напомню, что микрооперации непростые. Конвейер команд не будет заполнен полностью на постоянной основе, как у RISC.

Поэтому используется трюк под названием гипертрединг. Процессор CISC берет несколько потоков инструкций. Каждый поток инструкций разбивается на части и конвертируется в микрооперации.

Поскольку этот процесс несовершенен, вы получите ряд пробелов в конвейере. Но, имея дополнительный поток инструкций, вы можете поместить в эти промежутки другие микрооперации и таким образом заполнить конвейер.

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

Следовательно, более продвинутые и производительные процессоры RISC, такие как IBM POWER, тоже будут использовать аппаратные потоки.

В моем понимании трюк с гипертредингом более выгоден для процессоров CISC. Создание микроопераций менее идеальный процесс, и он создает больше пробелов в конвейере, следовательно, гипертрединг дает больший прирост производительности.

Если ваш конвейер всегда заполнен, то от гипертрединга/аппаратных потоков нет никакой пользы.

Аппаратные потоки могут представлять угрозу безопасности. Intel столкнулась с проблемами безопасности, потому что один поток инструкций может влиять на другой. Я не знаю подробностей, но некоторые производители предпочитают отключать аппаратные потоки по этой причине.

Как правило, аппаратные потоки дают примерно 20% прирост производительности. То есть процессор с 5 ядрами и гипертредингом будет приблизительно похож на процессор с 6 ядрами без него. Но данное значение зависит во многом от архитектуры процессора.

В любом случае, это одна из причин, почему ряд производителей высокопроизводительных чипов ARM, таких как Ampere, выпускают 80-ядерный процессор без гипертрединга. Более того, я не уверен, что хоть какой-то процессор ARM использует аппаратные потоки.

Процессор Ampere используется в дата-центрах, где важна безопасность.

Действительно ли стоит различать RISC и CISC?


Да, в основе лежат принципиально разные философии. Это не так важно для высокопроизводительных чипов, поскольку у них такое же большое количество транзисторов и сложность разделения инструкций x86 затмевается всем остальным.

Однако эти чипы выглядит по-разному, и к ним необходим разный подход.

Некоторые характеристики RISC больше не имеют особого смысла. Наборы инструкций RISC не обязательно малы. Хотя это во многом зависит от того, как вы считаете.

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

Тем не менее, все еще существует минимальный набор основных инструкций, и это очень похоже на RISC:

  • фиксированный размер инструкции;
  • инструкции разработаны для использования определенных частей процессора и оптимизированы для конвейерной обработки;
  • архитектура Load/Store. Большинство инструкций работают с регистрами. Работа с памятью производится в основном с помощью специальных инструкций, созданных исключительно для этого;
  • множество регистров, чтобы избежать частого доступа к памяти.

Для сравнения, инструкции CISC могут быть переменной длины. Люди могут спорить, что микрооперации это стиль RISC, но микрокод это деталь реализации, близкая к аппаратной.

Одна из ключевых идей RISC переложить тяжелую работу на компилятор. Это все еще так. Компилятор не может преобразовать микрооперации для оптимального выполнения.

Время наиболее критично при выполнении микроопераций, чем при компиляции. Это очевидное преимущество, которое позволяет передовым компиляторам перестраивать код вместо того, чтобы полагаться на драгоценный кремний.

Хотя процессоры RISC с годами получили более специализированные инструкции, например, для векторной обратки, у них по-прежнему нет сложности с множеством режимов доступа к памяти как у CISC.

Источники и дополнительное чтение


Источники для этой статья я указывал в предыдущей статье.

Также отмечу следующие источники:



Подробнее..

Перевод Запуск Unix-подобной ОС на самодельном CPU с помощью самодельного компилятора C

13.10.2020 10:19:44 | Автор: admin
image

Два года назад я начал работать разработчиком ПО. Иногда я рассказывал своим коллегам о студенческом проекте, которым занимался на третьем курсе университета, и они восприняли его настолько хорошо, что я решил написать этот пост1.

Позвольте задать вам вопрос: вы когда-нибудь проектировали собственную архитектуру набора команд (ISA), создавали на FPGA процессор на основе этой ISA и собирали для него компилятор? Запускали ли вы операционную систему на этом процессоре?

А у нас это получилось.

В этом посте я расскажу о своей учёбе в 2015 году, о четырёх месяцах создания самодельного CPU на самодельной архитектуре набора команд RISC, создании самодельного тулчейна C и портировании на этот процессор Unix-подобной ОС Xv6.

Процессорный эксперимент в Токийском университете


Всё это делалось в рамках студенческого экспериментального проекта под названием CPU Experiment. Давайте начнём с того, что же такое CPU experiment.

CPU experiment это небольшое популярное упражнение, проводящееся зимой третьего курса моей Кафедры информационных наук Токийского университета. В этом эксперименте студентов разделяют на группы по четыре-пять человек. Каждая группа проектирует собственную процессорную архитектуру, реализует её на FPGA, собирает компилятор подмножества OCaml для этого процессора, а затем запускает на процессоре определённую программу трассировки лучей. Обычно за каждую из задач (CPU, FPU, симулятор CPU и компилятор) отвечает один-два человека. В своей Group 6 я занимался CPU.

Это упражнение хорошо известно тем, что в нём от студентов ждут высокого уровня самообучения. Преподаватель просто даёт студентам задание взять написанную на OCaml программу трассировки лучей и запустить её на CPU, реализованном на FPGA, после чего занятие завершается. Он почти ничего не рассказывает о конкретных шагах по созданию CPU и компиляторов. Студенты сами изучают, как воплотить общие знания о процессорах и компиляторах, полученные на предыдущих лекциях, в реальные цепи и код. Это очень сложное упражнение, зато увлекательное и познавательное.

Запустим на собственном CPU операционную систему


Как вы могли заметить, я ничего не говорил об операционной системе, поэтому требуется объяснение.

Обычно эксперимент проходит следующим образом: во-первых, вы создаёте надёжно работающий CPU, вне зависимости от скорости его работы. Если вы сделаете работающий CPU и успешно запустите программу трассировки лучей, то получите за эксперимент зачёт. После этого вы сможете отдохнуть. Традиционно это время отдыха используется для дальнейшего ускорения своего CPU. В предыдущих экспериментах студенты создавали CPU с внеочередным (out-of-order) исполнением команд, VLIEW CPU, многоядерный CPU и даже суперскалярный CPU, что, по-моему, потрясающе.

Однако некоторые команды вкладывают больше энергии в реализацию развлекательных вещей, например, запуск игр или воспроизведение музыки, подключая к своим CPU динамик. В шестой группе, где находился я, была компания студентов, любивших развлечения, поэтому в качестве цели команды мы выбрали запуск ОС.

В результате к этой идее проявили интерес другие группы, была образована объединённая группа Group X примерно из восьми человек, целью которой стало Давайте запустим на собственном CPU операционную систему!

Хотя в Group 6 я отвечал за создание процессора, на этот раз я решил стать руководителем команды разработки ОС в Group X. Поэтому этот пост в основном написан с точки зрения команды разработчиков ОС, хотя я, разумеется, расскажу и про общие результаты группы.

Xv6


В качестве портируемой ОС мы выбрали Xv6 простую ОС, источником вдохновения для которой стал Unix v6; её создал с образовательными целями MIT. Xv6, в отличие от Unix v6, написана на ANSI C и выполняется на x86. Xv6 образовательная ОС, поэтому имеет довольно ограниченную функциональность, но в качестве простой Unix-подобной ОС она обладает достаточным набором возможностей. Подробнее о Xv6 можно прочитать на Википедии или в репозитории GitHub.

Сложности


При портировании xv6 было множество сложностей с программной стороны, потому что мы стремились создать всё с нуля.

1. Компилятор C и тулчейн для Xv6

В эксперименте с CPU мы обычно создаём компилятор ML. Естественно, им невозможно компилировать код Xv6, написанный на C.

2. Какие функции процессора необходимы для операционной системы?

Защита привилегий? Виртуальный адрес? Прерывание? Да, по лекциям мы имели общее представление о том, что делает операционная система, но не обладали достаточно полными знаниями, чтобы понять, какие конкретно функции CPU помогут нам реализовать задачу.

3. А что насчёт симулятора?

У нас был симулятор, который являлся одной из основных частей эксперимента с CPU, но он был простым и выполнял одну команду за другой, в нём не существовало ни прерываний, ни преобразования виртуальных адресов.

4. Плохая портируемость xv6

Xv6 не очень хорошо портируется. Например, в ней есть допущение о том, что char занимает 1 байт, а int 4 байта, и она выполняет активные манипуляции со стеком. Название Xv6, насколько я понимаю, взято от x86 и Unix v6, поэтому это в общем-то естественно.

У нас было много сомнений, но в декабре мы начали процесс портирования ОС Group X. Далее я буду писать о том, что мы делали, примерно в хронологическом порядке. Пост немного длинноват, поэтому если вы сразу хотите взглянуть на готовый результат, то перейдите к разделу Март.

Конец ноября приступаем к работе над компилятором


Первой задачей, ответ на который мы нашли, был компилятор и тулчейн. На удивление, наше решение заключалось в создании с нуля компилятора C89. Честно говоря, я не представлял, что мы выберем такой путь. Помню, как мы сначала обсуждали с Юити, отвечавшим в Group X за CPU, создание порта gcc или llvm.

Однако один из членов команды, Кэйити, внезапно сообщил нам, что написал компилятор C, и показал прототип компилятора с простым парсером и эмиттером. Нам показалось, что интереснее будет написать тулчейн с нуля, поэтому мы решили написать компилятор сами.

Юити и Ватару из Group 3, уже завершивший базовую часть эксперимента, присоединились к Кэйити, и так появилась команда разработки компилятора Group X. Позже мы назвали наш компилятор Ucc.

Середина декабря появилась команда разработки ОС!


В начале декабря я завершил свой процессор, и Group 6 закончила базовую часть эксперимента с CPU. Поэтому мы перешли к интересной части задаче по портированию ОС для Group X. В то время я и Сёхэй из Group 6 начали работать в Group X, став командой разработки ОС. Тогда же к нам присоединился Масаеси.

Базовая часть эксперимента: написание CPU


Кстати, я думаю, что немногим разработчикам ПО когда-нибудь доводилось писать CPU, поэтому немного расскажу и о создании CPU.

Сегодня для создания CPU необязательно соединять отдельные перемычки на монтажной плате; можно писать схему на языке описания аппаратуры (Hardware Description Language). Затем при помощи Vivado или Quartus код на HDL синтезируется в реальную схему. Этот процесс называется синтезом логических схем, а не компиляцией.

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

Самая сложная часть самой разработки заключалась в том, что синтез логических схем занимал огромное количество времени. Часто бывало так, что после запуска синтеза нам приходилось ждать по 30 минут, поэтому запустив синтез, я играл в Smash Bros. Melee с другими проектировщиками CPU, которые тоже ждали завершения синтеза. Кстати, мой любимый персонаж Sheik.

Конец декабря-середина января обучаемся, портируя Xv6 на MIPS


Мы начали искать ответ на вопрос: Какие функции процессора необходимы для операционной системы?

После создания команды разработки ОС мы приступили к еженедельным сессиям чтения исходного кода Xv6.

В то же время я начал портировать Xv6 на MIPS. Частично это было нужно для того, чтобы узнать, как работает ОС на уровне реализации, а частично потому, что, как оказалось, порта Xv6 на MIPS не существует. Примерно за неделю я завершил порт до этапа начала планировщика процессов. Во время процесса портирования я активно изучал MIPS и как работает xv6 на x86. Благодаря этому я понял на уровне реализации механизмы прерываний и MMU. На этом этапе я получил глубокое понимание функциональности CPU, требуемой для Xv6.

Кроме того, в середине января мы упорно работали над компиляцией всего кода Xv6, превращая его отдельные части в комментарии. В результате этого Xv6 в симулятора нашей самодельной архитектуры отобразил первое сообщение последовательности загрузки:

xv6...cpu0: starting...

В то же самое время это означало, что на данном этапе Ucc уже достаточно вырос, чтобы компилировать бльшую часть xv6, и это было замечательно2.

Февраль родился наш CPU под названием GAIA!


В порте на MIPS я завершил инициализацию PIC, что представляло огромную проблему, а также завершил реализацию обработчика прерываний. В результате этого портирование Xv6 на MIPS было завершено до этапа запуска первой пользовательской программы.

На основании своего опыта я создал проект спецификации прерываний и преобразования виртуальных адресов нашего самодельного CPU. Чтобы не усложнять его, мы решили не включать в него механизмы аппаратных привилегий, например, кольцевую защиту. Для преобразования виртуальных адресов мы решили, как и в x86, использовать методику аппаратного обхода страниц. Может показаться, что это сложно реализовать аппаратно, но мы посчитали, что так будет менее затратно, если мы пожертвуем скоростью и исключим реализацию TLB. В конечном итоге, позже Юити создал превосходное ядро CPU, в которое с самого начала был установлен TLB.

Юити завершил общую архитектуру набора команд нашего процессора. Он назвал наш CPU GAIA. Обычно в экспериментах с CPU мы не реализуем ни прерываний, ни MMU. Однако Юити начал реализовывать их для Xv6 на основании рефакторизованной версии процессора Group 3.

В дальнейшем я перейду к еженедельным записям, потому что с этого момента процесс начнёт развиваться быстро!

Первая неделя


Вместо того, чтобы просто закомментировать последовательности загрузки, Масаеси начал реализацию настоящей инициализации нашего CPU, а Сёхэй переписал код ассемблера x86 операционной системы Xv6 под нашу самодельную архитектуру. Я добавил в симулятор возможность симуляции прерываний, которую Ватару создал в базовой части экспериментов с CPU, а также завершил поддержку преобразования виртуальных адресов. Мы реализовали в симуляторе функциональность, достаточную для запуска ОС.

Вторая неделя


Я создал примитивный компоновщик для нашей архитектуры, чтобы собирать Xv6 и её двоичные объекты. Сёхэй работал над реализацией обработчика прерываний, и это была сложная задача. Прерывания трудно понять, тяжело разобраться с потоком, тяжело отлаживать, тяжело разрабатывать.

Когда я портировал Xv6 на MIPS, у меня был GDB, поэтому было довольно сносно, но в нашем эмуляторе не было никаких функций отладки, поэтому её выполнять, наверно, было очень трудно. Сёхэй не смог выдержать сложность отладки, поэтому он добавил в симулятор дизассемблер и отладочную функцию дампа. После этого отладочные функции симулятора были быстро усовершенствованы командой разработки ОС, и симулятор, наконец, вырос и стал похожим на это изображение:

image

Третья неделя


Превозмогая различные трудности, мы продолжали портирование Xv6, но ОС по-прежнему не работала.

В частности, вызывала много проблем спецификация Ucc, в которой char и int занимали 32 бита. Это была не вина Ucc. На самом деле, спецификация C требует только, чтобы sizeof(char) == 1 и sizeof(char) <= sizeof(int), поэтому в этом не было нарушений.

Однако, xv6 написана для x86, поэтому она предполагает, что sizeof(int) == 4 и добавляет константы к значению указателя, что приводило ко множеству противоречий. Поскольку создаваемый этим баг было так трудно найти, а объём был настолько велик, что в конечном итоге мы решили указать в Ucc, что char равен 8 битам.

Делегировав проблему 32-битного char команде разработчиков Ucc, я написал инициализацию страничной адресации этапа начальных вводов, и путём проб и ошибок пытался заставить правильно работать прерывания.

В конечном итоге, мы упорно трудились над решением задачи 4, Плохой портируемости xv6.

27, 28 февраля


Перечитав Slack, я увидел, что за этот день был сделан большой шаг вперёд. После того, как команда разработчиков Ucc очень быстро завершила изменение, сделав char 8-битным, мы упорно работали над большим объёмом отладки. Наконец, наша первая пользовательская программа init всё-таки заработала!

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

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

Этот баг сложно было устранить с низкими затратами на стороне оборудовании, поэтому мы устранили его, добавив в Xv6 цвет страниц. Для каждой строки кэша добавляется цвет и страницы выделяются так, что виртуальные адреса, указывающие на один физический адрес, всегда получают одинаковый цвет. Это означает, что виртуальные адреса, указывающие на один физический адрес, всегда будут иметь только один кэш. Так мы гарантируем, что GAIA никогда не будет иметь нескольких кэшей с общим физическим адресом.

Март Xv6 запускается!


Первого марта порт xv6 был завершён. Теперь xv6 работала в симуляторе!

image

Развлечений всегда должно быть с запасом


Изначально порт Xv6 рассматривался как развлечение, и поскольку Xv6 начала работать в симуляторе, мы стали трудиться над тем, чтобы развлечений стало ещё больше.

Во-первых, примерно за 4 часа Масаеси создал команду sl, запускаемую на нашем Xv6.


Сёхэй захотел написать Сапёра.


В это время Юити завершил реализацию процессора Group X. Реальный CPU работал гораздо быстрее симулятора, благодаря чему игру стало проще разрабатывать и играть в неё. Тогда же было создано очень качественное приложение 2048.


Эта игра 2048 получилась очень качественной, Юити постоянно в неё играл. Кстати, 2048 использует нелинейный буферизованный ввод, но в xv6 изначально этой функции не было. Для поддержки этой функции в дополнение к read и write в качестве devsw-действия было добавлено ioctl, а также связанные с termios функции для управления ICANON и echo. То есть единственная Xv6, способная играть в 2048 с подобной степенью полноты, есть только на GAIA.

Кстати, чтобы реализовать в Xv6 более близкую к Unix V6 схему, было бы лучше, по моему мнению, добавить системные вызовы gtty и stty. Однако я использовал ioctl, потому что Xv6 не имеет концепции tty, а также потому что ioctl появилась в следующей версии (V7), которая исторически близка к V6.

Есть и более крутые новости: на Xv6-GAIA появился небольшой ассемблер, созданный Кэйити. Также на нём есть миниатюрный vi, созданный Сёхэем. Только представьте, что можно сделать с этими двумя инструментами.



Это интерактивное программирование на FPGA!

Для эксперимента с CPU это довольно впечатляющее демо, ведь на этом процессоре нет никаких интерактивных программ.

Самое лучшее демо


Исходная задача эксперимента с CPU звучала так: Запустить на самодельном процессоре определённую программу трассировки лучей. Теперь, когда у нас есть работающая на процессоре операционная система, мы все знаем, что нужно сделать, правда? Мы решили запустить программу трассировки лучей в ОС нашего собственного CPU. У нас возникло несколько багов, однако нам удалось завершить её за час до финальной презентации.


Итак, мы выполнили то, о чём наверняка хотя бы раз шутил каждый студент нашей кафедры: запустили операционную систему на CPU, а поверх неё программу трассировки лучей.

Взгляд из 2020 года


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

Кстати, вы можете увидеть, как в то время выглядела Xv6, прямо в браузере, пройдя по ссылке! После эксперимента с CPU я портировал при помощи Emscripten наш симулятор GAIA на JavaScript. Давайте попробуем запустить наши sl, minesweeper и 2048.

xv6...cpu0: startinginit: starting sh$

Также стоит сказать, что портирование Xv6 на MIPS, которое не было закончено во время эксперимента с CPU, завершили месяц спустя. Репозиторий GitHub находится здесь.

После того, как мы опубликовали в 2015 году пост о челлендже Group X, следующие поколения студентов продолжили брать новые задания, связанные с ОС.

В 2018 году одни студенты запустили собственную ОС поверх самодельного CPU, а в 2019 году группа других студентов запустила собственную ОС, использовав в ISA самодельного CPU команды RISC-V. Кроме того, группа в 2020 году наконец-то запустила операционную систему Linux поверх самодельного CPU, в качестве ISA которого также использовалась RISC-V3.

Я уверен, что в будущем будет гораздо больше таких историй, поэтому следите за ними. Лично я ожидаю, что когда-нибудь кто-то запустит Linux на собственной ISA, или запустит на ней виртуальную машину.

Обычно говорят, что изобретать велосипеды заново не стоит, но в процессе изобретения можно довольно многому научиться. Он заставил меня осознать, что я не понимал всего этого настолько хорошо, чтобы реализовать всё с нуля. Кроме того, я рекомендую вам это сделать, потому что это чертовски увлекательно!

Это конец истории нашего эксперимента с CPU. Если вы заинтересовались изобретением замечательного велосипеда, то попробуйте создать процессор или портировать на него ОС.

В конце я хочу рассказать об участниках Group X.




  1. Если вы знаете японский, то можете прочитать мой предыдущий пост здесь. Я работаю в Microsoft, и не все мои коллеги понимают японский, поэтому я написал этот пост на английском.
  2. Кэйити сказал мне, что одной из причин быстрого роста Ucc заключалась в том, что они писали Ucc на OCaml. OCaml позволяет с лёгкостью манипулировать структурой дерева без багов указателей. Кстати, если вас интересует этап препроцессора, то мы использовали Clang CPP. Вы знали, что Clang CPP можно использовать как независимую команду? Кэйити написал на японском свою статью о команде разработчиков компилятора.
  3. Все статьи написаны на японском. Статьи группы, запускавшей собственную ОС поверх самодельного CPU в 2018 году находятся здесь, статьи группы, запускавшей свою ОС на процессоре RISC-V в 2019 году здесь, а статьи группы, запустившей Linux на своём процессоре RISC-V в 2020 году здесь.
Подробнее..

Перевод Как малоизвестный британский производитель ПК изобрел ARM и изменил мир

23.12.2020 16:22:50 | Автор: admin

Acorn Archimedes 1987 года стала первой серией персональных компьютеров на базе RISC.

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

Телефоны и большая часть нашего цифрового окружения работают на семействе процессоров ARM. Apple выпустил совершенно новую линейку компьютеров Mac на базе своего нового процессора M1 процессора на базе ARM и эти машины получают фантастические отзывы. Поэтому самое время напомнить о странных корнях этих микросхем, распространившихся по всему миру.

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

Но что, если вместо этого вы решили бы сделать так, чтобы все эти процессоры были созданы малоизвестной компанией из страны, которая, как правило, не первая, которая приходит на ум в качестве мирового лидера в области высокотехнологичных инноваций (по крайней мере не с 1800-х годов)? А что, если бы этот ЦПУ был обязан своим существованием, по крайней мере косвенно, образовательному телешоу? Скорее всего, продюсеры посоветуют вам немного отмотать сценарий Давай же, отнесись к этому серьезно. И все же почему-то на самом деле это именно так.

Вначале было телевидение

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

Все началось с телешоу 1982 года на BBC под названием Компьютерная программа. Это была попытка BBC рассказать британцам о том, что, черт возьми, это за новые модные машины, похожие на пишущие машинки, подключенные к телеку.

Шоу было частью более крупного проекта компьютерной грамотности, запущенного британским правительством и BBC в ответ на опасения, что Великобритания была совершенно не готова к революции в области персональных компьютеров, которая происходила в Америке. В отличие от большинства телешоу, BBC хотела использовать в сериале компьютер для объяснения фундаментальных вычислительных концепций и базового обучения программированию на языке BASIC. Концепции включали графику и звук, возможность подключения к сетям телетекста, синтез речи и даже элементарный ИИ. Поэтому компьютер, необходимый для шоу, должен был быть довольно хорошим. Требования продюсеров изначально были даже настолько высоки, что ничто на рынке не удовлетворяло потребности BBC.

Итак, BBC обратилась с призывом к молодой компьютерной индустрии Великобритании, в которой тогда доминировала компания Sinclair, которая сделала свое состояние на калькуляторах и крошечных телевизорах. В конечном итоге прибыльный контракт получила гораздо меньшая молодая компания Acorn Computers.

Расцвет Acorn

Acorn, компания родом из Кембриджа, начала свою деятельность в 1979 году после разработки компьютерных систем, изначально предназначенных для работы игровых автоматов, которые затем превратила в небольшие любительские компьютерные системы на базе процессоров 6502. Это было то же семейство процессоров, которое среди многих других использовалось в компьютерах Apple II, Atari 2600 и Commodore 64. Дизайн этого процессора станет важным позже.

Acorn разработала домашний компьютер под названием Atom, и когда появилась эта возможность от BBC, они начали планы по развитию преемника Atom в BBC Micro.

Список необходимых фичей от BBC гарантировал, что получившаяся машина будет достаточно мощной для той эпохи, хотя и не такой мощной, как оригинальная разработка Acorn преемника Atom. Этот преемник Atom имел бы два процессора, проверенный временем 6502 и еще не определившийся 16-разрядный процессор.

Позже Acorn отказался от этого процессора, но сохранил интерфейсную систему, называемую Tube, которая позволяла подключать дополнительные процессоры к машине. (Это тоже станет позже важным)

Разработка BBC Micro действительно раздвинула пределы возможностей Acorn, поскольку это была довольно современная машина для того времени. В результате были приняты некоторые сырые, но работоспособные инженерные решения, как например необходимость повторить размещение пальца инженера на материнской плате с помощью блока резисторов, чтобы заставить машину работать.

Никто так и не понял, почему машина работает только тогда, когда палец помещен в определенную точку на материнской плате, но как только они смогли сымитировать прикосновение пальца с помощью резисторов и убедились, что это работает, они двинулись дальше.

Послушайте, что рассказывает один из ключевых инженеров:

BBC Micro оказался большим успехом для Acorn, став доминирующим компьютером для образовательных целей в Великобритании в 1980-х годах. Каждый читатель этой статьи наверняка знает, что 80-е годы были очень важным временем в истории компьютеров. Персональный компьютер от IBM был выпущен в 1981 году, установив стандарт для ПК на десятилетия вперед. ПК Apple Lisa в 1983 году предвосхитила Mac и революцию графического пользовательского интерфейса окна-значки-мышь, который будет доминировать в будущем.

Acorn видел, как происходят эти разработки, и понял, что им понадобится что-то более мощное, чем стареющий, но надежный 6502, для питания своих будущих машин, если они хотят конкурировать. Acorn экспериментировал с множеством 16-битных процессоров: 65816, 16-битным вариантом 6502, Motorola 68000, на котором установлен Apple Macintosh, и сравнительно редким National Semiconductor 32016.

Однако ни один из них на самом деле не выполнял свою работу, и Acorn обратилась к Intel с просьбой внедрить процессоры Intel 80286 в их новую архитектуру. Intel их проигнорировала.

RISCованный бизнес

Спойлер: это окажется очень плохим решением для Intel.

Затем компания Acorn приняла судьбоносное решение разработать собственный процессор. Вдохновленный бережливым производством Western Design Center (компания, которая разрабатывала новые версии 6502) и исследованиями нового типа концепции проектирования процессоров, называемых компьютер с сокращённым набором команд (англ. Restricted (reduced) Instruction Set Computer, сокращ. RISC), Acorn решила двигаться вперед. Инженеры Стив Фербер и Софи Уилсон оказались ключевыми участниками проекта.

Теперь процессоры RISC называются так, как они называются по сравнению с процессорами CISC (англ. complex instruction set computing или complex instruction set computer, сокращ.). Попытаюсь дать очень упрощенное объяснение того, что это на самом деле означает.

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

У RISC, как вы, наверное, уже догадались, наоборот меньше инструкций, меньше деталей на самом чипе, и каждая инструкция может быть выполнена за один такт. В результате код оказывается длиннее и кажется менее эффективным, но сам чип проще и может выполнять простые инструкции быстрее.

Компания Acorn хорошо подходила для разработки процессора RISC, поскольку чип 6502, с которым они были хорошо знакомы, часто называют своего рода прототипом дизайна RISC. Интернет полон всевозможных мнений по этому поводу, и я не собираюсь порождать болезненный и утомительный спор, но хотя бы в благодарность этой статье просто поверьте мне, что 6502 обладает по крайней мере некоторыми чертами, очень похожими на RISC.

Новый чип Acorn был настолько RISC-подобен, что Софи Уилсон, разрабатывая набор инструкций для нового процессора Acorn, кажется, явно вдохновлялась рядом концепций дизайна 6502.

Используя интерфейс BBC Micro Tube в качестве испытательного стенда, новый процессор на базе RISC, разработанный Acorn, был назван Acorn RISC Machine, или ARM. Поставщик микросхем Acorn, компания VLSI, начала производить процессоры ARM, в первую очередь для внутреннего R&D Acorn. Вскоре после этого была готова серийная версия ARM2.

В 1987 году был представлен первый серийный ПК на базе RISC, Acorn Archimedes, работающий на процессоре ARM2. ARM показал лучшую производительность, чем Intel 286, несмотря на то, что в нем на 245 000 транзисторов меньше, чем у большого чипа Intel.

Archimedes с его ОС Arthur в ПЗУ (постоянное запоминающее устройство) оказался гибкой, быстрой и мощной машиной. У него была хорошая графика для того времени, графический пользовательский интерфейс, а также несколько крутых и быстрых низкополигональных демонстраций и игр, которые демонстрировали скорость машины благодаря ее процессору.

В то время эта первая машина на базе ARM претендовала на звание самого быстрого персонального компьютера той эпохи с рейтингом производительности в несколько раз выше, чем у Intel 80286.

Меньше значит больше

Отсутствие транзисторов в ARM свидетельствовало об относительной простоте самого ARM, и в результате чип потреблял гораздо меньше энергии и работал гораздо менее резво, чем что-либо еще из-за своей вычислительной мощности.

Низкое энергопотребление / низкое тепловыделение ARM не входило в состав первоначального задания на проектирование, поскольку Acorn проектировал процессор для настольного компьютера, но он, вероятно, является самым удачным и полезным незапланированным побочным продуктом в истории вычислительной техники.

Низкое энергопотребление и низкое тепловыделение сделали ARM подходящим для мобильных устройств, поэтому в конце 1980-х Apple начала искать процессор, достаточно мощный, чтобы (часто смешно) переводить рукописный текст в текст и запускать графический интерфейс, при этом питаясь от батареек типа АА. Карманное устройство, которое они хотели использовать, было печально известным Newton, и только быстрое и компактное ядро ARM могло питать его.

Apple и партнер Acorn по микросхемам VLSI заключили партнерство с Acorn, чтобы выделить подразделение ARM в свою собственную новую компанию под названием Advanced RISC Machines, что позволило сохранить название ARM. В рамках этого альянса, при добавлении значительных ресурсов Apple, ARM разработает ядро ARM6, при этом процессор ARM610 станет первым производственным чипом, основанным на этом ядре, а в версии с частотой 20 МГц будет использоваться для Apple Newton в 1993 году.

Хотя, конечно, Newton был своего рода впечатляющим провалом, в ретроспективе он станет чем-то гораздо большим: портативным устройством с сенсорным экраном на батарейках и процессором ARM. Сегодня то же самое описание можно использовать, чтобы описать миллиарды смартфонов, которые постоянно используются по всему миру. Впервые оно было испытано в полевых условиях с устройством, которое большинство людей помнит из того эпизода Симпсоны, где оно преобразовало рукописную фразу Ударь Мартина ("Beat up Martin") в Съешь Марту ("Eat up Martha")

ARM610 станет питанием нового поколения компьютеров Acorn Archimedes и странного ноутбука на базе Ньютона под названием eMate. В 2001 году 7-ядерный процессор ARM будет работать на iPod от Apple и игровой консоли Game Boy Advance от Nintendo. В 2004 году пара ARM будет управлять двумя экранами Nintendo DS.

Затем, в 2007 году, Apple выпустит первый iPhone с 11-ядерным процессором ARM. С этого момента все помешаются на ARM.

Процессоры ARM стали выбором по умолчанию для смартфонов, будь то Apple или что-либо другое. Процессоры ARM были в каждой думающей машине, кроме настольных компьютеров, ноутбуков или серверов на базе Intel. Теперь, с Chromebook и новыми настольными компьютерами и ноутбуками Apple MacOS на базе ARM, похоже, что ARM, наконец, вернется туда, откуда все начиналось к настольному компьютеру.

Так много лет спустя история происхождения ARM остается достойной рассказа, потому что она настолько невероятна; это такая странная, незапланированная последовательность событий из неожиданных источников. Несмотря на то, что сейчас этот процессор абсолютно доминирует в мире, скромные начинания делают его менее бесчувственным гигантом индустрии, чем, скажем, почти биополия (от монополия) Intel / AMD.

Можно воспользоваться моментом и задуматься: поскольку британцы чувствовали свое отставание от компьютерной революции, они решили снимать телешоу о компьютерах. Для этого им был нужен компьютер, и одна не самая прорывная компания создала его. И когда этой маленькой компании потребовалось создать более быстрый процессор, потому что Intel не потрудилась ответить на их звонки, они сделали свой собственный. Просто так случилось, что этот процессор не потребляет много энергии и не выделяет много тепла, что и привлекло внимание Apple, которая стала его использовать. После чего эта компания, конечно же, захватила мир.

Если бы я это выдумал, вы бы сказали, что я слишком извернулся или что посмотрел слишком много фильмов Уэса Андерсона. Но это реальность.

Однако если реальность на самом деле является симуляцией, держу пари, что она тоже работает на ARM.


Реклама которая может быть полезна

Прямо сейчас в OTUS действуют максимальные новогодние скидки на все курсы. Ознакомиться с полным списком курсов вы можете по ссылке ниже. Также у всех желающих есть уникальная возможность отправить адресатуподарочный сертификат на обучение в OTUS.

Кстати, о "красивой упаковке" онлайн-сертификатов мырассказываем в этой статье.

ЗАБРАТЬ СКИДКУ

Подробнее..

Почему мы используем платформу ARM в промышленном оборудовании

16.06.2020 10:18:24 | Автор: admin


Сегодня почти каждый из нас использует устройства на базе ARM-процессоров это смартфоны, телевизоры и даже холодильники с кофеварками. Несколько дней назад в прессу просочились слухи, что компания Apple объявит о переходе с платформы X86 на ARM на своих ноутбуках.

Мы в Advantech уже много лет производим устройства на платформе ARM и на это множество причин. В этой статье мы разберем что такое ARM (от англ. Advanced RISC Machine), в чем ее отличие от других архитектур и почему все больше производителей выбирает эту архитектуру.



Наборы инструкций RISC vs CISC





Для начала следует разобраться в чем принципиальное отличие процессоров ARM и X86. Для того, чтобы программисты смогли писать программы, работающие на разных процессорах, производители договорились унифицировать набор машинных инструкций до определенного формата и соблюдать его в разных моделях своих процессоров. Машинные инструкции это низкоуровневые команды, которые отвечают за базовые операции вроде записи/чтения/модификации данных в памяти, арифметику и т.д.
Существует несколько основных концепций, используемых при проектировании процессоров. Наиболее популярные и широко известные всем это RISC и CISC.

CISC (англ. Complex Instruction Set Computing) этот подход используется для разработки универсальных и мощных процессоров, которые обычно используются в десктопных компьютерах и на серверах. Такие процессоры как Intel CoreiN/Xeon/Pentium, AMD Ryzen/Atlhon/Sempron и прочие хорошие знакомые процессоры имеют набор инструкций типа CISC, оформленную в виде стандарта x86.

Основные особенности концепции CISC:

  • Большой набор машинных команд разного формата для разного типа задач
  • Сложный формат кодировки инструкций
  • Много разных форматов адресации
  • Выполнение вспомогательных программ в микрокоде процессора
  • Более высокое энергопотребление
  • Высокая цена


Процессоры типа CISC имеют более сложную архитектуру и обычно имеют вспомогательные программы работающие прямо в процессоре для упрощения работы программистов.

RISC (англ. reduced instruction set computer) противоположная концепция проектирования процессоров. В RISC команды максимально упрощены и имеют более строгий формат и фиксированную длину. За счет упрощенных инструкций достигается высокая производительность при малом энергопотреблении. Процессоры RISC требуют от программиста большой контроль над выполнением кода, так как не имеют встроенных микропрограмм, работающих внутри процессора. Архитектура ARM (от англ. Advanced RISC Machine усовершенствованная RISC-машина) это продолжение идеи архитектуры RISC развиваемое компанией ARM Limited. Сегодня множество компаний производят свои собственные ARM процессоры по лицензии от ARM Limited например, популярные в смартфонах Qualcomm Snapdragon, Mediatek, Allwiner, Apple An/Hn а также популярные во встраиваемых системах Freescale i.MX, Broadcom, Nvidia Tegra и другие.

Основные особенности концепции RISC:

  • Упрощенные инструкции фиксированной длины
  • Меньшее энергопотребление
  • Больший контроль над работой со стороны исполняемых программ
  • Более сложные программы


Архитектура ARM значительно расширяет коценпцию RISC. Современные ARM-процессоры часто поставляются в формате SoC (System On Chip) и имеют на одном кристалле с процессором контроллер памяти, графическое ядро, аудио интерфейс, модули беспроводной связи и многое другое. Это позволяет производителям оборудования не тратить ресурсы на разработку собственных сложных систем под каждое устройство отдельно, а интегрировать уже готовую аппартную платформу, сосредточившись только на разработке необходимых функций конечного продукта.

X86 медленно развивается



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


Современные X86 процессоры имеют десятки ядер

Попытки Intel создать энергоэффективный X86-процессор Atom были достаточно успешны, но кроме маломощных десктопов, ноутбуков и встраиваемых систем, этот процессор мало для чего подходит.

ARM это экономично и современно



Современные ARM-процессоры развиваются очень быстро. Каждый год выходят чипы существенно лучше своих предшественников. На данный момент средняя производительность ARM чипов все еще остается ниже X86, но в некоторых синтетических тестах они уже почти сравнялись. Совершенно очевидно, что в будущем наши ноутбуки, и, возможно, десктопные компьютеры, будут работать на ARM-процессорах. Переходов ноутбуков Apple на собственные ARM-процессоры должно дать большой толчок всей индустрии в этом направлении.

Основные достоинства процессоров ARM:

  • Цена специфичные процессоры ARM могут стоить очень дешево, в сравнении с самыми дешевыми X86 разница может в несколько порядков.
  • Энергопотребление низкое энергопотребление позволяет производить устройства с автономным питанием а также более компактные устройства за счет более низкого энергопотреблениях и меньших системах охлаждения
  • Размеры процессоры ARM могут быть очень компактного размера, не требующие даже пассивного охлаждения, при этом достаточно мощные. Это позволяет производить устройства очень компактного размера, недостижимого с процессорами X86.


Устройства Advantech на платформе ARM


Advantech давно производит продукты на базе платформы ARM для разных отраслей и задач. От промышленных контроллеров, до сетевого оборудования и компактных компьютеров. Мы уже рассказывали о некоторых наших продуктах на ARM в других статьях.

WISE-710 IoT-шлюз на базе i.MX6



WISE-710 универсальное устройство, которое одновременно может быть шлюзом для промышленных интерфейсов, устройством сбора и обработки данных, хабом для IoT устройств и маршрутизатором. Построено на базе SoC i.MX6, процессора на архитектуре ARM Cortex-A7.

ECU-1152 Шлюз для промышленных интерфейсов на базе ARM Cortex A8



ECU-1152 шлюз для промышленных интерфейсов а также устройство для связи с объектом и устройства сбора и передачи данных с объекта. Построено на базе процессора ARM процессора с ядром Cortex A8

Миниатюрный ARM-компьютер UNO-1251G



UNO-1251G крохотных компьютер, умещающийся на DIN-рейку, на базе 32-битного процессора Cortex A8 под управлением Linux или Windows CE. Поддерживает модули расширения Wi-Fi/3G/4G. Имеет встроенную CAN-шину и два интерфейса RS-232. Два порта LAN позволяют подключать его к двум независимым Ethernet сетям или использовать как маршрутизатор.

Компьютеры для машинного обучения на базе Nvidia Jetson
image
MIC-720AI построен на базе платформы Jetson TX2, работающей на собственных ядрах Nvidia ARM Cortex-A57 и NVIDIA Denver 2 с полностью пассивным охлаждением. Предназначен для установки в промышленные системы машинного зрения, на производстве и в подвижных объектах. Безвентиляторная конструкция обеспечивает полную бесшумность в работе и позволяет использовать компьютер в пыльных помещениях без необходимости обслуживания. Работает под управлением Linux

Будущее за ARM


Наверняка архитектура X86 с нами еще надолго. Все профессиональные высокопроизводительные вычисления пока делаются на этой платформе. Под X86 написаны основные десктопные операционные системы и прикладные программы. Однако уже сегодня ARM активно вытесняет устаревший X86 даже в сфере больших вычислений. Платформы вроде Nvidia Jetson сравнимы по производительности, а в некоторых задачах и превосходят системы на базе X86. Так что нас обязательно ждет яркое противостояние двух платформ, от которой в конечном счете потребители только выйграют.

Расскажите как вы используете ARM-процессоры сегодня или как планируете использовать в будущем.
Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru