Журнал Компьютерра - Журнал «Компьютерра» №38
Впрочем, полный провал i860 не помешал корпорациям Intel и Hewlett-Packard уже через два года инициировать разработку «суперпроцессора» Itanium, который должен был исправить ошибки 860-го процессора и стать заменой не только архитектуре x86, но и всем тогдашним RISC-архитектурам. Архитектура получила звучное название IA-64 (Intel Architecture for 64-bit), и поначалу казалось, что «пересадят» пользователей на Itanium едва ли не начиная с Pentium II. Itanium должен был с помощью специального полуаппаратного эмулятора поддерживать набор инструкций x86, так что переход с архитектуры IA-32 на IA-64 обещал быть безболезненным. «Крутизна» новинки была так очевидна, что Silicon Graphics, например, даже забросила разработку своей фирменной архитектуры MIPS, рассудив, что с Itanium ей все равно не сравниться.
Но если отбросить красивые слова и посмотреть, что получилось на практике, то следует признать, что проект Itanium «блестяще провалился». Вначале очень долго задерживался первый Itanium (Merced). Потом некстати вылезла со своими процессорами AMD и вынудила Intel ввязаться в «гонку мегагерц», по итогам которой «устаревшая» архитектура x86 сделала такой колоссальный рывок, что однозначного «суперпроцессора» из со скрипом появившегося на свет Itanium уже не получилось. Затем была проведена большая «работа над ошибками», в ходе которой производительность и «производственные» технические характеристики Itanium 2 значительно улучшились, так что «итаниумное» семейство с трудом, но все же завоевало лидерство в производительности (особенно при вычислениях с плавающей точкой, критичных для научных расчетов). Но принципиально это ситуацию не изменило. Перспективы для иного, кроме как High-End-применения, у Itanium сегодня печальные - фактически AMD убила его развитие своими 64-разрядными процессорами. Да, старшие модели 64-разрядных Opteron в среднем проигрывают старшим Itanium 2 по производительности; однако проигрыш этот невелик и компенсируется тем, что «Оптероны» гораздо дешевле и не требуют специальной адаптации уже имеющихся программ к IA-64. В итоге получилось так, что Intel, конечно, предпочла бы использовать свою архитектуру IA-64 вместо чужой архитектуры AMD64, однако выбирая между быстрой потерей большей части серверного рынка, занятого сегодня процессорами Xeon, и утратой надежды на то, что Xeon в обозримом будущем будет заменен на Itanium, Intel выбрала первый вариант. А после введения в «Зионах» технологии EM64T (копии AMD64) от развития собственных Itanium-систем отказалась большая часть поставщиков серверов, начиная с IBM и заканчивая Dell. Даже соразработчик Itanium компания Hewlett-Packard (как и SGI, которая ради IA-64 поставила крест на своей процессорной архитектуре PA-RISC) потихоньку сворачивает линейку продуктов на основе этих CPU. Так что злая ирония про «Itanic» (по аналогии с «Titanic») сегодня, к сожалению, уместна как никогда.
Кроме Intel попытку внедрить VLIW-архитектуру в повседневную жизнь предпринимала со своими x86-совместимыми процессорами небезызвестная Transmeta. У команды, в которой работал сам Линус Торвальдс, не было претензий на «новую сверхархитектуру», но процессоры они создали не менее интересные. Transmeta не стала проталкивать свой VLIW как индустриальный стандарт, а сосредоточилась на разработке специального софта, полностью имитирующего (программно!) на VLIW-процессоре обычную архитектуру x86. Производительностью такое решение не отличалось, но зато было простым (ибо VLIW архитектурно проще), дешевым (ибо простым) и потребляющим совсем немного энергии (в силу все той же простоты), что позволило Transmeta вполне успешно позиционировать свои CPU в нишу недорогих мобильных процессоров и даже процессоров для блейд-серверов. К сожалению, производственные трудности и появление технологии Centrino, которая свела конкуренцию на мобильном рынке почти к нулю, привели к тому, что Transmeta терпела огромные убытки. Так что судьба двух доступных пока VLIW-архитектур - Intel Itanium 2 и Transmeta Efficeon - очень похожа. Обе оказались вытеснены в узкоспециализированные ниши: Itanium 2 - в высокопроизводительную; Efficeon - в экономичную.
Концепция Cell
Итак, VLIW/EPIC на роль процессора завтрашнего дня пока не годится - те потенциальные преимущества, которыми она обладает, сегодня не оправдываются. Но существенные изменения в грядущих процессорах мы все-таки увидим.
Хотим мы того или нет, работать нам придется с многоядерными процессорами. Как уже говорилось, разработка нового процессорного ядра - дело весьма долгое даже при наличии опытной команды и чертежей предыдущей версии изделия; совершенствование технологических процессов, позволяющих уместить на одном кусочке кремния все больше транзисторов, происходит гораздо быстрее. Раньше это выливалось во все более «кэшастые» варианты одних и тех же архитектур и во все более «прямолинейные» варианты их разводки (пожертвовав площадью кристалла и увеличив его размеры, разводку можно сделать «более высокочастотной»); теперь же стало выгоднее просто устанавливать два-три-четыре одинаковых или почти одинаковых ядра в один кристалл или на одну подложку.
Но коль уж все равно нам светит повальный переход на параллельные алгоритмы (а параллельное программирование нетривиальных алгоритмов по праву считается одной из самых сложных современных задач), то имеет смысл уже сегодня заняться разработкой перспективных параллельных архитектур на основе принципиально новых концепций. Именно такой подход в лице процессора Cell (совместное детище Sony, Toshiba и IBM), возможно, и определит облик завтрашнего дня компьютинга.
По меркам же дня сегодняшнего Cell вызывает интерес своей необычностью и потрясающей футуристичностью: девять ядер, из которых одно главное, а восемь - вспомогательные; сумасшедшей пропускной способности интерфейсы и оперативная память Rambus; тактовая частота под три гигагерца. Но новизна процессора не в этом (вернее, не только в этом). Cell - это еще и попытка значительно пересмотреть существующие парадигмы программирования.
Cell в переводе на русский - ячейка. В концепции Cell существуют аппаратные и программные ячейки. Аппаратная ячейка - любой процессор, способный выполнять программные ячейки и связанный с другими процессорами. Программная ячейка - это данные, либо особая программа (apulet), описывающая, как следует обрабатывать данные. В идеале нет никаких самостоятельно существующих программ, нет процессоров и компьютеров. Есть только данные, код, который их обрабатывает, и абстрактная аппаратура, обеспечивающая существование того и другого. Не поняли? Смотрите: пусть у нас есть, например, передаваемый по Сети видеопоток.
Что такое видеопоток? На программном уровне это последовательность фреймов - небольших блоков данных, описывающих маленький кусочек (скажем, 0,1 с) видео или звуковой дорожки. В терминах Cell - поток ячеек, содержащих данные разного типа. Его воспроизведение можно представить как результат выполнения некоторой большой программы, с исходными данными в виде этого потока, а можно - как процесс многократного преобразования ячеек с данными, в ходе которого ячейки одного типа (например, сжатый звук) превращаются в ячейки другого типа (несжатый звук) маленькими программками (апулетами). Обычно все эти превращения запрятаны глубоко в некую всеобъемлющую программу, которая копирует поступающие данные в оперативную память, поочередно обрабатывает их разными алгоритмами и старается распределить обработку по нескольким процессорам. Идея Cell состоит в том, что вместо этой программно-ориентированной модели мы берем более естественную, ориентированную на данные модель декодирования видеопотока и сводим написание видеопроигрывателя к написанию инструкций типа «чтобы воспроизвести видеотрансляцию, нужно подключиться по такому-то адресу в Сети к источнику ячеек, преобразовать поступающий поток в поток ячеек со сжатым видео и сжатым звуком, преобразовать сжатый звук в несжатый, сжатое видео в несжатое, обработать несжатый звук эквалайзером и эффект-процессором, а к несжатому видео применить деинтерлейсинг, подогнать получившуюся картинку к размерам экрана, скорректировать яркость, насыщенность и контрастность и воспроизвести получившиеся аудио- и видеопотоки». Вот это и есть программа для Cell! В ней даже нет инструкций, указывающих, как делать все вышеописанное, - за «подробностями» Cell-устройство обращается к библиотеке алгоритмов, причем каждый алгоритм (апулет) - это тоже ячейка, которую, к примеру, можно на лету скачать из Сети с того же самого источника видеотрансляции. А какое железо и какая операционная система обеспечивает этот процесс с точки зрения Cell-программиста (фактически автора алгоритмов и описаний, подобных вышеприведенному), пользователя и главных действующих лиц - данных и апулетов, - совершенно неважно.
Какую выгоду мы имеем при такой организации? Во-первых, все написанные таким образом Cell-программы параллельны по самой своей сути. Мало того что мы разбиваем исполнение программы на несколько явно независящих друг от друга стадий, которые можно исполнять «в параллель». У нас же целая цепочка ячеек-данных, требующих обработки и в подавляющем большинстве случаев все эти ячейки друг от друга совершенно независимы - а значит, мы можем «превращать» по одному и тому же алгоритму несколько ячеек одновременно. Таким образом, в Cell удается загрузить работой не просто десятки - а сотни и даже тысячи «элементарных процессоров» (Synergetic Processing Element, SPE), причем задействовать для запущенной на одном процессоре задачи SPE всех процессоров данного устройства и даже совершенно прозрачным образом привлечь к ней же SPE других устройств! Представьте, что игровая приставка, домашний компьютер, телевизор, холодильник и КПК совместно работают над, скажем, запущенной пользователем задачей рендеринга трехмерной сцены, причем делают это совершенно прозрачным и незаметным для вас способом - и вы поймете всю прелесть подобной организации! А самое замечательное, что вся эта красота не стоила ни малейших усилий. Нам не требовалось размышлять над кластеризацией, пересылкой данных, блокировками, потоками и прочими «прелестями» параллельного программирования, превращающего жизнь программиста в кошмар: мы написали только «интересную» и «содержательную» часть кода, собственно «алгоритмику» задачи, переложив всю рутину на автоматику и, возможно, прозрачным образом задействовав для решения своих задач произвольное количество чужого кода[Скажем, если в трансляции видеопоток сжат нашим «фирменным» кодеком, а звук - обычным стандартным, то потребуется обеспечить лишь «свою» часть по видеодекодированию, а все остальное - декодирование звука, набор «улучшалок» для картинки и т. п. - Cell-устройство возьмет стандартное или ранее загруженное пользователем.].
