Явные недостатки x86-64
Увы, нет. По крайней мере в ближайшие года три. Изменения регистров общего назначения и системы адресации памяти - совсем не то, что добавление новых регистров и новых инструкций для работы с ними. Расширения никак не влияют на работу старых программ, которые об их существовании и не догадываются; а вот пройти мимо изменений использующихся на каждом шагу регистров общего назначения - даже в уже существующих приложениях - невозможно. Очень часто приложения явным или неявным образом апеллируют к тому, что данные, которые они используют, имеют ту или иную длину и неожиданный сюрприз в виде занимающего не 4, а 8 байт указателя на оперативную память для них почти всегда фатален. Даже если программа не занимается «явным приведением типов», превращая их в 32-битные целые числа и обратно (это из сугубо программистских заморочек), то почти наверняка хоть где-нибудь она работает со структурой данных, в которую одним из компонентов входит тот самый указатель, и где для него отведено строго четыре байта, зажатых слева и справа данными той же или других структур. Так что подавляющее большинство существующих 32-битных программ в 64-битном режиме выполняться не будут.
Это не такая уж катастрофа, как может показаться: современные процессоры умеют быстро переключаться между 32- и 64-битным режимами, однако как минимум одно приложение, работающее на 64-битном компьютере, эти «нововведения» все-таки должно поддерживать. Ибо если даже операционная система, заведующая менеджментом виртуального адресного пространства, будет работать в 32-битном режиме, то ради чего мы боролись? Поэтому сформулируем «принцип номер один» для 64-битных систем: для поддержки 64-битности операционная система тоже должна быть 64-битной. Правда, объем переделок, которые для этого требуются, велик, но не бесконечен - релизы UNIX-систем с поддержкой AMD64 появились всего лишь несколькими месяцами позже представления новых систем, так что если бы этим дело и ограничилось, то особых поводов для беспокойства не возникло. Но, к сожалению, драйверы для операционных систем - это часть ОС, и, волей-неволей, они тоже должны быть 64-битными. А поскольку драйверы пишут тысячи и десятки тысяч «сторонних разработчиков», которым отнюдь не улыбается одновременно поддерживать 32- и 64-битные версии, не говоря о том, чтобы создавать драйвер для «железки», выпуск которой уже два года как прекращен, то это уже очень серьезная проблема, не решенная до сих пор[Сообществу OpenSource проще: там почти ко всем драйверам идут исходники, и зачастую достаточно простой перекомпиляции исходников, чтобы получить из 32-битной версии 64-битную или наоборот. Юниксоиды вообще стараются по возможности создавать переносимый код, который можно использовать с минимумом изменений на разных платформах; но даже если перекомпиляции недостаточно, то «модификация» этих исходников с исправлением тонких мест, вызывающих проблемы с 64-битностью, в принципе доступна любому мало-мальски грамотному программисту. Поэтому с «опенсорсными» 64-битными драйверами особых проблем сейчас нет. А вот с «фирменными» (вроде поддерживающего в Linux аппаратное ускорение OpenGL-драйвера для видеокарт nVidia) есть, хотя вендоры и стараются оперативно их решать].
Второе «слабое место» 64-битных процессоров в том, что обработка 64-битных данных заведомо требует больше времени, чем обработка 32-битных, и, что еще важнее, 64-битные программы и данные к ним занимают в оперативной памяти гораздо больше места. А поскольку оперативная память - ресурс медленный и дефицитный (кэш-память, особенно кэши первого уровня, имеет конечные размеры), то вместе с возросшей вычислительной сложностью это приводит к сильному падению «чистой» производительности процессора в 64-битных режимах. А что вы хотели, за все нужно платить, и в классическом варианте за поддержку большого объема памяти, устранение «проблемы мусора» и упрощение процедуры маппинга файлов на память приходится расплачиваться сравнительно невысоким быстродействием процессора, подсистемы оперативной памяти и несовместимостью с ранее написанными драйверами. Разумеется, в перспективе мы никуда от этого не уйдем, но сегодня потенциальные недостатки 64-битности для обычного пользователя перевешивают ее потенциальные достоинства.
Но кто сказал, что x86-64 - это только 64-битные указатели, команды и регистры GPR?..
IA-32 versus x86-64
Переделывая почти весь процессор и весь набор поддерживаемых им инструкций, мы все равно получаем несовместимость в 64-битном режиме со старыми программами. Так почему бы заодно не исправить ошибки предшественников и не убрать из x86 устаревшие ограничения? 64-битный режим не просто улучшенная версия IA-32 ISA, фактически это следующая версия архитектуры x86, во многом лишенная «родовых травм» этого семейства, начинавшегося с микроконтроллеров и долгое время не претендовавшего на «серьезное» использование.
Первое и, пожалуй, главное преимущество, которое получила архитектура x86-64, - долгожданная поддержка шестнадцати регистров общего назначения и шестнадцати регистров XMM. На первый взгляд это чисто количественное изменение, но на самом деле - принципиальная во всех отношениях доработка архитектуры IA-32. Судите сами: у современного IA-32 восемь регистров общего назначения (EAX, EBX, ECX, EDX, EDI, ESI, EBP и ESP), восемь 64-битных регистров MMX (MMX0-MMX7) и восемь же регистров SSE (XMM0-XMM7). Не замечаете ничего странного? Откуда вообще взялась цифра восемь? Для ответа на этот вопрос нам потребуется обратиться к «основам основ» - к формату x86-инструкций.
Каждая инструкция представляет собой длинную комбинацию из пяти составляющих: а) опкода (operation code, opcode), описывающего, что нужно сделать с данными, б) поля ModR/M, в котором записывается «подвид» инструкции, режим адресации памяти (как и у всякого CISC-процессорa, этих подвидов у x86 много) и один или два регистра, используемых инструкцией, в) поля SIB (Scale-Index-Base), в котором при некоторых режимах адресации памяти записываются еще два регистра (база и индекс) и масштаб, г) полей Displacement и Immediate, в них записываются используемые инструкцией константы, д) набора «приставок» (prefixes), позволяющих задать «нестандартные» режимы использования инструкции. Обязательным является только поле опкода, все остальные опциональны и могут отсутствовать[Теперь понимаете, что имелось в виду под «непомерной сложностью декодирования CISC-инструкций»?].
Оставим в стороне вопрос о том, для чего нужна столь сложная конструкция и как она работает, и сосредоточимся на одном-единственном интересующем нас аспекте: как в x86 кодируются используемые инструкциями операнды. Смотрите: поля Reg/Opcode[В принципе здесь может быть записан не регистр, а (для некоторых инструкций) дополнительный опкод, указывающий на ту или иную разновидность одной и той же инструкции] и R/M[Здесь тоже не всегда записывается регистр - иногда это поле используют для кодирования одной из 24 разновидностей режимов адресации памяти. В x86 много подобных «тонкостей»] занимают по три бита, поля Index и Base в SIB - тоже трехбитные. А трехбитных комбинаций, как легко посчитать, всего восемь, именно столько регистров может быть одновременно доступно любой программе. Так было задумано еще три десятка лет назад, при проектировании Intel 8086, и с тех пор ничего не изменилось, хотя Pentium 4 отличается от 8086, как небо от земли. Восемь регистров современных Athlon и Pentium не блажь разработчиков и не техническая необходимость, а фундаментальное ограничение самого набора инструкций x86.
Что же делать, если нам хочется как-то обойти это ограничение, не теряя совместимости со старыми приложениями? К счастью, инженеры, проектировавшие x86 ISA, были очень талантливыми и прозорливыми, а потому заложили в архитектуру возможность вводить перед инструкциями приставки - специальные указатели, так или иначе изменяющие значения инструкций. Скажем, приставка LOCK говорит, что инструкция должна быть выполнена в «атомном» режиме["Атомный" режим - это когда выполнение инструкции гарантированно не будет прервано каким-нибудь внешним событием. К примеру, если мы что-нибудь записываем в оперативную память, то начиная с момента исполнения и до завершения атомной инструкции никто «посторонний» не сможет ни записать в то же место оперативной памяти, ни прочитать оттуда. Используется в многопроцессорных системах для организации межпроцессорного взаимодействия], приставки 2E и 2F подсказывают процессору, произойдет условный переход или нет, а приставка 66 приказывает переключаться между 16-битным и 32-битным представлением данных в регистрах. Поэтому когда разработчикам x86-64 понадобилось добавить в архитектуру IA-32 поддержку 64-битности, они сделали очень простую и в то же время гениальную вещь, введя набор 64-битных приставок REX, которые не столько расширяют возможности инструкций, сколько служат для кодирования дополнительной информации в четырех своих полях. Поле REX.W задает «размер» обрабатываемых данных: если здесь записан нолик, то обрабатываемые регистры интерпретируются как 32-битные, если единичка - то как 64-битные; а поля REX.R, REX.X и REX.B - старшие биты, дополняющие трехбитные поля ModR/M.Reg, SIB.Index и, в зависимости от ситуации, ModR/M.R/M или SIB.Base соответственно. Знаю, что это звучит не слишком понятно, поэтому тут же поясню, что это означает. На самом деле в 64-битном режиме мы используем 4-битную кодировку регистров процессора, но три младших регистровых бита записываем на их «традиционные» места в инструкции, а старший бит - переносим в приставку REX, обходя тем самым архитектурное ограничение. А заодно, помимо поддержки восьми новых GPR-регистров R8-R15 и SSE-регистров XMM8-XMM15, получаем возможность отключить 64-битные вычисления, когда они нам не требуются, - и пропорционально сэкономить на времени исполнения и занимаемом данными месте! И все это - одним-единственным байтом!
Вторая группа усовершенствований - отказ от поддержки безнадежно устаревших и давно не использующихся возможностей IA-32. В расширенном режиме не поддерживаются Real Mode и Virtual 8086-mode[Да-да, Virtual 8086 - это именно то, о чем вы сейчас подумали, - полная имитация процессора Intel 8086. Много ли найдется людей, которые пожалеют о его отсутствии?], и почти полностью отключена сегментация[Поскольку читатель уже заскучал от обилия технических фактов, не буду утомлять его описанием сегментированной модели памяти 80286, скажу только, что сегментация - это очень упрощенный аналог виртуальной памяти] (хотя некоторые настройки сегмента CS и сегменты FS/GS все же можно использовать); не поддерживаются инструкции, работавшие с этими сегментами, и инструкции, оперировавшие BCD-числами[BCD (Binary Coded Decimal) - это когда десятичное число записывается шестнадцатеричными цифрами. Например, 54d - в виде 54h = 01010100b вместо традиционных 36h = 00110110b]. Все это позволяет заметно облегчить процессору жизнь и в перспективе - повысить его производительность. К примеру, отказ от сегментации позволяет при обращении к оперативной памяти не вычислять линейный адрес и не проверять его допустимость в рамках сегмента, а значит, эффективность этой подсистемы при переходе к x86-64 существенно возрастет.
«А как обстоят дела с совместимостью со старыми программами?» - спросит читатель. Посмотрим: если обойтись без приставки REX, то процессор будет считать, что все записанные там данные - нули, то есть новые регистры не используются, а размер операндов инструкции равен 32 битам, то есть старшие 32 бита каждого 64-разрядного регистра при подобных вычислениях явным образом забиваются нулями. Как легко догадаться, инструкция без префикса REX даже в 64-битном режиме будет работать точно так же, как она работала и в 32-битном; и если соблюдать меры предосторожности (в частности, не выходить при адресации за границу «нижних 4 Гбайт» виртуальной памяти, то даже в 64-битном режиме все программы будут работать как и в 32-битном! Красивое решение? Мне кажется, да. Если программе не требуется поддержка всяческих «64-битностей», то она может запросто продолжать работать на «физически» 64-битном процессоре в 32-битном режиме, не используя ни 64-битные указатели, ни 64-битные вычисления, зато «радуясь» удвоенному количеству регистров и другим улучшениям x86.
К сожалению, «нет в мире счастья», и по кодировке префиксы REX совпадают с шестнадцатью «сокращенными» инструкциями семейств INC и DEC (увеличение или уменьшение содержимого регистра на единичку). Вдобавок в 64-битном режиме не поддерживается ряд инструкций и «режимов» x86 (о чем речь пойдет ниже), а для нескольких инструкций изменены опкоды или их смысловая нагрузка[К примеру, инструкция 90h в классическом x86 означает XCHG EAX, EAX (поменять местами регистр EAX с регистром EAX). Поскольку от перестановки двух одинаковых регистров их содержимое не меняется, то эту комбинацию часто используют в качестве однобайтной «пустышки» (NOP), которая ничего не выполняет, зато занимает 1 байт машинного кода. Зачастую некоторые инструкции хочется «выровнять» в оперативной памяти, сделав так, чтобы они, например, не «пересекали 16-байтные границы» (если этого не сделать, то при декодировании инструкции возникнет «штраф», связанный с тем, что процессору придется «склеивать» инструкцию из нескольких 16-байтных кусочков); и если, скажем, эта инструкция - начало цикла, то непрерывная выплата «штрафа» может существенно замедлить выполнение программы. Вставка нескольких NOP’ов, «закрывающих» возникающие из-за выравнивания «дырки» в коде, - обычная практика, однако в 64-битном режиме процессор не просто переставит EAX с EAX местами, а еще и заполнит старшие 32 бита регистра RAX нулями - и наша инструкция уже не будет «настоящим» NOP’ом. Поэтому в x86-64 опкод 90h обрабатывается по-особому, всегда интерпретируясь как NOP]; так что даже в «тепличных» 32-битных условиях перекомпиляция программ для поддержки x86-64 все-таки требуется. Но и унывать по этому поводу не приходится: получить все преимущества от расширенного набора регистров без перекомпиляции все равно невозможно, а если очень хочется запустить 32-битное приложение, это можно сделать, временно переведя процессор в «режим совместимости» (Compatibility Mode), в котором полностью имитируется классический IA-32.
Какие процессоры поддерживают x86-64?
В случае AMD - все новые CPU без исключения. Athlon 64, Mobile Athlon 64, Turion и Opteron поддерживают технологию AMD64 изначально; процессоры Sempron (изначально этой поддержки лишенные) - начиная с определенного степпинга (E) или определенной даты (осени 2005 года). Отличить «новые» Sempron от старых проще всего по логотипу на коробке: у 64-разрядных Sempron’ов на упаковке стоит значок AMD64.
В случае Intel технологию EM64T поддерживают только процессоры новых степпингов (начиная с "E") в исполнении LGA775. Pentium D, Pentium eXtreme Edition и Pentium 4 семейства 6xx поддерживают EM64T изначально; процессоры Xeon - начиная c 90-нм ядра Nocona; процессоры Pentium 4 семейства 5xx и Celeron D семейства 3xx - только те модели, номер которых заканчивается на шестерку или единичку. Pentium 4 Extreme Edition 3,73 ГГц тоже поддерживает EM64T. Все остальные модели (в частности, Pentium M и процессоры в исполнении Socket 478) технологию EM64T не поддерживают и в ближайшее время эту поддержку не получат.
To 64bit or not to 64bit?
Так стоит ли переходить на x86-64 или нет? Думаю, после всего вышеизложенного ответ понятен: без сомнения, стоит! Технология x86-64 действительно предоставляет все преимущества 64-битных систем, содержит ряд качественных улучшений по сравнению с «классической» IA-32 ISA, но главное - позволяет не использовать 64-битные вычисления там, где этого не требуется, и сохраняет полную совместимость с любым 32-битным софтом. А потому единственный серьезный довод против, который до сих пор мешает широкому распространению технологии, - это необходимость поддержки x86-64 операционной системой и использования редких и порой не до конца отлаженных и «недооптимизированных» 64-битных драйверов.
Благодарим компании AMD (за предоставление тестового набора Athlon 64 X2 4800+), MSI (за материнскую плату MSI K8N SLI) и сеть магазинов «Неоторг» (за видеокарту MSI GeForce 7800GT).
64-битный Linux
Операционные системы семейства *nix и особенно их разновидности с открытым исходным кодом никогда не испытывали затруднений с портированием на самые разные архитектуры. Unix вообще задумывалась как портируемая операционная система[Недаром же стандарт на Unix-системы называется POSIX - Portable Operation System Interface for computer environments], а множество добровольных помощников - неплохой способ сократить время отладки и тестирования новой разновидности «операционки» и драйверов для нее.
Именно это и позволило юниксоидам в полной мере использовать 64-битные x86-процессоры сразу же после того, как появились первые компиляторы, поддерживающие 64-битные инструкции x86-64. Благо что при желании собрать свой «64-битный» дистрибутив может любой человек, обладающий достаточными познаниями в программировании, организации и администрировании *nix-систем; а перекомпилировать «обычную» программу для того, чтобы она получила поддержку x86-64, в большинстве случаев может и обычный пользователь. В мире Unix-систем, в отличие от Microsoft Windows, поддержка технологии x86-64 происходит гораздо естественнее - если приложение (или драйвер) распространяется в «исходниках», то в большинстве случаев его достаточно «пересобрать» (заново откомпилировать программу); а если в «бинарниках» (в заранее откомпилированном виде) - то почти всегда этот бинарник представлен в целом ряде вариантов под разные версии *nix-систем, среди которых наверняка найдется подходящая версия под вашу конкретную операционную систему. Поскольку все вышесказанное относится и к драйверам (которые могут считаться пусть и не самостоятельными, но программами), то проблем с ними тоже, как правило, не возникает[Для некоторых устройств unix-драйверов попросту не существует - ни для 32-битных, ни для 64-битных версий операционных систем. Но эту ситуацию уже никак, естественно, не исправишь].
Мы попробовали установить один из современных дистрибутивов с поддержкой x86-64 - Linux Corporate Server 3.0 от компании Mandrake. С инсталляцией и опознанием оборудования трудностей не было (разве что аудиокодек не распознался); с компиляцией тестовых приложений - тоже. В отличие от своих Windows-собратьев, скомпилированные наиболее распространенным компилятором GCC эти приложения выиграли в производительности куда больше (до 40-50%). Дело в том, что GCC - кроссплатформный компилятор, способный генерировать машинный код для двух десятков разных процессорных архитектур, а потому код для каждой из архитектур он генерирует по более простым алгоритмам, нежели «заточенные» под IA-32 компиляторы, и потому от «подводных камней» x86 страдает больше. К примеру, в x86 рекордно мало регистров общего назначения и регистров SSE по сравнению с другими процессорами, на которые GCC рассчитан. Поэтому переход к удвоенному числу регистров общего назначения так сильно упрощает GCC работу, что он перестает «по-глупому» спотыкаться - и возникает большая «дельта» между результатами одной и той же программы в 32-битном и 64-битном режиме. Разумеется, это справедливо не для всех приложений, но для очень многих, так что если ваш процессор поддерживает технологию x86-64 и вы намерены установить на него операционную UNIX-систему - лучше заранее купите 64-битный дистрибутив.
Как пересобрать *nix-приложение для поддержки x86-64
Большинство используемых в обычной жизни вариантов Linux ориентированы на работу с бинарными пакетами, и пересобирать программы в них приходится нечасто. Если вы хотите насладиться преимуществами 64-битной архитектуры, убедитесь, что заветные цифры «64» содержатся в номере версии вашего «дистро» - большинство крупных сборщиков поставляют специальные билды для этих целей. Впрочем, использовать или не использовать «продвинутые» дистрибутивы - вопрос открытый: Linux состоит из множества пакетов, и может статься, что нужная программа не собрана под 64-битную архитектуру в вашем репозитарии. Тогда можно попробовать собрать ее из исходников самостоятельно. Скорее всего, архитектура должна определиться автоматически (например, на этапе выполнения скрипта configure или при подготовке пакета из src.rpm-файла), и все нужные опции компилятора включатся без вашего участия. В особо запущенных случаях потребуется ручная правка Makefile. Здесь надо действовать по ситуации - но чаще всего будет достаточно добавить ключ -march ‹имя-архитектуры› при запуске gcc или g++[Например, -march k8 для сборки под AMD64 (полный перечень опций можно найти в документации gcс на
Microsoft Windows XP x64-bit edition
Говоря о технологии x86-64, невозможно не упомянуть, пожалуй, главную операционную систему, с которой пользователям этой технологии придется работать, - Microsoft Windows.
Можно долго рассуждать на тему, насколько интересна и востребована сегодня технология x86-64, но раз ее так или иначе поддерживают почти все новые процессоры, то у пользователей возникает вопрос иного рода: как 64-битность использовать на практике. Впрочем, очевидно, что для начала потребуется установить на компьютер 64-битную операционную систему.
Windows XP Professional x64 edition
А поскольку для среднестатистического юзера понятия ОС и Microsoft Windows, можно сказать, равнозначны, то выбор у него не очень богатый: либо «более пользовательская» Windows XP Professional x64 edition, либо серверные разновидности Windows 2003 Server x64 edition. На самом деле выбор еще уже, поскольку, вопреки своему названию, Windows XP Professional x64 edition основывается отнюдь не на коде оригинальной Windows XP, а использует то же самое «ядро» от Windows 2003 Server. Так что какой бы вариант вы не предпочли, «достанется» вам примерно одно и то же, просто с разными настройками системы по умолчанию. «Обновлять» систему с 32 бит до 64 невозможно - в любом случае потребуется ее полная переустановка. Список доступных языков пока тоже невелик: либо английский, либо японский, либо пакет MUI с европейскими языками (в которые русский язык не включен); так что неопытному пользователю, боюсь, рекомендовать Windows x64 edition не приходится. Впрочем, еще год назад у Microsoft не было даже этого, так что даже такой скудный ассортимент - значительный шаг вперед.
Итак, все 64-битные варианты операционных систем от Microsoft основываются на ядре Windows 2003 Server и уже включают в себя первый сервис-пак к Windows 2003[Кстати, видимо, желание включить SP1 в состав x64 edition и вызвало длительную задержку с релизом Windows x64 edition], интерфейс DirectX 9.0c и медиаплейер Windows Media Player десятой версии. Единственное «видимое» отличие для пользователя этих «осей» от 2003 Server SP1 - это возможность запуска 64-битных приложений. Поддерживается как AMD64, так и EM64T, со всей сопутствующей последней технологии спецификой. В остальном чисто внешне новые операционные системы, если не считать красивых логотипов с подписями «x64 edition», ничем не отличаются от своих прародителей. Интерфейс, приемы работы в ОС, системные настройки - все остается прежним.
А вот «невидимых» программных изменений гораздо больше. К примеру, переход на 64-битную архитектуру и к 64-битным указателям должен был автоматически привести к тому, что все структуры Windows API, в которых эти указатели встречаются, разом устарели и потребовали замены. Проще говоря, переход к 64-битным вычислениям автоматически привел и к смене Windows API на новую, «64-битную» версию. Но поскольку подобного рода смена API не позволила бы запускать в новых «Окнах» 32-битные приложения (даже несмотря на поддержку такой возможности процессором), то «старый» API в ней тоже сохранили, реализовав его через специальный «переходник», конвертирующий данные из «старого» формата в новый и наоборот. Называется «переходник» WOW64 (Windows On Windows x64) и может сильно тормозить работу 32-битных приложений под 64-битной Windows. Вообще, ситуация, в которой 64-битные и 32-битные приложения вынуждены как-то налаживать взаимодействие друг с другом, уже привела к довольно забавным результатам. К примеру, в Windows x64 edition - целых два Internet Explorer’а: «новый» быстродействующий 64-битный и «старый» 32-битный, не столь проворный, зато совместимый со всевозможными 32-разрядными плагинами для Internet Explorer’а. Мелочь, конечно, но именно из таких мелочей складывается…
Общее впечатление от новой ОС
В целом оно очень хорошее. К примеру, Windows x64 «знает» практически все «железо» и содержит необходимые 64-битные драйверы к нему, так что установка ОС даже на новейшую платформу проходит быстро и с минимумом человеческого вмешательства. Все мыслимые дыры в системе безопасности «превентивно» залатаны свежайшим сервис-паком; старые программы работают без нареканий; 64-битные запускаются легко. Некоторые результаты, снятые на нашем тестовом стенде, вы можете видеть во врезках, а мы позволим себе вкратце их прокомментировать.
Пункт первый. За редчайшими исключениями 32-битные программы в Windows XP x64 edition работают нормально, но чуть медленнее, нежели в «родной» 32-битной Windows XP. Различия не столь велики, чтобы быть субъективно заметными, однако закономерность налицо. Кто в этом виноват - «режим совместимости», в котором приходится работать процессору, новое ядро Windows 2003 или «прослойка» WOW64, - непонятно, так что ситуация может варьироваться от приложения к приложению.
Пункт второй. Специально оптимизированные для 64-битности приложения, как правило, работают быстрее своих 32-битных аналогов, но существенных рывков в производительности не дают. Правда, встречаются и приятные исключения, - так, почти все пакеты трехмерного моделирования и рендеринга в 64-битном режиме ускорялись на 10-30%. А вот больших изменений в трехмерных игрушках мы не заметили: где-то 64-битная версия чуть быстрее, где-то - чуть медленнее, но прорыва в скорости здесь нет и, возможно, никогда и не будет - подобного рода игрушки «упираются» не столько в центральные процессоры, сколько в недостаточно мощные видеокарты.
Пункт третий. Работать в 64-битных операционных системах пока еще не очень комфортно. К примеру, крупнейшие разработчики программ для записи CD и DVD 64-битные версии своих продуктов еще не выпустили, а тесно взаимодействующие с оборудованием 32-битные версии в 64-битной Windows у нас нормально так и не заработали, вынуждая обратиться к встроенным средствам записи дисков. Стоит ли говорить, что многим этот вариант покажется неудобным? Вместе с уже описанной проблемой нестыковки 32-битных плагинов и ActiveX-объектов и 64-битных программ это довольно сильно смазывает впечатление от Windows x64 edition.
Четвертый и последний пункт, сопряженный с нашей практикой использования Windows x64 edition - это, конечно же, вопросы, связанные с необходимостью использования 64-битных драйверов. Здесь дела обстоят противоречиво. С одной стороны, свежеустановленная Windows XP Professional x64 edition успешно определила на нашем тестовом стенде, построенном на чипсете nForce 4 SLI, все устройства (за исключением интегрированных аудиокодека и сетевой карты) и установила к ним соответствующие драйверы. Заметим, что такие брэнды, как ASUSTeK, Gigabyte, Broadcomm обязательно комплектуют свою новую продукцию драйверами для 64-битных версий Windows, а ATI и nVidia регулярно выкладывают в Сети всё более совершенные версии 64-битных драйверов к своим чипсетам и видеокартам, ничем не уступающие по функциональности 32-битным аналогам. С другой стороны - подобным образом поступают далеко не все производители, и та же MSI, чью материнскую плату и видеоадаптер мы использовали в тестовом стенде, никаких 64-битных драйверов на штатном компакт-диске не предоставила. Для некоторых (особенно устаревших) устройств 64-битных драйверов нет вообще, и неясно, появятся ли они в обозримом будущем[Чем-то это напоминает традиционную ситуацию с драйверами в Linux]. Кого-то она устраивает, кого-то нет.
Ситуация с 64-битным софтом для Windows складывается парадоксальная: операционная система есть, драйверы для нее есть, а вот самого простого - оптимизированных для 64-битного режима программ - нет. Радует только, что наиболее критичные к производительности приложения все-таки к x86-64 адаптированы. Так что для пользователей 3DSmax, Photoshop, LightWave, Premiere надпись на коробке от процессора про поддержку 64-bit - уже не просто слова, а ощутимая помощь в работе.
Еще одна область, где Windows x86 может сразу «раскрыться», - это приложения .Net. Они, как известно, ни к одной конкретной архитектуре не привязываются, а записываются на некотором «промежуточном» языке (IL), который превращается в машинный код для конкретной архитектуры только при непосредственном исполнении программы (Just-in-Time Compilation, JIC). Уже выпущен .Net Framework 2.0, поддерживающий x86-64, так что приложения .Net выигрыш в производительности от новой архитектуры получат без всякой перекомпиляции и сразу.
Стоит ли прямо сейчас переходить на Windows x64 edition? «Массовому» пользователю - пожалуй, рановато. В большинстве случаев переход на «64-битность» либо не даст ему сколько-нибудь заметных преимуществ в быстродействии, либо выльется в непрерывный поиск 64-битных версий любимых приложений и драйверов. А вот профессионалам и системным администраторам, старающимся выжать из машин максимум возможного, - пожалуй, стоит: прибавка 20-30% производительности на любимой задаче отнюдь не помешает.
Terralab.ru: Железный поток
Беспроводная камера Canon Digital Ixus Wireless
