To 64-bit or not to 64-bit?

Mozilla останавливает разработку 64-разрядной версии Firefox для Windows. Возможно это временное решение, но пока что – так.

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

Ситуация выглядит парадоксальной. Сегодня клиентская программная среда (ограничусь Windows как наиболее распространенной платформой) представляет собой микс 32- и 64-разрядного кода. Формально в этом нет ничего страшного или плохого (раз работает), но тем не менее. Windows Server стала 64-разрядной фактически в принудительном порядке, Microsoft просто прекратила выпускать 32-разрядную и в кратчайший срок сделала то же самое с основными серверными продуктами. Необходимость 64-разрядной клиентской Windows находилась под гораздо большим вопросом, виду более широкого разнообразия аппаратного и программного обеспечения, в том числе и устаревшего, унаследованного. Проблему с большими объемами памяти вполне можно было решить, «доточив» поддержку PAE (которая появилась еще в Windows XP) и слегка «простимулировав» писателей драйверов. А с точки зрения производительности чисто консьюмерский тезис «больше = лучше» в данном контексте не выдерживает критики.

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

Едва ли не единственное бесспорное преимущество 64-разрядной среды – лучшая безопасность, которая обеспечивается рядом аппаратных функций (видимо они сложнее реализуются в 32-разрядной архитектуре) и механизмами ОС, наиболее показательным их которых является Address Space Layout Randomization (ASLR). ASLR автоматически рандомизирует адреса, по которым приложения и их компоненты загружаются в память, а также – по которым размещаются стеки, кучи и другие структуры. Тем самым усложняется их поиск (а перебор 64-разрядного адресного пространства и вовсе невозможен), а значит, и применение различных хакерских методик. В Windows ASLR присутствует со времен Vista и с каждой новой версией ОС совершенствуется, в частности, в 64-разрядной Windows 8 появился High Entropy ASLR (HEASLR), который делает разброс возможных адресов еще большим. Этот механизм доступен только для 64-разрядных приложений и задействуется ими по желанию, в частности, он применяется вкладками Metro-варианта Internet Explorer.

Но ведь безопасность – это как раз главный аргумент для браузера, который давно уже стал (на пару с Вебом) главным источником информационных угроз. Как известно, в 64-разрядной Windows 8 по умолчанию все равно используется 32-разрядный IE10 – исключительно из соображений совместимости. Для IE9, к примеру, есть и другая причина – в 64-разрядном варианте этого браузера отсутствует JIT-компилятор JavaScript, соответственно, производительность чистого интерпретатора оставляет желать лучшего. В IE10 этот недостаток устранен, как следствие, выровнялась и производительность. 32-разрядный браузер все-равно несколько быстрее, у меня получилось – на 5% в Peacekeeper и на 8% в SunSpider, но это уже приемлемо. Тем более, что первый результат, скорее всего, является следствием второго, т.е. можно предположить, что проблема в недостаточной оптимизации 64-разрядного JavaScript-движка, просто в силу его новизны.

Таким образом, не случайно 64-разрядный IE10 включается через опцию Enhanced Protected Mode – его смысл именно в лучшей безопасности, ради которой можно и пренебречь какими-то дополнительными удобствами. Microsoft даже не побоялась полностью отказаться от плагинов для Metro-браузера и не похоже, чтобы это кого-то сильно взволновало. Поэтому решение Mozilla вряд ли может порадовать. Впрочем, и остальные разработчики «альтернативных» браузеров не слишком озабочены данными вопросами. 64-разрядный Chrome существует только для Linux, для Windows работы даже не ведутся. 64-разрядный Opera имеется в «лабораторной» версии, которую не сразу и найдешь. Любопытно, что по результатам Peacekeeper он даже на 3-4% обгоняет 32-разрядный релиз (хотя, возможно, мне просто не удалось до конца подровнять настройки). То есть перспективы у 64-разрядного ПО вроде бы есть, но видятся они как-то уж очень по-разному.