64-x битные процессоры

Введение

Не так давно - каких то лет десять назад, на наших глазах произошла "микро" революция: мы перешли с 16-ти на 32-битные приложения. Большинство, надо полагать, этот процесс еще довольно хорошо помнит. И помнит, в том числе, что никакого увеличения производительности "на глаз" замечено не было. Так вот -с переходом с 32-бит на 64-бит будет то же самое.

Теперь, после столь оптимистичного вступления, попытаемся разобраться -почему ситуация складывается именно так, а не иначе. Да и вообще - может быть автор ошибается? Тем более, что, усилиями маркетологов шумиха вокруг 64-бит процессоров поднимается в последнее время все больше и больше. Что характерно -раньше такого не было, хотя 64-бит RISC чипы вышли на рынок еще в конце 90-х. Тогда это были типично серверные процессоры, причем уже широко известные узкому кругу специалистов, а сегодня в отрасль пришли многомиллионные маркетинговые бюджеты того же Intel.

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

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

Но для начала, нам придется как следует углубиться в самые-самые основы работы процессоров - это послужит той необходимой платформой, от которой будет отталкиваться весь последующий разговор. И, чуть-чуть, в историю. Которая начинается со времен Intel 4004, бывшего 4-бит процессором. Это означало, что процессорные регистры общего назначения могли хранить лишь числа такой размеренности, ALU (arithmetic logic unit), модуль, выполняющий вычисления с целыми числами, мог с ними работать, плюс, процессор мог бы использовать 4-бит числа при адресации к блокам памяти. То есть, к примеру, для инструкций, работающих с целыми числами, были доступны лишь значения от -7 до 8. Очевидно, что - маловато для любой арифметической операции.

Впрочем, уже очень скоро появился на свет 8-бит 8008 (-127 - 128), также скоро сменил его 16-бит 8086 (-32768 - 32767), а уже в 1986 году мы увидели 80386 процессор, впервые реализовавший 32-бит режим работы, что дало возможность работы с числами размерностью свыше двух миллиардов. Кстати, а о какой работе вообще идет речь, как оперирует числами процессор?

Как оперирует числами процессор?

Есть ALU (в последних процессорах - уже несколько), в который поступают все инструкции и данные, необходимые для целочисленных вычислений, как правило, это один из самых быстрых в плане тактовой частоты модулей процессора. Грубо говоря, процесс его работы можно представить следующим образом: поступили данные (две цифры - 3 и 4), поступила инструкция (операция умножения). На выходе получили результат - 12. Сложение, вычитание, деление, и так далее - в общем, все, с чем мы имеем дело в повседневной жизни.

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

Возникает вопрос, при чем тут регистры? Как уже говорилось - прежде, чем данные попадут в ALU, они должны быть туда загружены. Загружены из некоего источника. Под которым можно подразумевать все угодно - от винчестера, до кэша процессора. Из кэша данные попадают непосредственно в процессор, в блок хранения данных. Небольшой по объему, но скоростной. Однако, в силу ряда чисто физических ограничений, расположить его вплотную к ALU не получится - роль посредника выполняет набор совсем уж небольших блоков для хранения данных, работающих на очень большой скорости, и называющихся регистрами.

Как раз оттуда ALU данные, с которыми он работает, и получает, и звучит для него вышеупомянутая операция скорее не как "3 * 4", а как "содержимое регистра A * содержимое регистра B". И, разумеется, сохранить результат в один из регистров (может быть, даже один из использовавшихся в операции), откуда он потом, при необходимости, сможет быть взять для еще одной операции, или же записан в оперативную память, освободив драгоценное место. Когда мы говорим о разрядности процессора, то, практически в первую очередь, мы говорим как раз о разрядности этих регистров - могут ли они хранить 8, 16, 32, или 64-бит числа.

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

С числами с плавающей запятой работает отдельный набор инструкций, x87, с ними оперируют отдельные вычислительные блоки, сведенные в модуль с общим названием "сопроцессор", а хранятся они и оперирует с ними процессор во внутреннем формате с 80-бит представлением. Так что здесь пока что все нормально, и ради чисел с плавающей запятой весь сыр-бор затевать явно не требовалось. Тем более, что это направление развивается совершенно автономным образом - SSE, 3DNow, и так далее, так что переход x86 с 32-бит на 64 его затрагивает весьма слабо.

Существует, впрочем, и еще один аспект вопроса, а именно - доступ к памяти. Дело в том, что в базовом режиме, так называемом "flat addressing", те же самые регистры общего назначения используются для хранения адресов доступа к памяти. 32 бита дают нам 4.3 миллиарда возможных комбинаций, так что 32-бит процессор может, таким образом, осилить объем памяти лишь объемом в 4.3 Гбайт. Адреса ячеек, имеющих более старшие номера, он попросту не может хранить в своих регистрах.

Очевидно, что здесь польза от 64 бит проявляется наиболее очевидно, поскольку объем адресуемого пространства сразу увеличивается до 18 миллионов терабайт. И 4 Гбайт то памяти в настоящее время можно встретить лишь в серверах, хотя через несколько лет, очевидно, до таких объемов доберутся и PC, но новые возможности: Их, очевидно, хватит на ближайшие несколько десятков лет, по крайней мере, если иметь дело с теоретической стороной вопроса - на практике дела обстоят отнюдь не столь радужно.

Так вот, раз уж мы заговорили о серверах, то впору вообще задаться вопросом - что толку вообще в переходе на 64-бит? Кто выиграет от этого? В первую очередь в голову, разумеется, приходят пресловутые серверы баз данных. Где серьезные базы давно уже переросли объем в 4 Гбайт, а возможность кэшировать их полностью в оперативной памяти слишком заманчива в плане производительности, чтобы от нее отказываться. Так что, между прочим, как и с сопроцессором, производители серверных решений не стали дожидаться, пока как-то решит проблему - за счет использования различных подходов, 32-бит Xeon позволяет адресовать более 4 Гбайт данных (до 64 Гбйт), хотя, конечно подобные полухакерские решения трудно назвать серьезной платформой под будущее, да и падение производительности при операциях с памятью при этом измеряется в десятках процентов. Впрочем, будущее от Intel - это Itanium, а не Xeon.

Зачем необходим 64-х битный процессор?

Даже на рабочих станциях пока что трудно представить себе необходимость объемов памяти выше 4 Гбайт, хотя, конечно, очевидно, что совершенствование приложений, работающих с 2D и 3D графикой, а также с видео, уже в течение ближайших лет позволят перешагнуть этот барьер. Тем не менее, сегодня здесь пользы от 64-бит - ни малейшей.

Про Word, игры, и так далее - в этом контексте рассуждать вообще просто смешно, хотя, с другой стороны, по мере увеличения реалистичности отображаемого в играх мира легко себе представить необходимость в подобных объемах памяти. Достаточно представить себе все сервера, поддерживающие Ultima Online или Everquest, сконцентрированные в обычный будущий игровой PC среднего уровня.

Однако, кто-то, возможно, уже мог заметить изьян в этих рассуждениях - они ведутся так, как будто 64-бит адресация к памяти является единственным достоинством 64-бит процессоров. Неужели, от представления целых чисел в 64-бит формате для вычислений ничего не меняется? Кое-что меняется, конечно, но, во многом, для тех же серверов: симуляция ядерных взрывов, погоды, криптография, и прочие подобные приложения, где действительно может возникнуть ситуация, когда 32-бит диапазона целых чисел может не хватить. Реальный мир обычных PC - фактически, исключено. Кстати, если уж сейчас кому-то такое и нужно, то языки высокого уровня, вроде того же C, позволяют использовать стандартный фокус, когда для представления 64-бит числа используются два 32-бит регистра. Что, естественно, поскольку количество регистров весьма ограничено, несколько негативно сказывается на производительности.

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

Впрочем, уточнение "для той же архитектуры" было сделано отнюдь не зря, поскольку, если уж мы отталкиваемся от x86, то это будет справедливо только для Athlon 64 и Opteron от AMD. Все остальные игроки пошли по совсем другому направлению, разрабатывая под 64-бит совершенно отличные архитектуры. Возьмем тот же Intel, который и положил, собственно, начало шумихе по поводу 64-бит процессоров.

Intel 64

Компания предпочла, если можно так выразиться, совершить бархатную революцию, оставив на некоторое время развиваться свою линейку 32-бит процессоров, и, параллельно, начав выводить на рынок 64-бит семейство. Шаг, сделанный Intel впервые: переход с 16 на 32 бит был сделан абсолютно дискретно - i386 полностью заменил собой i286, волевым решением, если можно так выразиться.

Процессор разрабатывался с нуля, причем, параллельно сразу в двух версиях: инженерами Intel и Hewlett-Packard. Впрочем, в основе обоих чипов лежали, естественно, одни и те же идеи, поскольку создавались они все же совместно, и должны были оба стать родоначальниками одного и того же семейства. Цементирующим составом были, естественно, единая идеология, пришедшая на смену CISC - EPIC (Explicitly Parallel Instruction Computing), и новая архитектура - IA-64, включающая в себя набор инструкций, описание регистров, и прочие подобные вещи. Впрочем, архитектура как раз - вещь изменчивая, достаточно вспомнить как отличаются между собой такие CISC процессоры, как 8086 и i486, оба созданные на базе x86.

Точно так же и с Merced и McKinley, Itanium и Itanium 2 - оба построены на базе одной идеологии, но разных разновидностях архитектуры. В свое время та же история, в общем то, была и с Pentium и Pentium Pro. Впрочем, общие черты были и у тех, есть и у этих, за это "отвечает" EPIC. В первую очередь речь идет о полноценной масштабной суперскалярности, то есть, способности выполнять одновременно несколько инструкций. Для чего, естественно, процессор содержит исполнительных модулей - для операций с целыми числами, с числами с плавающей запятой, и т.д.

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

Кардинально решен вопрос с регистрами, количество которых увеличено в несколько раз: у Itanium их количество составляет 128 общего назначения, 128 - для хранения чисел с плавающей запятой, 8 регистров переходов, и 64, отвечающих за работу механизмов предсказания. Здесь все очевидно - такого количества регистров, да еще реально 64-битных, хватит для хранения любых требуемых чисел для любого разумного количество исполнительных модулей. Каковых у Itanium, первого представителя семейства, всего пять - два целочисленных, два для операций с памятью, (итого - 4 ALU инструкции за такт), и четыре - для операций с плавающей точкой. Физическая память адресуется 44-бит числами, что на самом деле ограничивает ее объем "всего лишь" 17.6 Терабайт, блоки для операций с плавающей точкой работают с числами в 82-бит представлении.

От идеи реализовать 32-бит x86 ядро в аппаратном виде Intel отказался, сочтя это слишком неэффективным использованием площади кристалла, так что для того, чтобы получить возможность исполнения Itanium старого доброго х86 кода, пришлось создать систему трансляции, которая на лету преобразует x86 код в IA-64. Очевидно, что при прочих равных, производительность подобного решения будет ниже, чем чистого x86, работающего на той же частоте. Впрочем, никто и не ждет от Itanium скоростного исполнения x86 программ - поддержка этой архитектуры относится скорее к издержкам переходного периода. Тем не менее, факт остается фактом: это семейство для решения 32-бит задач не приспособлено. Впрочем, вряд ли кто-то будет покупать Itanium для подобных целей.

Вдобавок, сам по себе Itanium был в значительной степени пилотным проектом, как и Pentium Pro, так что процессор вообще стоит рассматривать больше как демонстрацию возможностей архитектуры, чем реальный коммерческий продукт. Характерный штрих - чипсет для Itanium, 460GX, поддерживает в качестве памяти всего лишь PC100 SDRAM, это кое-что говорит о скорости, с которой способен переваривать данные процессор. С другой стороны, однако, в какой-то мере не слишком быстрый интерфейс с оперативной памятью компенсируется очень большим кэшем - 2 или 4 Мбайт L3, работающими на полной частоте процессора (733 или 800 МГц), с пропускной способностью до 12.8 Гбайт/с.

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

Itanium 2 является уже куда более коммерчески интересным продуктом. Созданный командой инженеров Hewlett-Packard, набившей руку на создании 64-бит процессоров серии PA-RISC, чип получился куда более совершенным. С несколько меньшим количеством кэша L3 (1.5 или 3 Мбайт), и несколько более высокой частотой, 900 МГц или 1 ГГц, он обеспечивает в полтора-два раза большую производительность на тех же задачах, что и Itanium. И является, фактически, первым коммерческим представителем архитектуры IA-64. Дальше планы у Intel уже расписаны совершенно четко, и в ближайшие несколько лет особых революций не предвидится - только за счет совершенствования техпроцесса.

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

Технология же Yamhill, полумифический ответ Intel на AMD x86-64, то есть, 64-бит надстройка для 32-бит процессоров, несмотря на все слухи, так и остается чем-то неопределенным. Можно не сомневаться, что подобные наработки у Intel действительно имеются, но линейка Pentium 4 - Xeon - Itanium на сегодняшний день настолько плотно закрывает все возможные спектры применений, что добавлять телеге пятое колесо просто-напросто нет никакой необходимости.

AMD 64

У AMD же подход полностью противоположный. Компания считает, что сейчас не время и не место для революций, а плавность эволюционного развития x86 со времен 8086 до Pentium 4 и Athlon XP, не должна прерываться. Исходя из этой идеи и формулировалась сама идеология создания процессора AMD следующего поколения - K8. Необходимость 64-битности уже тогда прослеживалась абсолютно явно, да и Intel уже во всеуслышание заявил о разработке IA-64, так что вопрос - быть 64-бит или не быть, на повестке дня для компании просто не стоял.

Однако, запас мощности, объем ресурсов, выражающихся как в финансовом выражении, так и в прочих, например, во влиянии - доле рынка, у AMD и Intel просто несравним, так что последовать по пути своего конкурента и предложить Intel абсолютно новую идеологию компания попросту не могла. Не поняли бы и не пошли бы. Оставалось сделать то, что у AMD обычно получалось лучше всего: взять старый добрый x86, и сделать его лучше, чем у Intel. Так и родилась на свет архитектура x86-64.

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

Впрочем, опять же, никто здесь не является гениальным провидцем, и разработчиком микропроцессоров эти вещи известны давным-давно. Так же, как и некоторые из путей их решения. Скажем, у того же Pentium 4 действительно 8 32-бит регистров общего назначения. Те, что видит исполняемый код. За их же фоном в глубинах процессора скрываются еще 120 (!), которыми тот может жонглировать как угодно, в нужный момент представляя любой из них под видом одного из базовой восьмерки. Путь интересный, но неочевидный. Для того же компилятора. На который, впрочем, как мы помним, Pentium 4 совершенно и не полагается.

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

Дальше все зависит лишь от того режима, в котором работает процессор. Есть режим обратной совместимости, где K8 работает как обычный 32-бит процессор, не используя ничего из своих новых возможностей, кроме тех, что относятся к простому увеличению производительности процессора. Есть так называемый "long mode", который, в свою очередь, состоит из двух подрежимов: "64-bit mode" и "compatibility mode". Обязательно требуется наличие 64-бит OS, способной, впрочем, исполнять оба вида кода, как 64-бит, так и обычный x86. Естественно, что в последнем случае программа не будет иметь доступа к памяти выше 4 Гбайт, полному объему регистров, дополнительным регистрам, и т.д. В общем, в свое время Windows 95 примерно так же относилась к 16-бит и 32-бит программам.

Впрочем, по умолчанию регистры установлены в 32-бит режим, поскольку даже 64-бит программа не пользуется только 64-бит числами. Скорее, она даже не столько пользуется ими, сколько старыми добрыми 32-бит. Выделять под их хранение 64-бит регистры - напрасная трата ресурсов, так что по умолчанию - 32-бит. Если же программе потребовалась именно операция с 64-бит регистрами, она должна использовать специальный префикс при обращении к ним, длиной в один байт. Это довольно много, учитывая, что таких обращений в программе может быть достаточно много. Впрочем, AMD полагает, что вряд ли увеличение объема одного и того же кода при переходе с x86 на x86-64 составит более десяти процентов.

Зато, с другой стороны, 32-бит программы во всех режимах обратной совместимости будут чувствовать себя просто как дома - они попросту не заметят, что исполняются на 64-бит процессоре, пользуясь всеми благами новых технологий, вроде встроенного в процессор северный моста чипсета, и т.д. А учитывая, что, как уже говорилось, 32-бит для подавляющего большинства всех необходимых программ для PC, рабочих станций, и Low-End серверов ближайшие несколько лет хватит, то здесь у Athlon 64 и Opteron перед Itanium несомненное преимущество - они не предлагают ненужных для этого рынка вещей за лишние деньги. Понадобятся 64-бит - всегда пожалуйста, нет - значит будем исполнять 32-бит в родном режиме, не занимаясь медленной эмуляцией.

Весь вопрос в том и заключается - есть ли вообще надобность в подобных процессора: умеющих исполнять стандартный 32-бит код, но, в случае необходимости, пользоваться и преимуществами 64-бит вычислений и доступа к памяти выше 4 Гбайт: Некоторые уверены, что да, вроде создателя Unreal, Tim Sweeny. По его мнению, подобная платформа обеспечит возможность создания дешевых рабочих станций, с соотношением цена/производительность в разы большей, чем у систем на том же Itanium. К выходу Athlon 64 Epic собирается выпустить 64-бит версию Unreal, и вообще полон оптимизма по поводу перспектив подобного подхода.

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

Первый представитель ядра K8 уже вышел - это Opteron, серверный процессор для одно-, двух-, и четырехпроцессорных конфигураций, с перспективой выхода на 8-процессорные платформы. С его облегченным вариантом, Athlon 64, к сожалению, пока полной ясности нет - процессор уже неоднократно откладывался, и сейчас ожидается где-то ближе к 2004 году. Виной тому технологические проблемы, или же уже упоминавшееся отсутствие 64-бит приложений для PC (включая операционную систему - Windows-64, поскольку Unix - это не OS для PC)? Скорее все же второе, и теперь AMD вынуждена ждать, пока Microsoft придет ей на помощь. Остается лишь надеяться, что это произойдет не слишком поздно.

Впрочем, есть 64-бит процессоры, у которых вопрос поддержки на уровне ОС и софта просто-напросто не стоит. Это, естественно, ветераны серверных платформ - RISC процессоры IBM, Sun, и Compaq.

IBM, Sun, и Compaq

Линейки IBM PowerPC, в своих серверных воплощениях известные, как Power4/Power4+, являются на сегодняшний день, пожалуй, наиболее реальными соперниками Itanium 2. В свое время это были первые 0.13 мкм 64-бит процессоры на рынке, с тех пор IBM неустанно работала над их техническими параметрами, и вот, сегодня мы имеем то, что имеем: относительно недорогой процессор с двумя физическими ядрами, 1.4-1.5 Мбайт кэша L2, и встроенным северным мостом. Процессор исповедует достаточно экзотический подход, комбинируя до пяти инструкций в группу, затем обращаясь с ней как с единым неделимым целым. С одной стороны - упрощает работу, с другой стороны - если что-то произошло, то придется делать откат на уровне всей группы. Да и на возможности параллельного исполнения такое ограничение сказывается не самым лучшим способом, лишая гибкости.

Нельзя не отметить еще одного из последних представителей семейства PowerPC - 64-бит PowerPC 970, нацеленный на совершенно другой сегмент. Это процессор для компьютеров класса PowerMac, представляющий из себя урезанный вариант Power4, дополненный к тому же SIMD набором инструкций Altivec от Motorola. Почти идеальный вариант для замены PowerPC G4 и G4+, к тому же, очень экономичный. И с потенциалом роста тактовой частоты выше 2 ГГц.

Sun в последнее время страдает от беспрестанных ударов со всех сторон, со все сокращающейся рыночной долей на рынке серверов и, соответственно, серверных процессоров. Компания слишком затянула с процессом развития своих продуктовых линеек, и ее сегодняшний UltraSPARC III по производительности выглядит довольно бледно относительно конкурентов. Хуже того, UltraSPARC IV, фактически, является всего лишь его его 0.13 мкм вариантом. Чего-то действительно нового можно ждать лишь от UltraSPARC V, но до этого процессора надо еще дожить - раньше 2005 года его ждать никак не приходится.

Alpha? Здесь, по большей части, ситуация очевидна - отдаленного будущего у архитектуры нет. HP сделала долгосрочную ставку на Itanium, Samsung в последнее время также не проявляет особой активности в этой сфере. Тем не менее, запас хода и инерция архитектуры весьма велики, так что, даже будучи практически лишенной поддержки, она все еще продолжает развиваться. Маленькая, но мощная 1.25 ГГц EV68, оказалась вполне способна потягаться с куда более серьезным на вид Power4, а ее дальнейшее воплощение, EV7, в силу заложенных в него технических решений, является, пожалуй, наиболее мощным на сегодняшний день средством для многопроцессорных комплексов. Вдобавок, в течение года HP собирается выпустить на рынок 0.13 мкм версию EV7 - EV79, с куда большим кэшем L2 и поддержкой более скоростной PC1066 RDRAM.

Вопрос здесь, однако, заключается не столько в чисто технических возможностях процессоров, сколько в тех силах, что за ними стоят - насколько те в состоянии обеспечить мощную поддержку. Как в этом плане, так и все же с точки зрения чисто технологического потенциала, на победу со временем в верхнем эшелоне просто обречены Itanium и Power4+. Судьба же Athlon 64 и Opteron выглядит не совсем ясной - все зависит от того, насколько они смогут использовать свой 64-бит потенциал, для чего им потребуются 64-бит операционные системы и приложения для массовых пользователей. С чем, по крайней мере, на данный момент, дела обстоят не очень. Впрочем, это не удивляет - переход с 16-бит на 32-бит Microsoft совершала почти десяток лет.

Дополнительные материалы: