Не так давно - каких то лет десять назад, на наших глазах произошла "микро" революция: мы перешли с 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-бит процессоров.

Стр.2 - Intel 64

Стр.3 - AMD 64

Стр.4 - IBM, Sun, и Compaq