WikiDer > MAJC

MAJC
MAJC
ДизайнерSun Microsystems
Введено1990-е годы
ДизайнVLIW

MAJC (Архитектура микропроцессоров для вычислений на Java) была Sun Microsystems многоядерный, многопоточный, очень длинное командное слово (VLIW) микропроцессор дизайн с середины до конца 1990-х годов. Первоначально называвшийся процессором UltraJava, процессор MAJC предназначался для работы Ява программы, чья "поздняя компиляция" позволила Sun принять несколько благоприятных проектных решений. Процессор был выпущен в виде двух коммерческих графических карт от Sun. Извлеченные уроки, касающиеся многопоточности на многоядерном процессоре, послужили основой для дальнейшего OpenSPARC реализации, такие как UltraSPARC T1.

Элементы дизайна

Перенести планирование инструкций в компилятор

Как и другие конструкции VLIW, в частности Intelс IA-64 (Itanium) MAJC попытался повысить производительность, перенеся несколько дорогостоящих операций из процессора в соответствующие компиляторы. В целом, конструкции VLIW пытаются устранить планировщик инструкций, что часто составляет относительно большую часть общего транзисторного бюджета процессора. После удаления этой части ЦП в программное обеспечение эти транзисторы можно использовать для других целей, часто для добавления дополнительных функциональные единицы для одновременной обработки большего количества инструкций или увеличения количества кэш-память чтобы сократить время ожидания получения данных от гораздо более медленных основная память. Хотя MAJC разделяет эти общие концепции, он отличался от других проектов VLIW и процессоров в целом по ряду конкретных деталей.

Обобщенные функциональные блоки

Большинство процессоров включают в себя несколько отдельных «подпроцессоров», известных как функциональные единицы которые настроены на работу с определенным типом данных. Например, современный ЦП обычно имеет два или три функциональных блока, предназначенных для обработки. целое число данные и логические инструкции, известные как ALU, в то время как другие устройства обрабатывают плавающая точка числа, FPUs, или мультимедийные данные, SIMD. Вместо этого MAJC использовал единый многоцелевой функциональный блок, который мог обрабатывать любые данные. Теоретически такой подход означал, что обработка любого одного типа данных займет больше времени, возможно, намного дольше, чем обработка тех же данных в блоке, предназначенном для этого типа данных. Но с другой стороны, эти универсальные модули также означали, что у вас не останется неиспользованных больших частей ЦП, потому что программа просто выполняла много (например) вычислений с плавающей запятой в этот конкретный момент времени.

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

Другое отличие состоит в том, что MAJC допускает использование "переменной длины"пакеты инструкций", которые в рамках VLIW содержат ряд инструкций, которые, как определил компилятор, могут выполняться одновременно. Большинство архитектур VLIW используют пакеты фиксированной длины, и когда они не могут найти инструкцию для запуска, они вместо этого заполняют ее NOP, который просто занимает место. Хотя пакеты инструкций переменной длины усложняли ЦП, они уменьшали размер кода и, следовательно, количество дорогостоящих промахи в кеше увеличивая количество кода в кеше в любой момент.

Избегайте блокировок и срывов

Основное отличие заключалось в том, что дизайн MAJC требовал, чтобы компилятор избегал блокировки, приостанавливает выполнение, пока результаты одной инструкции должны быть обработаны, чтобы можно было запустить следующую. Например, если процессор получает инструкции С = А + В, Е = С + D, то вторая инструкция может быть запущена только после завершения первой. Большинство процессоров включают в себя блокировки, чтобы задержать и перепланировать эти виды взаимосвязанных инструкций, позволяя некоторым другим инструкциям выполняться, пока вычисляется значение C. Однако эти блокировки очень дороги с точки зрения занимаемой площади кристалла и представляют собой большую часть логики планировщика команд.

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

Это означает, что компилятор был привязан не к MAJC в целом, а к конкретная реализация MAJC, каждый отдельный ЦП основан на дизайне MAJC. Обычно это было бы серьезной логистической проблемой; рассмотреть количество различных вариаций Intel IA-32 Например, при разработке дизайна каждому из них потребуется свой собственный выделенный компилятор, а разработчик должен будет создать свой двоичный файл для каждого из них. Однако именно эта концепция движет рынком Java - действительно существует свой компилятор для каждого ЭТО, и он устанавливается на клиентском компьютере, а не на компьютере разработчика. Разработчик поставляет только один байт-код версия своей программы, и компьютер пользователя компилирует ее на базовую платформу.

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

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

MAJC продвинул эту идею еще на один шаг и попытался предварительно получить данные и инструкции, необходимые для потоков, пока они были остановлены. Большинство процессоров включают аналогичные функции для частей потока инструкций, известных как спекулятивное исполнение, где процессор выполняет оба возможных результата ветвления, ожидая вычисления решающей переменной. Вместо этого MAJC продолжал запускать поток, как если бы он не был остановлен, используя это выполнение для поиска и последующей загрузки любых данных или инструкций, которые вскоре потребуются, когда поток перестанет останавливаться. Sun назвал это Пространственно-временные вычисления (STC), и это спекулятивная многопоточность дизайн.

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

Реализации

Sun построила единственную модель MAJC, двухъядерную MAJC 5200, который был сердцем XVR-1000 и XVR-4000 компании Sun рабочая станция графические платы. Однако многие из идей многоядерного и многопоточного дизайна, особенно с точки зрения использования нескольких потоков для уменьшения задержек, нашли свое отражение в Sun SPARC линейка процессоров, а также разработки других компаний. Кроме того, идея MAJC о разработке процессора для запуска как можно большего количества потоков, а не инструкций, по-видимому, является основой более позднего UltraSPARC T1 (под кодовым названием Ниагара) дизайн.

Смотрите также

дальнейшее чтение

внешняя ссылка