Ниже приведен перевод статьи «Road to Snow Leopard: twice the RAM, half the price, 64-bits» с ресурса AppleInsider.com. Статья затрагивает особенности подсистемы памяти анонсированной ОС, а также содержит сравнение работы подсистемы памяти в 32-битных ОС от Apple и Microsoft.
В то время как 4Гб ограничение, описанное ранее, только начинает отражаться на повседневных пользователях, существует еще одна проблема, которая ограничивает полное использование установленной памяти определенным приложением. На самом деле реальная проблема нехватки оперативной памяти состоит не в том, сколько памяти можно установить, а в том, какое количество памяти приложение может адресовать для своих нужд.
32-битные версии Windows, Linux, и Mac OS X по-разному управляют памятью в 4 Гб. Это означает, что их переход на 64-битные версии даст пользователям совершенно различные улучшения. В 32-битных версиях Linux и Mac OS X ядро выделяет 4 Гб виртуальной памяти для себя и столько же для каждого приложения (или процесса). Подсистема виртуальной памяти распределяет память исходя из соображений максимальной производительности. Понятное дело, что чем больше памяти, тем лучше.
В 32-битной версии Windows каждое приложение получает только 2 Гб виртуального адресного пространства; 4 Гб разделяются ядром. По умолчанию, разделение происходит пополам, так что приложение получает в пользование 2 Гб, в то время как ядро резервирует остальные 2Гб. Используя специальную настройку, Windows может быть установлена в пропорцию 3 Гб / 1 Гб, что дает приложению еще один Гб, но не выделяет все 4 Гб. Это влияет на каждое приложение, которому необходимо много памяти.
Причина такого разделения в Windows является производительность. Системные вызовы Windows могут адресовать области памяти, выделенные для приложения, и для ядра за один подход, потому что CPU может непосредственно адресовать и память ядра, и память приложения используя кэшированную lookup-таблицу TLB.
В противовес Windows, 32-битные версии Linux и Mac OS X предоставляют каждому приложению все 4 Гб виртуальной памяти, их адреса перекрываются с адресами ядра. Это означает, что таблица TLB центрального процессора не может хранить кэшированные адреса, потому что не может отличить один от другого.
Каждый раз, когда подсистема памяти перемещается между двумя адресными пространствами, она должна очищать таблицу TLB. Каждый вызов 32-битной системы очищает TLB дважды, повторно устанавливая кэш в ноль и тем самым снижая производительность, ради которой и была придумана. В Windows очищение происходит только в момент переключения между приложениями, поскольку каждое приложение делит свое пространство виртуальной памяти с ядром.
В 64-bit Mac OS X Leopard 64-битные приложения имеют колоссальный объем памяти, который намного превышает 4 Гб. Это позволяет 64-битным приложениям занимать старшие адресные пространства, в то время как ядро занимает младшие. В отсутствии наложения адресов, TLB не надо обнулять и она может работать именно так, как задумывалось. Это преимущество пока что не полность использовано, поскольку ядро и большинство приложений все еще 32-битные (на рисунке ниже — слева).
Snow Leopard даст возможность использовать 64-битные ядро и приложения, полностью исключая необходимость очищать TLB, потому что новое ядро не будет иметь разделяемых адресных пространств, даже в случае 32-битных приложений (на рисунке ниже — справа). Это будет превосходством всех пользователей, использующих 64-битную ОС и процессор Core 2 или лучше, даже при использовании чипсета Santa Rosa, который тоже сможет запускать 64-битные приложения и виртуальная память не будет ограничена количеством адресуемой системной памяти.
Нынешние 32-битные приложения (Mac) имеют доступ к большей памяти, чем 32-битные приложения Windows, но при этом обнуляют таблицу TLB каждый раз, когда приложение делает системный вызов, чем если бы просто переключалось между приложениями. С приходом 64-битных Leopard предлагает большую производительность с неограниченной виртуальной адресацией.
В 64-битной Windows приложения выйдут за предел 2 Гб адресуемого пространства, но существенного прироста производительности не будет, поскольку Windows ранее не сталкивалась с проблемой очищения TLB.
Обе платформы только выиграют от дополнительных 64-разрядных регистров. Этот фактор также объясняет, почему пользователи PowerPC G5 не увидят большого прироста производительности от стандартных приложений, портированных для 64-бит. У 32-битных приложений PowerPC уже есть дополнительное место в регистрах. В большинстве случаев, они будут работать даже медленнее из-за дополнительной работы по адресации. Это одна из ключевых причин, почему Snow Leopard будет только Intel.
Существует дополнительная нагрузка на Intel в связи с 64-битной адресацией; она связана с отсутствием рынка 64-битных приложений для платформы Windows. С этой проблемой сталкивалась Adobe при выпуске Photoshop CS4.
В то же время, все Mac сейчас 64-битные и используют 64-битную ОС, поэтому не существует проблемы для адаптации ранее написанных 64-битных программ от Apple. За исключением пожалуй программ от сторонних разработчиков. Apple должна обеспечить разработчиков новыми версиями драйверов и плагинов для нового ядра и заставить сторонних разработчиков сделать то же самое.
Системная память против памяти приложения.
В то время как 4Гб ограничение, описанное ранее, только начинает отражаться на повседневных пользователях, существует еще одна проблема, которая ограничивает полное использование установленной памяти определенным приложением. На самом деле реальная проблема нехватки оперативной памяти состоит не в том, сколько памяти можно установить, а в том, какое количество памяти приложение может адресовать для своих нужд.
32-битные версии Windows, Linux, и Mac OS X по-разному управляют памятью в 4 Гб. Это означает, что их переход на 64-битные версии даст пользователям совершенно различные улучшения. В 32-битных версиях Linux и Mac OS X ядро выделяет 4 Гб виртуальной памяти для себя и столько же для каждого приложения (или процесса). Подсистема виртуальной памяти распределяет память исходя из соображений максимальной производительности. Понятное дело, что чем больше памяти, тем лучше.
В 32-битной версии Windows каждое приложение получает только 2 Гб виртуального адресного пространства; 4 Гб разделяются ядром. По умолчанию, разделение происходит пополам, так что приложение получает в пользование 2 Гб, в то время как ядро резервирует остальные 2Гб. Используя специальную настройку, Windows может быть установлена в пропорцию 3 Гб / 1 Гб, что дает приложению еще один Гб, но не выделяет все 4 Гб. Это влияет на каждое приложение, которому необходимо много памяти.
Причина такого разделения в Windows является производительность. Системные вызовы Windows могут адресовать области памяти, выделенные для приложения, и для ядра за один подход, потому что CPU может непосредственно адресовать и память ядра, и память приложения используя кэшированную lookup-таблицу TLB.
Чем больше памяти, тем больше ответственность
В противовес Windows, 32-битные версии Linux и Mac OS X предоставляют каждому приложению все 4 Гб виртуальной памяти, их адреса перекрываются с адресами ядра. Это означает, что таблица TLB центрального процессора не может хранить кэшированные адреса, потому что не может отличить один от другого.
Каждый раз, когда подсистема памяти перемещается между двумя адресными пространствами, она должна очищать таблицу TLB. Каждый вызов 32-битной системы очищает TLB дважды, повторно устанавливая кэш в ноль и тем самым снижая производительность, ради которой и была придумана. В Windows очищение происходит только в момент переключения между приложениями, поскольку каждое приложение делит свое пространство виртуальной памяти с ядром.
В 64-bit Mac OS X Leopard 64-битные приложения имеют колоссальный объем памяти, который намного превышает 4 Гб. Это позволяет 64-битным приложениям занимать старшие адресные пространства, в то время как ядро занимает младшие. В отсутствии наложения адресов, TLB не надо обнулять и она может работать именно так, как задумывалось. Это преимущество пока что не полность использовано, поскольку ядро и большинство приложений все еще 32-битные (на рисунке ниже — слева).
Snow Leopard даст возможность использовать 64-битные ядро и приложения, полностью исключая необходимость очищать TLB, потому что новое ядро не будет иметь разделяемых адресных пространств, даже в случае 32-битных приложений (на рисунке ниже — справа). Это будет превосходством всех пользователей, использующих 64-битную ОС и процессор Core 2 или лучше, даже при использовании чипсета Santa Rosa, который тоже сможет запускать 64-битные приложения и виртуальная память не будет ограничена количеством адресуемой системной памяти.
Больше, лучше, быстрее
Нынешние 32-битные приложения (Mac) имеют доступ к большей памяти, чем 32-битные приложения Windows, но при этом обнуляют таблицу TLB каждый раз, когда приложение делает системный вызов, чем если бы просто переключалось между приложениями. С приходом 64-битных Leopard предлагает большую производительность с неограниченной виртуальной адресацией.
В 64-битной Windows приложения выйдут за предел 2 Гб адресуемого пространства, но существенного прироста производительности не будет, поскольку Windows ранее не сталкивалась с проблемой очищения TLB.
Обе платформы только выиграют от дополнительных 64-разрядных регистров. Этот фактор также объясняет, почему пользователи PowerPC G5 не увидят большого прироста производительности от стандартных приложений, портированных для 64-бит. У 32-битных приложений PowerPC уже есть дополнительное место в регистрах. В большинстве случаев, они будут работать даже медленнее из-за дополнительной работы по адресации. Это одна из ключевых причин, почему Snow Leopard будет только Intel.
Тёмная сторона 64-бит.
Существует дополнительная нагрузка на Intel в связи с 64-битной адресацией; она связана с отсутствием рынка 64-битных приложений для платформы Windows. С этой проблемой сталкивалась Adobe при выпуске Photoshop CS4.
В то же время, все Mac сейчас 64-битные и используют 64-битную ОС, поэтому не существует проблемы для адаптации ранее написанных 64-битных программ от Apple. За исключением пожалуй программ от сторонних разработчиков. Apple должна обеспечить разработчиков новыми версиями драйверов и плагинов для нового ядра и заставить сторонних разработчиков сделать то же самое.
