Компьютерра, 2005 № 41 (613) - [17]
Но все же - что дает разрядность? Если процессор поддерживает длинные физические адреса (в архитектуре x86 соответствующий режим называется Physical Address Extension, PAE[Если подробнее, то в PAE используется 52-битная адресация, позволяющая адресовать до четырех петабайт данных]), то мы можем поставить на сервер хоть 64 Гбайт оперативной памяти и выделять ее разным приложениям. Условия вроде «не более двух гигов для чипсета такого-то» - это ограничения именно чипсета, не умеющего обслуживать большой объем памяти, а не 32-разрядной системы. Поэтому в серверных приложениях, когда на одном сервере, как правило, запущено несколько десятков одновременно работающих приложений, пресловутый «барьер в 4 Гбайт» практически не ощущается. Но означает ли это, что сегодня 64-разрядный x86 никому не нужен?
Конечно, нет! 64-разрядность виртуальной памяти в приложениях востребована уже сейчас, просто эти «добавочные биты» используются другими способами.
Во-первых, какую-то часть виртуального адресного пространства может забирать операционная система. К примеру, MS Windows обычно использует для своих нужд старший бит виртуального адреса, ограничивая адресное пространство запущенного в ней приложения 31 битом и 2 Гбайт адресного пространства. А два гигабайта оперативной памяти, согласитесь, куда ближе к реальной жизни, нежели гипотетические четыре; и ситуацию, когда их начнет не хватать, представить гораздо проще. Можно, правда, попытаться использовать специальный режим, когда Windows будет предоставлять процессам не два, а три гига адресного пространства, но работает он, к сожалению, далеко не всегда, зачастую роняя при неправильной настройке операционную систему.
Во-вторых, линейное адресное пространство подвержено «засорению» - процессу, в ходе которого в нем образуются дырки, которые невозможно использовать. Программы часто оперируют не байтами и словами, а гораздо более крупными структурами, занимающими десятки, сотни и даже миллионы байт информации. Если мы использовали эту структуру, а затем необходимость в ней отпала, то в памяти остается дыра, совпадающая по размерам и расположению с местом, где лежали данные этой структуры. И удастся ли сию дыру использовать - еще бабушка надвое сказала. Иногда почти вся оперативная память состоит из дырок, не несущих никакой практической пользы, и места для записи даже небольшого объема данных не находится[Подобным особенно грешат операционные системы и среды разработки компании Microsoft: менеджер памяти, используемый в Windows, не столь эффективен, как его UNIX-собратья, и «мусора» в памяти оставляет гораздо больше. Иногда это приводит к тому, что нормально работающие на UNIX программы, использующие вдобавок сравнительно небольшой объем оперативной памяти, в MS Windows через некоторое время вылетают с ошибкой Out of memory].
В-третьих, существует такая интересная техника, как маппинг файлов на оперативную память. «Маппить» можно что угодно, причем это не только самый быстрый, но и один из самых удобных способов обработки файлов. Не нужно ничего читать из файла или записывать в него, не нужно думать об эффективном кэшировании данных - все происходит автоматически. Просто «мапнул» файл на память - и находившиеся в нем данные волшебным образом мгновенно оказались доступными приложению. В «настоящую» оперативную память они будут подгружаться только при обращении к ним, а в случае длительной «невостребованности» - вновь возвращаться на жесткий диск, освобождая место для чего-нибудь более актуального. Реализовать что-либо подобное «вручную» - практически невозможно. Но, к сожалению, на двух гигабайтах адресного пространства Windows особенно не развернешься[И на 4 Гбайт своп-файла, которыми нас обычно ограничивает Windows (ругать так ругать!), - зачастую тоже], поэтому техника маппинга задействуется только тогда, когда высокая скорость обработки файлов для приложения становится критичной.
Поэтому даже если бы в технологиях EM64T/AMD64 не было бы ничего сверх возможности оперировать с 64-битными указателями[Указатель на оперативную память (обычно просто говорят: указатель) - это ячейка памяти, в которой записывается номер другой ячейки. То есть, к примеру, мы можем как-то использовать в программе это число (номер ячейки) - присваивать его, изменять, увеличивать или уменьшать, а потом вызвать специальную операцию «разыменования» - взятия данных, расположенных по этому адресу в оперативной памяти. В C/C++ и подобных языках программирования указатели выделены в самостоятельный тип данных, и программист работает с ними «вручную»; в других языках «арифметику» указателей от программиста прячут, предлагая работать с более высокоуровневыми абстракциями, однако в машинном коде и оперативной памяти указатели встречаются почти всегда] на оперативную память, они по-прежнему оставались бы востребованными и своего покупателя все равно бы нашли. Но стоила бы в этом случае овчинка выделки?
Увы, нет. По крайней мере в ближайшие года три. Изменения регистров общего назначения и системы адресации памяти - совсем не то, что добавление новых регистров и новых инструкций для работы с ними. Расширения никак не влияют на работу старых программ, которые об их существовании и не догадываются; а вот пройти мимо изменений использующихся на каждом шагу регистров общего назначения - даже в уже существующих приложениях - невозможно. Очень часто приложения явным или неявным образом апеллируют к тому, что данные, которые они используют, имеют ту или иную длину и неожиданный сюрприз в виде занимающего не 4, а 8 байт указателя на оперативную память для них почти всегда фатален. Даже если программа не занимается «явным приведением типов», превращая их в 32-битные целые числа и обратно (это из сугубо программистских заморочек), то почти наверняка хоть где-нибудь она работает со структурой данных, в которую одним из компонентов входит тот самый указатель, и где для него отведено строго четыре байта, зажатых слева и справа данными той же или других структур. Так что подавляющее большинство существующих 32-битных программ в 64-битном режиме выполняться не будут.
