Говоря просто в общих чертах и упрощенно, и без учета деталей реализаций виртуальной памяти, разработчик всегда заранее знает, чего не хватает реализации виртуальной памяти.
Разработчик всегда может сказать: «Мне не нужно загружать этот аудиофайл прямо сейчас. Музыка внутри используется только для игры поверх экрана». И сразу же после выхода игры за экран, разработчик может сказать: «Мне больше не нужен этот аудиоклип в физической памяти. Он используется только для этой игры поверх экрана».
ОС не имеет такого предвидения. Возможно, после многих сбоев страниц будет возможно выяснить, что какой-то аудиоклип больше не нужен в физической памяти, поскольку к нему давно не обращались. Но превращение предвидения в ретроспективу приводит к множеству ошибок страниц, а множество ошибок страниц приводит к сбоям в частоте кадров в программном обеспечении, столь же критичном по времени, как в видеоигре. Там предвидение разработчика действительно помогает, если вы хотите избежать таких сбоев.
И это относится концептуально независимо от аппаратного и программного обеспечения. Предполагая, что подкачка в памяти обходится дорого, предвидение разработчика всегда поможет сократить эти расходы.
Говоря еще шире, существует бесконечный цикл между разработчиком оборудования, разработчиком компилятора, разработчиком ОС / драйвера и разработчиком приложения. Разработчики оборудования / компилятора / ОС / драйвера часто пытаются реализовать оптимизацию для ускорения вашего среднего приложения на основе его обычных шаблонов доступа к памяти, и, возможно, иногда с такой надеждой: «Люди должны просто иметь возможность писать код так, как им хочется, и это должен быть быстрым. "Но если кто-то думал об этом типе, он обычно терпит неудачу в критических по производительности полях, потому что тогда разработчики, критичные к производительности, начинают изучать сложные детали своего компилятора, аппаратного обеспечения, ОС, драйверов и т. Д. И начинают писать код специально Предназначен для максимально возможного написания максимально быстрого кода (например, предварительных выборок, расщепления горячих / холодных полей, SoAs и т. д. для кода, удобного для кэширования). И это как игра, которая никогда не заканчивается. Эти вещи никогда не рассматриваются как черные ящики в областях, критичных к производительности, поскольку разработчики конкурируют за производительность.
Лично я бы хотел, чтобы виртуальная память не существовала, поскольку она добавляет дополнительный уровень непредсказуемости производительности способами, которые являются чрезмерно экстремальными и приводят к значительным потерям производительности, когда дела идут на юг, вплоть до непригодности., Я иногда сталкивался со случаями, когда я использовал какое-то приложение, в котором я случайно набрал лишнюю цифру или две, когда выпил в какое-то поле ввода, что затем приводило к такому быстрому истощению физической памяти, что приводило ОС к ползанию, где я не мог Я даже больше не нажимал кнопку «Отмена» на индикаторе выполнения, и ему пришлось ждать 10 минут, нажимая Ctrl + Alt + Del, чтобы остановить процесс, и проклинать себя, выплескивая свой напиток, чтобы вернуться к точке, где вещи снова можно использовать, и это несмотря на то, что файл подкачки хранится на SSD. В тех случаях, я бы скорее предпочел «из памяти» ошибку или что-то, и в этот момент я мог бы закрыть некоторые из моих 17 вкладок порно (это нормально, я закладка моих любимых во всяком случае), чтобы освободить память, а затем немедленно идти о возобновить мой бизнес.