L'algoritmo di sostituzione della cache più efficiente [chiuso]

Wikipedia elenca 11 algoritmi di sostituzione della cache . Supponendo di non sapere quasi nulla dell'applicazione che sto per sviluppare, cosa dovrei usare come algoritmo di sostituzione della cache "predefinito"?

Se ricordo correttamente dal mio corso OS, LRU è il miglior algoritmo di sostituzione della cache generale. Ma forse mi sbaglio.

Inoltre, questa è una domanda un po 'accademica, poiché, in generale, la memoria principale è economica e abbondante e non ho davvero bisogno di preoccuparmi troppo della dimensione della cache.

Immagino che la risposta migliore sia che dipende. Nella mia esperienza ci sono molti fattori che vanno nella scelta degli algoritmi di memorizzazione nella cache.

Fattori da considerare

1. Bilancia lettura / scrittura. (Quale percentuale di accessi sono letture rispetto a scritture)
2. Quantità di cache.
3. Tipo di supporto dietro la cache. (Sono unità SATA lente o unità SSD veloci?)
4. Hits vs Misses. (Con che frequenza vengono riscritte o rilette le cose?)
5. Dimensione di accesso media (Questo va a scegliere la dimensione della pagina)
6. Quanto costano le letture e le scritture.

Una volta considerati tutti i diversi fattori, è quindi necessario trovare un algoritmo di cache che gestisca meglio. Ad esempio, supponiamo che tu abbia un'applicazione in cui ci sono molte scritture, alcune riscritture, letture di dati scritti di recente e una sorta di media di spinning. In questo caso si vorrebbe una sorta di algoritmo di cache ibrida. Per gestire i dati di scrittura potresti voler qualcosa come Wise order of Writes (WOW) e un algoritmo LRU per i dati che sono stati letti dal disco. La ragione di ciò è che gli accessi al disco sono molto costosi e l'algoritmo WOW renderà più efficiente la scrittura dei dati e la LRU manterrà i dati a cui si accede frequentemente sempre nella cache.

Supponiamo che tu abbia dischi SSD, che hanno tempi di accesso molto rapidi, potresti voler orientare la tua scelta verso l'algoritmo LRU poiché gli accessi al disco sono relativamente economici.

Quindi davvero quello che voglio dire è che non esiste una risposta "migliore". La migliore risposta è conoscere i fattori che si applicano a te e scegliere un algoritmo che li gestisca meglio.

Come trovare l'algoritmo per te

Profila il tuo sistema. Questo di solito comporta l'aggiunta di codice per conservare le statistiche per gli accessi alla memoria. Profilando puoi vedere quali fattori sono più importanti per te.

In passato ho aggiunto codice per tenere traccia di tutti gli accessi alla memoria per un periodo di tempo. Poi più tardi cerco modelli. Cerco riletture, riscritture, accesso sequenziale, accesso casuale, ecc.

Dopo aver identificato le cose importanti, è necessario esaminare tutti i diversi tipi di algoritmi di memorizzazione nella cache per vedere quali gestiscono le cose meglio.

Supponendo che tu non sappia quasi nulla dell'applicazione che stai per sviluppare, dovresti saperne di più prima di scegliere e implementare effettivamente un sistema cache. In altre parole, non esistono implementazioni predefinite: alcune sono buone per alcuni scopi e totalmente cattive per altri .

Ad esempio, prendi solo due implementazioni: meno utilizzate di recente e meno utilizzate di frequente. Come decidere quale utilizzare prima di un altro?

• LRU è utile quando sei abbastanza sicuro che l'utente accederà più spesso agli elementi più recenti e non tornerà mai o raramente a quelli vecchi. Un esempio: un utilizzo generale di un client di posta elettronica. Nella maggior parte dei casi, gli utenti accedono costantemente alle mail più recenti. Li leggono, li rimandano, ritornano tra pochi minuti, ore o giorni, ecc. Possono ritrovarsi a cercare un messaggio che hanno ricevuto due anni fa, ma accade meno frequentemente rispetto all'accesso ai messaggi ricevuti nelle ultime due ore.

• D'altra parte, LRU non ha senso nel contesto in cui l'utente accederà ad alcuni elementi molto più frequentemente di altri. Un esempio: ascolto spesso la musica che mi piace, e può succedere che su 400 canzoni ascolto le stesse cinque almeno una volta alla settimana, mentre ascolterò al massimo una volta all'anno 100 canzoni che non mi piacciono tanto. In questo caso, LFU è molto più appropriato.

Prendendo solo due delle implementazioni, vedi che non esiste un algoritmo "predefinito" che puoi usare quando non vuoi pensare a quale è meglio o non hai abbastanza informazioni sull'applicazione. È, beh, come chiedere se per impostazione predefinita, è necessario aggiungere, sottrarre, moltiplicare o dividere due numeri per trovare un risultato di un calcolo quando non si sa nulla al riguardo.

Perché limitare le tue scelte solo a Wikipedia? Se hai accesso a un database di ricerca come la Biblioteca digitale ACM troverai ancora più algoritmi. Fai anche attenzione a fare confusione con i brevetti. Ad esempio ARC è un buon algoritmo ma sfortunatamente è brevettato.

Potresti passare un sacco di tempo a soffrire per l'algoritmo "migliore", oppure potresti semplicemente implementare un semplice algoritmo e INIZIARE CON IL RESTO DEL SISTEMA. Quando hai qualcosa testabile poi preoccuparsi l'algoritmo.

Ottimizzazione prematura ...

Non esiste un algoritmo cache perfetto: puoi sempre trovare un caso che si comporta molto male.

Pertanto è importante conoscere il problema che viene memorizzato nella cache al fine di determinare quello che si comporterà meno male.

Inoltre, si dovrebbe considerare quanto tempo è necessario per le cose della cache e per quanto tempo si può memorizzare nella cache le cose ...