Mówiąc bardzo ogólnie i upraszczająco, i bez uwzględnienia szczegółów implementacji pamięci wirtualnej, deweloper zawsze ma wiedzę na temat przewidywania, której brakuje implementacji maszyny wirtualnej.
Deweloper zawsze może powiedzieć: „Nie muszę teraz ładować tego pliku audio. Muzyka w środku jest używana tylko w grze na ekranie”. I zaraz po zakończeniu gry na ekranie programista może powiedzieć: „Nie potrzebuję już tego klipu audio w pamięci fizycznej. Jest on używany tylko w tej grze na ekranie”.
System operacyjny nie ma takiego przewidywania. Być może uda się ustalić, wiele błędów strony później, że jakiś klip audio nie jest już potrzebny w pamięci fizycznej, ponieważ nie był dostępny od dłuższego czasu. Ale przekształcenie foresightu w spojrzenie z perspektywy czasu przekłada się na wiele błędów stron, a wiele błędów stron przekłada się na czkawkę w liczbie klatek na sekundę w oprogramowaniu tak krytycznym czasowo jak gra wideo. Tam dalekowzroczność dewelopera naprawdę pomaga, jeśli chcesz uniknąć takich czkawek.
I dotyczy to koncepcyjnie niezależnie od sprzętu i oprogramowania. Zakładając, że stronicowanie w pamięci jest kosztowne, to przewidywanie programisty zawsze pomoże w zmniejszeniu tego kosztu.
Mówiąc jeszcze szerzej, między projektantem sprzętu, projektantem kompilatora, projektantem systemu operacyjnego / sterowników i twórcą aplikacji jest niekończący się cykl. Twórcy sprzętu / kompilatora / systemu operacyjnego / sterownika często próbują wdrożyć optymalizacje w celu przyspieszenia przeciętnej aplikacji w oparciu o zwykłe wzorce dostępu do pamięci, a czasem może z nadzieją: „Ludzie powinni po prostu móc pisać kod, jak chcą i to powinno być szybkie ”.Ale jeśli pojawi się jakakolwiek myśl o tym typie, zwykle nie udaje się to w przypadku pól krytycznych pod względem wydajności, ponieważ wtedy programiści o krytycznej wydajności zaczynają poznawać skomplikowane szczegóły swojego kompilatora, sprzętu, systemu operacyjnego, sterowników itp. I zaczynają pisać kod zaprojektowane tak, aby wykorzystać to w jak największym stopniu, aby napisać najszybszy możliwy kod (takie jak prefiksy, dzielenie pola gorącego / zimnego, SoAs itp. dla kodu przyjaznego dla pamięci podręcznej). I to jest jak gra, która nigdy się nie kończy. Te rzeczy nigdy nie są traktowane jako czarne skrzynki w polach krytycznych pod względem wydajności, ponieważ programiści konkurują o wydajność.
Osobiście chciałbym, żeby pamięć wirtualna nie istniała, ponieważ dodaje ona dodatkową warstwę nieprzewidywalności wydajności w sposób, który bywa zbyt ekstremalny i niesie ze sobą zbyt dużą utratę wydajności, gdy rzeczy idą naprawdę na południe do punktu bezużyteczności. Czasami natrafiam na przypadki, w których korzystałem z aplikacji, w której przypadkowo wpisałem dodatkową cyfrę lub dwie, gdy byłem pijany w jakimś polu wejściowym, co spowodowało, że wyczerpało ono pamięć fizyczną tak szybko, że doprowadziło system operacyjny do pełzania, gdzie nie mogłem t nawet kliknąłem przycisk Anuluj na pasku postępu i musiałem czekać 10 minut, jednocześnie wciskając Ctrl + Alt + Del, aby zabić proces i przeklinać siebie podczas rozlewania drinka, aby wrócić do punktu, w którym rzeczy są znowu użyteczne, i że pomimo zapisania pliku strony na dysku SSD. W takich przypadkach wolałbym błąd „brak pamięci” lub coś takiego, w którym to momencie mógłbym zamknąć niektóre z moich 17 zakładek porno (w porządku, i tak dodaję do ulubionych), aby zwolnić trochę pamięci, a następnie natychmiast przejść wznowienie mojej działalności.