Архивы: по дате | по разделам | по авторам

Свет в конце туннеля

Архив
автор : Крис Касперски   07.09.1999

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

Френк Херберт. "Дюна"
Маленькая белая крыска с нежно-розовым хвостиком и красными, словно нарисованными глазками-бусинками сосредоточенно перебирала лапками, пытаясь взобраться по беличьему колесу. Когда очередная жердочка под ней неумолимо ушла вниз, крыска несдержанно зафырчала и принялась перебирать лапками еще быстрее. Но это только ускорило вращение колеса.

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

Наращивать тактовую частоту день ото дня становилось все труднее. Тогда разработчики пошли другим путем: оптимизировали исполнительные цепи, чтобы большинство команд исполнялось всего за один такт микропроцессора, ввели новые инструкции и векторные операции (технологии MMX и 3Dnow!)...

Сегодня можно с уверенностью сказать, что RISC- и CISC-архитектуры исчерпали себя, достигнув сопоставимой производительности. Но программисты, словно не заметив этого, все еще продолжают "утяжелять" программное обеспечение: Windows 2000 будет построена на объектах COM и COM+. С точки зрения разработчиков это хорошо, ибо позволит писать более устойчивый и свободный от ошибок программный код, но с точки зрения микропроцессора один только вызов объекта COM+ распадается на тысячи команд и очень-очень много тактов.

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

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

СУПЕРСКАЛЯРНАЯ АРХИТЕКТУРА

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

MOV AX,1234h ; Записать в регистр AX число 1234h
MOV CX,DX ; Записать в регистр CX значение регистра DX


Достаточно лишь, чтобы устройство выборки инструкций позволяло декодировать обе команды за один такт. Для RISC с их фиксированной длиной команд это вообще не составляло никакой проблемы (подробнее - в статье "RISC vs. CISC").

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

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

MOV AX,1234h ; Записать в регистр AX число 1234h
ADD DX,AX ; Сложить содержимое регистра DX с регистром AX


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

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

В самом деле, если пример, приведенный выше, переписать как

MOV AX,1234h
ADD DX,1234h


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

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

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

MOV AX,1234h ; Записать в регистр AX число 1234h
ADD DX,AX ; Сложить содержимое регистра DX с регистром AX
MOV CX,666h ; Записать в регистр CX число 666h
ADD BX.CX ; Сложить содержимое регистра BX с регистром CX


Можно исполнить в другом порядке:

MOV AX,1234h ; Записать в регистр AX число 1234h
MOV CX,666h ; Записать в регистр CX число 666h
ADD DX,AX ; Сложить содержимое регистра DX с регистром AX
ADD BX.CX ; Сложить содержимое регистра BX с регистром CX


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

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

MOV AX,1234h ; Записать в регистр AX число 1234h
ADD DX,AX ; Сложить содержимое регистра DX с регистром AX
MOV AX,666h ; Записать в регистр CX число 666h
ADD BX.AX ; Сложить содержимое регистра BX с регистром AX


Теперь уже невозможно одновременно выполнить первую и третью строки, однако этой, казалось бы, на первый взгляд, неразрешимой проблеме быстро было найдено красивое решение. В действительности зависимость между двумя командами ложная. Очевидно (даже машине), что должны использоваться дополнительные регистры. Но что нас ограничивает? Давайте переименуем регистры в AX~1 и AX~2 соответственно. Тогда получим следующий код:

MOV AX~1,1234h ; Записать в регистр AX число 1234h
ADD DX, AX~1 ; Сложить содержимое регистра DX с регистром AX
MOV AX~2,666h ; Записать в регистр CX число 666h
ADD BX, AX~2 ; Сложить содержимое регистра BX с регистром AX


Разумеется, теперь никаких проблем с параллельным исполнением уже не возникнет. Конечно же, потребуется больше регистров! Но регистры дешевы (всего лишь набор триггеров из 4-6 транзисторов), а за быстродействие потребитель деньги охотно заплатит.

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

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

ПАРАЛЛЕЛИЗМ В МИКРОПРОЦЕССОРАХ RISC и CISC

Микропроцессоры PowerPC (RISC)

Процессор PowerPC был разработан в результате тесного сотрудничества ведущих производителей индустрии - IBM, Apple и Motorola. Он воплотил в себе гений тысяч инженеров, долгое время был лидером среди собратьев в отношении цена/производительность.

Суперскалярное RISC-ядро позволяло за один такт выполнять до четырех команд благодаря четырем конвейерам выборки и шести независимым функциональным устройствам: трем целочисленным АЛУ, блоку вещественной арифметики (обрабатывающему числа с плавающей точкой), модулю чтения\записи результатов и блоку переходов. Для параллельного исполнения выборка инструкций должна соответствовать набору имеющихся устройств. Четыре целочисленные операции за один такт не выполнятся, а вот три целочисленные и одна вещественная могут.

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

При этом результаты работы команд записываются в промежуточный кэш-буфер, который обнуляется в случае ошибочного предсказания. Что представляет собой динамическое предсказание ветвлений? В микропроцессорах PowerPC использован простой и надежный механизм таблицы предыстории переходов (или, говоря красивым техническим языком, BTH - Branch History Table).

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

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

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

Микропроцессор Pentium Pro

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

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

Конвейеров у Pentium Pro два  [1]. Однако это еще не означает, что Pentium способен выполнить две любые инструкции параллельно. Исходя из сложности команд CISC и того факта, что каждая инструкция может задействовать произвольное (читай: временами очень большое) число функциональных устройств микропроцессора, их все пришлось бы дублировать. В результате далеко не всякие инструкции выполняются параллельно.

Для борьбы с иррегулярными переходами в Pentium был использован значительно более сложный по сравнению с RISC-системами статически-динамический анализатор условия ветвления вместе с детектором вложенных конструкций (например, вложенных циклов). Но даже этот механизм не позволил достичь свыше 80 процентов угадываний.

Видно, что у RISC-микропроцессоров параллелизм выражен в большей степени, чем у CISC. Фиксированная (или близкая к ней) длина инструкций облегчила разработку многоконвейерных реализаций. Простые инструкции по отдельности задействовали лишь одно функциональное устройство. Например, типичная CISC-операция:

ADD AX, [SI+BX+66h]

Необходимо разобрать сложное поле адресации, чтобы понять, что это именно "SI+BX+66h", а не что-то другое; сложить (то есть вычислить этот результат), затем загрузить содержимое требуемой ячейки и, наконец, опять сложить его со значением регистра AX.

Следовательно, для выполнения инструкции за один такт требуется два арифметических устройства и один загрузчик. Но и в этом случае все действия должны выполняться последовательно. То есть ВЫЧИСЛЕНИЕ АДРЕСА, ЗАГРУЗКА, ВЫЧИСЛЕНИЕ РЕЗУЛЬТАТА. И никакие действия не могут быть спарены. Хоть умри, но потребуется три такта на выполнение, или хотя бы одно из устройств должно функционировать на удвоенной тактовой частоте.

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

ВЫБОР ДРУГОГО ПУТИ

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

Однако новая технология не давала никакого выигрыша на старых приложениях - не спасала даже перекомпиляция. Существенно повлиять на быстродействие могло только принципиальное изменение идеологии программирования: переход на векторные операции  [2].

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

AMD не отстала от конкурентов и активно продвигает на рынок свой вариант реализации MMX - технологию 3DNow!, ориентированную  [3] на вычисления, связанные с трехмерной графикой.

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

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

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

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

Но не приходим ли мы добровольно к RISC-концепции, вновь возвращаясь к началу на очередном витке прогресса? К тому же правила оптимизации даже у соседних моделей процессоров (например, Pentium 75, Pentium 100, Pentium 166 MMX, Pentium II) отличаются очень и очень. Настолько, что код, оптимизированный под один процессор, может исполняться медленнее неоптимизированного - на другом.

Воистину, "мартышкин труд". Это что же, при появлении нового микропроцессора перекомпилировать все программное обеспечение заново? Поставлять покупателю исходные тексты с компилятором?  [4] Или пытаться в ущерб производительности найти компромиссный вариант? Причем любое решение было бы надругательством над самой концепцией суперскалярной архитектуры: параллелизм распознает сам процессор, и ему не требуется помощи со стороны компилятора.

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

VLIW (процессоры с длинным командным словом)

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

Почему? Да потому, что параллелизм - это... как бы помягче выразиться? Нет, не плохо, скорее всего - излишне сложно и непривычно, и сопряжено с трудностями в разработке компиляторов.  [5]

Однако на рубеже второго тысячелетия компьютерная индустрия завела себя в тупик. Считается, что с поправкой на ионный ветер и длину волны излучателя, который рисует матрицу будущего кристалла, вкупе с некоторыми другими эффектами, невозможно (читай: технически неоправданно сложно) перейти порог 0,1 мкм в ближайшие десять лет, а выпускаемые сейчас по 0,18-мкм технологии микропроцессоры его уже почти достигли. (Texas Instruments уже разработала технологический процесс с проектными нормами 0,07 мкм. - Г.Б.)

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

Менее проблематичным выглядит увеличение слоев металлизации. Технически это нетрудно, но вот экономически - неоправданно. Вероятность брака растет экспоненциально. Именно этим (высоким процентом брака) в первую очередь и объясняется значительная стоимость процессора Pentium Pro.

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

Архитектура VLIW была известна и ранее, хотя процессоры на ее основе были мало распространены. Наиболее известные модели были выпущены ныне уже не существующей фирмой Multiflow Computer.  [6] В нашей стране по сходной архитектуре был построен суперкомпьютер "Эльбрус-3".

Из микропроцессоров, построенных по VLIW-архитектуре, можно назвать только семейство сигнальных чипов TMS320C6x фирмы Texas Instruments. Эта архитектура не стала бы знаменитой, если бы именно на нее не обратили внимание компании HP и Intel при разработке микропроцессора нового поколения Merced. Поэтому есть смысл рассмотреть ее подробнее.

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

- все три команды выполняются параллельно;
- сначала выполняются первые две команды, потом третья;
- выполняется одна команда, а затем параллельно последующие две.

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

Неплохой результат, верно? Особенно если вспомнить, что RISC были способны выполнить не более четырех команд, а CISC - и вовсе двух, тогда как для VLIW девять (или 16 = 4 по 4) инструкций не предел. Более того: если суперскалярные архитектуры только некоторые - удачные - команды исполняли параллельно, то VLIW - в большинстве случаев. Поэтому производительность может повышаться в десятки раз при незначительном аппаратном усложнении конструкции.

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

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

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

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

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

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

Другой характерной для RISC чертой будет разделение инструкций по категориям: чтения/записи в память и вычислительных операций. Это облегчит распараллеливание вычислений. Разумеется, и набор регистров обещает быть солидным. В том же Merced одних только целочисленных регистров планируется 128!

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

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

Таким образом, современная реализация VLIW-архитектуры наследует концепции и RISC, и CISC.

ВЗГЛЯД ИЗ ТОННЕЛЯ

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

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



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

2 (обратно к тексту) - В отличие от скалярных, операндами векторных операций являются массивы чисел (векторы), а не скаляры.

3 (обратно к тексту) - Как видно из ее названия.

4 (обратно к тексту) - Open Source, ау...

5 (обратно к тексту) - О программировании на низком уровне мы и не говорим. Оно сопряжено со слишком большими трудозатратами и малоэффективно. Рассказывают, что некогда один программист параллельных архитектур воскликнул: "А не быстрее ли будет все это рассчитать на калькуляторе, чем программировать эту машину?". Не знаю, как Гай Юлий Цезарь, а человек (программист - это ведь, в первую очередь, человек) привык мыслить поочередными, а не параллельными концепциями. Параллельное вычисление, несмотря на всю эффективность, все же неудобно. Сколько головной боли принесли программистам потоки в операционных системах, то есть возможность одновременного исполнения программы в разных местах. Точнее, даже не сами потоки, а проблемы их синхронизации и распределения вычислений таким образом, чтобы никогда один из потоков не простаивал в ожидании результатов другого.

6 (обратно к тексту) - Инженеры, работавшие в этой фирме, сейчас трудятся в HP над небезызвестным проектом Merced, но это уже другая история.



© ООО "Компьютерра-Онлайн", 1997-2022
При цитировании и использовании любых материалов ссылка на "Компьютерру" обязательна.