Sia la velocità che la funzionalità.
La storia della memoria virtuale
Tutti i sistemi operativi moderni come Windows, Linux e MacOS usano la memoria virtuale. La memoria virtuale è un modo pulito e assistito dall'hardware di mentire al tuo computer su quanta memoria c'è. La vostra CPU ha una Memory Management Unit (MMU), che mappa la memoria usata da ogni programma nella memoria fisica effettiva. Questo dà due vantaggi immediati: ogni programma inizia nella stessa posizione in memoria, dal punto di vista di quel programma, e tutti i programmi sono isolati gli uni dagli altri. Il programma A non avrà accesso alla memoria del programma B.
Ma diciamo che avete un computer da 8GB e sia il programma A che il programma B allocano ciascuno un buffer di memoria di 4GB. Questo è troppo, naturalmente, ma è anche il caso che i progettisti del sistema operativo sappiano che a volte i programmatori chiedono molto di più di quanto avranno mai bisogno. Così ognuno di quei blocchi da 4GB sarà allocato nella memoria virtuale, ma non necessariamente allocato realmente. Ogni programma (ogni processo) ha la propria mappatura della memoria, suddivisa in piccole "pagine" di memoria. La tabella MMU può essere aggiornata per queste allocazioni, ma alcune o tutte quelle pagine sono segnate come non effettivamente allocate.
Quindi, mentre i programmi girano, la memoria che non è in memoria segnalerà una trappola per il processore quando un processore tenterà di accedervi. Questa trappola salta al gestore della memoria del sistema operativo. Se c'è ancora memoria disponibile, una parte di questa sarà allocata nella RAM fisica e assegnata alla pagina che ha subito la trappola, e per motivi di efficienza, probabilmente un po' di più. Un vantaggio immediato di questo è che il programma, grazie alla gestione della memoria, può ottenere un blocco contiguo di memoria, fino ai 4GB richiesti in questo caso, anche se un blocco contiguo non esiste nella memoria fisica reale.
Ma cosa succede se non c'è più memoria? Un'opzione sarebbe, naturalmente, quella di segnalarlo come un errore di esaurimento della memoria e terminare il programma. Ma molto tempo fa, i progettisti di sistemi operativi hanno capito che molti programmi caricano codice che viene usato solo una volta o usato raramente. Gli utenti possono caricare programmi che possono rimanere inattivi, consumando risorse per poco valore. Così le tabelle di gestione della memoria nel sistema tracciano anche quali pagine MMU sono state usate, quali sono state usate di recente, ecc. E questo permette al sistema operativo di scaricare un po' di memoria inutilizzata, per soddisfare questo bisogno di più RAM per il programma A.
Ora, se le pagine di memoria che vengono recuperate contengono codice eseguibile, è codice che è stato caricato dall'immagine su disco del programma. Quella pagina può essere semplicemente marcata come non in memoria, e quella RAM può essere recuperata. Tuttavia, se la memoria contiene dati, questi devono essere messi da qualche parte. Quel posto è praticamente sempre un posto sul disco. I sistemi Windows hanno un "file di swap", mentre i sistemi Linux hanno tipicamente una "partizione di swap". In entrambi i casi, c'è un pezzo di disco da qualche parte, sia che usiate un HDD o un SSD, che è lì per virtualizzare la vostra RAM.
Il Colpo di Performance della VM
C'è quindi un piccolo overhead nella gestione della memoria di base, o così sembrerebbe. Dopo tutto, ogni volta che il vostro programma prende una trappola nel gestore della memoria, è un pezzo di tempo mangiato che sarebbe stato una singola istruzione. Quindi in un certo senso, sì, sta rendendo le cose più lente.
Ma il vero rallentamento sta andando sul disco piuttosto che sulla RAM. Non importa se avete un vecchio disco IDE parallelo o l'ultimissimo SSD M.2 su quattro canali PCIe, il vostro disco è molte, molte volte più lento della vostra DRAM. E quindi la prima vittoria di avere più memoria è evitare i page fault, queste trappole per il gestore della memoria che hanno bisogno di scambiare dentro e fuori dal disco.
La vittoria delle prestazioni della VM
Considerate anche che la memoria virtuale non è apparsa magicamente un giorno in un sistema operativo moderno. I progettisti di sistemi operativi, i programmatori di applicazioni, ecc. hanno vissuto con la memoria virtuale per oltre cinquant'anni. Ci sono enormi benefici in termini di prestazioni con la memoria virtuale.
Uno è semplicemente spremere quell'applicazione che altrimenti non ci starebbe. Negli anni '90, lavoravo in un'azienda che faceva un'applicazione di presentazione multimediale. Questa applicazione girava su MS-DOS, ma mischiare un sacco di foto e video poteva essere una sfida. MS-DOS, naturalmente, non aveva memoria virtuale. Ma a quei tempi, se si eseguiva un programma MS-DOS su OS/2 di IBM, si usava il gestore di memoria OS/2 e voilà! Memoria virtuale con paginazione. Così le presentazioni che non giravano sotto MS-DOS giravano sotto OS/2 sulla stessa limitata piattaforma di computer di allora.
Alcune altre caratteristiche sono utilizzate, che si tratti di paginazione o meno. Poiché il gestore della memoria sa quale memoria è stata allocata, può recuperarla tutta senza che le applicazioni debbano spendere sforzi di codifica per recuperarla. Questa non è una scusa per una programmazione sciatta, ma va insieme a quel fattore di protezione - le risorse di un programma morto possono essere trovate e restituite al sistema. Anche altri aspetti della progettazione dei programmi si sono evoluti per trarre vantaggio dai sistemi di memoria virtuale.
E i sistemi operativi stessi si sono evoluti. Dato che un sistema gestito in memoria può adattarsi alla RAM disponibile, i sistemi operativi moderni non lasciano semplicemente la RAM inutilizzata in giro, ma la allocano quando non viene utilizzata per velocizzare il sistema. Buffer di memoria più grandi, pezzi di codice che potrebbero essere necessari in seguito, ecc. possono essere allocati senza paura di soffocare i programmi utente.
Questo non è illimitato, naturalmente. Ho qui un sistema con 64GB DRAM, che esegue un browser, un programma CAD e alcune utility, e sto usando 21.8GB. Questo funzionerebbe facilmente su un sistema da 16GB, e funzionerebbe abbastanza bene su un sistema da 8GB. Ma le ottimizzazioni che il sistema operativo sta facendo per accelerare le cose andrebbero perse, quindi avrei un sistema più lento. È possibile che nel caso di 8GB vedrei abbastanza paginazione della memoria da rallentare ancora di più.
Più RAM, più capacità... Ai margini
Naturalmente, parlando di memoria grande, stiamo parlando di sistemi a 64 bit. La comune "regola empirica" per la memoria è almeno 2GB per core della CPU, quindi oggi, 8GB su un sistema a 4 core, 16GB su un sistema a 6 core come il mio (12GB non è un'opzione). Questo si basa sul vecchio limite a 32-bit nella maggior parte dei sistemi operativi di 2-3 GB per processo utente e qualche supposizione che non si stiano eseguendo troppi programmi diversi tutti insieme che effettivamente consumano il tempo della CPU (quelli inattivi, naturalmente, possono essere avviati fuori dalla memoria senza troppi rallentamenti). Ma questa è solo una linea guida minima.
E alcune cose semplicemente non funzionano in piccoli pezzi di memoria, ma data la dimensione della RAM sui computer medi in questi giorni, il numero di queste applicazioni lampeggia regolarmente. Prima del mio ultimo aggiornamento del PC, nel 2013, avevo un PC con 16GB di RAM, e mi stava bloccando. Una delle cose che faccio è la composizione di foto di grandi dimensioni, e il programma principale che uso per questo è piuttosto affamato di memoria. Sto cucendo insieme dozzine di immagini da 16Mpixel o 20Mpixel, e mi stavo scontrando con un muro, esaurendo la memoria anche con un file di pagina abbastanza grande.
Così ho costruito il mio nuovo PC con 64GB DRAM, il massimo che la scheda principale poteva gestire, e ho proceduto ad eseguire alcune di quelle composizioni di foto... e sono rimasto immediatamente senza memoria. Quindi è stata colpa mia - ho provato a farne due allo stesso tempo. Andando uno alla volta, sono abbastanza bravo in questi giorni.