Большинство компьютеров сегодня поставляются с 64-битной версией Windows и часто с минимальным объемом оперативной памяти. Это ставит под вопрос эффективность этих систем. Это особенно актуально, когда пользователи хотят запускать свои устаревшие 32-разрядные программы на этих новых компьютерах.
Читатель спрашивает:
Правда ли, что для запуска 32-разрядных приложений в 64-разрядной системе Windows требуется в 1,5 раза больше памяти по сравнению с 32-разрядным приложением в 32-разрядной операционной системе Windows?
Брюс ответ:
Ранее мы уже обсуждали преимущества и недостатки сохранения всего 64-битного кода и некоторые эффекты «смешивания и сопоставления». влияет Сегодня мы рассмотрим, как 32-битные приложения выполняются в 64-битных версиях Windows.
64-разрядная операционная система Windows не может запустить 32-разрядную программу Windows без какой-либо дополнительной помощи. Они просто слишком разные: от указателей и типов данных, до того, как системные вызовы (как программы используют ресурсы базовой операционной системы). Вам нужен какой-то способ сделать их совместимыми.
Понимание WoW64
Windows использует подсистему WoW64 (Windows32 на Windows64) для компенсации различий. Он эффективно работает как 32-разрядный мини-эмулятор Windows в системах x64 и как полноценный эмулятор в системах Itanium (IA64).
Системы IA64 требуют полного эмулятора из-за различий в инструкциях процессора и размерах страниц памяти (4K в x86 и x64, 8K в IA64). Поскольку процессоры x64 имеют все инструкции процессоров x86 и используют один и тот же размер страницы памяти, для него не требуется полный эмулятор.
В обоих случаях WoW64 обеспечивает интерфейс между 64-битным ядром Windows и 32-битной версией ntdll.dll (содержит список основных функций ядра Windows), перехватывая вызовы ядра и изменяя их, чтобы они могли обрабатываться родные 64-битные функции, предоставляемые ядром Windows.
Для достижения этой цели в системах x64 / IA64 используются 3 DLL-файла: wow64cpu.dll, wow64win.dll и wow64.dll. Их функции заключаются в том, чтобы абстрагировать характеристики процессора и предоставлять thunks (о них мы поговорим позже ) в win32k.sys, который предоставляет функциональность «окна», и ntoskrnl.exe, который содержит исполнительный модуль, ядро, менеджер памяти, планировщик процессов (не для путать с планировщиком заданий, доступным из панели управления) и другими основными элементами операционной системы.
Thunk — это подпрограмма (воспринимается как последовательность инструкций, выполняющих одну задачу), которая позволяет программе выполнять общую подпрограмму или функцию в системе.
В этом случае он извлекает аргументы из стека вызовов 32-битной программы, преобразует их в их 64-битные аналоги и выполняет 64-битный системный вызов. После возврата из вызова он преобразует 64-битные результаты обратно в 32-битные и возвращает их обратно в стек вызовов программы для использования вызывающей стороной.
Все операции выполняются в пользовательском режиме (который имеет ограниченные разрешения) по двум причинам. Во-первых, он минимизирует влияние ошибок в коде, которые могут привести к дыре в безопасности, повреждению данных или сбою системы при работе в режиме ядра.
Во-вторых, это снижает влияние на производительность, которое оно будет иметь при работе в режиме ядра (режиме, используемом основными компонентами операционной системы) из-за накладных расходов, возникающих при переключении между режимом пользователя и режимом ядра и обратно.
Возвращаясь к системам Itanium, следует отметить и другие важные отличия. Системы IA64 используют два дополнительных файла. IA32exec.bin — это программный эмулятор x86, а Wowia32x.dll обеспечивает интерфейс между WoW64 и программным эмулятором.
32-разрядный процесс загрузит эти файлы, а также 64-разрядную версию ntdll.dll. Это единственные 64-разрядные двоичные файлы, которые могут быть загружены в 32-разрядный процесс до Windows 7. В Windows 7 и более поздних версиях также есть другая DLL, apisetschema.dll, которая будет загружена во все процессы.
Когда запускается 32-разрядный процесс, он загружает файл Wow64.dll, который, в свою очередь, загружает 32-разрядную версию ntdll.dll и все необходимые 32-разрядные библиотеки DLL из % systemroot% \ SysWOW64 . Большинство этих файлов идентичны двоичным файлам в 32-разрядной системе, хотя некоторые из них были переписаны, чтобы вести себя по-другому в WOW64.
Глядя на список загруженных библиотек DLL, мы видим, что в процессе под Win64 загружено 9 библиотек DLL, которых нет в системе Win32.
Теперь у вас может возникнуть искушение посмотреть на размеры файлов, сложить их и использовать их в качестве основы для определения объема используемой дополнительной памяти, но в результате вы получите неточные результаты. Эти файлы по своей природе предназначены для использования в качестве общих компонентов, и в результате первый файл, для которого требуется DLL, загружает его в память.
Последующие программы, которым требуется одна и та же DLL, не загружают весь компонент в память. Они получают указатель на уже загруженный компонент и выделяют ОЗУ для дополнительных элементов, которые загружаются в процесс.
Наша тестовая установка
Чтобы увидеть, что происходит, я настроил две виртуальные машины под управлением Windows 7 Ultimate с 2 ГБ оперативной памяти, выделенной для каждой. Одна из них — 32-битная версия, а другая — 64-битная. Оба прошли одинаковый процесс установки и исправления.
После того, как обе системы были исправлены, я отключил файл подкачки на обеих, чтобы получить лучшее представление об использовании памяти, гарантируя, что ОЗУ не может быть выгружено на диск. После этого LibreOffice 5.0.3.2 был установлен.
Копия Sysinternals Process Explorer было также размещено на обеих машинах. Это инструмент, который я использовал для сбора информации об использовании памяти. Настройка столбца по умолчанию была изменена, чтобы я мог посмотреть на использование Рабочего набора и WS Private.
Эти числа рабочих наборов отражают объем оперативной памяти, используемой программами. Это еще более усложнило ситуацию, отразив объем памяти, используемый разделяемыми библиотеками, даже если они уже были загружены другим процессом. Из-за этого, если вы добавите весь столбец, вы можете получить общий объем памяти, превышающий установленную . Рабочий набор по-прежнему является лучшим индикатором того, сколько именно памяти требуется для процесса.
Процессы, которые мы изучаем, тоже не одиноки. Различные программы LibreOffice запускают еще один процесс, soffice.exe, который будет выполнять еще один процесс, soffice.bin. Нам необходимо просмотреть итоги всех трех процессов, чтобы увидеть эффективное использование памяти каждой программой.
Для первоначального теста я просто по отдельности открыл Writer, Calc и Impress, чтобы посмотреть, сколько памяти они потребляют без загрузки данных, и экспортировал данные из Process Explorer. С Calc и Impress я открыл 3,7 МБ файл .xls и 3,9 МБ файл .pptx соответственно и записал новое использование памяти. Результаты можно увидеть в таблице ниже. Все данные в КБ.
Большой сюрприз произошел с Impress. Без документа он использовал на 4,1% больше оперативной памяти в 64-битной системе и на 9,9% меньше при загруженном документе. Я выкопал несколько других презентаций и получил схожие результаты со всеми из них. 64-битная система использовала меньше оперативной памяти, чем 32-битная.
Итак, требуют ли 64-разрядные версии Windows больше оперативной памяти, чем их 32-разрядные аналоги, при запуске 32-разрядных приложений? В общем да.
Но вам нужно обновить оперативную память? Возможно нет. Разница на самом деле не такая большая. Это, конечно, не в 1,5 раза отличается.