Algoritma Penggantian Cache Paling Efisien [ditutup]


12

Wikipedia mencantumkan 11 algoritma penggantian cache . Dengan asumsi saya hampir tidak tahu apa-apa tentang aplikasi yang akan saya kembangkan, apa yang harus saya gunakan sebagai algoritma penggantian cache "default"?

Jika saya ingat dengan benar dari kursus OS saya, LRU adalah algoritma penggantian cache umum yang terbaik. Tapi mungkin saya salah.

Juga, ini sedikit pertanyaan akademis, karena, umumnya, memori utama murah dan berlimpah dan saya tidak benar-benar perlu khawatir tentang ukuran cache terlalu banyak.


1
Apakah pengambilan awal relevan dengan aplikasi Anda? Jika demikian, strategi pra-pengambilan dan penahanan harus dipertimbangkan bersamaan ketika memilih algoritma.
rwong

Anda perlu mendapatkan jejak sampel (daftar pola akses data) yang mewakili domain aplikasi yang Anda inginkan. Anda mungkin dapat menemukan set tes yang tersedia untuk umum dari penelitian akademik. Kemudian Anda dapat menerapkan setiap algoritma, melakukan simulasi, dan melaporkan temuan Anda. Gagal itu, gunakan LRU dengan penggantian acak hemat.
rwong

1
Jika Anda "hampir tidak tahu apa-apa tentang aplikasi" maka masih jauh dari awal untuk memikirkan algoritma penggantian cache yang "efisien".
Anon

Memori utama mungkin murah, tetapi jika kinerja merupakan masalah penting, efisiensi akses akan menjadi masalah. Saya tidak berpikir Anda bisa memilih strategi penggantian cache-kecuali Anda adalah kepala arsitek komputer baru. Kita semua mendapatkan apa pun yang ditawarkan pasar. Jika Anda harus cepat, Anda perlu mengatur struktur komputasi dan data Anda untuk membuat penggunaan hirarki memori yang efisien.
Omega Centauri

1
@Omega Centauri Anda memikirkan cache CPU saja, tetapi ada banyak lagi. OS cache file dan direktori yang digunakan, basis data cache data mereka, hampir setiap aplikasi melakukan banyak caching (misalnya hasil yang sudah dihitung).
maaartinus

Jawaban:


15

Saya kira jawaban terbaik adalah itu tergantung. Dalam pengalaman saya, ada banyak faktor yang masuk ke dalam memilih algoritma caching.

Faktor yang perlu dipertimbangkan

  1. Baca / Tulis Saldo. (Berapa persentase akses yang dibaca vs yang ditulis)
  2. Jumlah cache.
  3. Jenis media di balik cache. (Apakah drive SATA lambat atau drive SSD cepat?)
  4. Hits vs Misses. (Seberapa sering hal-hal ditulis ulang atau dibaca kembali?)
  5. Ukuran akses rata-rata (Ini berlaku untuk memilih ukuran halaman)
  6. Betapa mahalnya membaca dan menulis.

Setelah Anda mempertimbangkan semua faktor yang berbeda, Anda perlu menemukan algoritma cache yang menangani yang terbaik. Misalnya katakan bahwa Anda memiliki aplikasi di mana ada banyak penulisan, beberapa penulisan ulang, membaca data yang baru ditulis dan semacam media pemintalan. Dalam hal ini Anda ingin semacam algoritma caching hybrid. Untuk menangani data tulis, Anda mungkin menginginkan sesuatu seperti Wise order of Writes (WOW) dan algoritma LRU untuk data yang telah dibaca dari disk. Alasan untuk ini adalah bahwa akses disk sangat mahal dan algoritma WOW akan membuatnya lebih efisien untuk menulis data dan LRU akan menyimpan data yang sering diakses selalu dalam cache.

Katakanlah Anda memiliki disk SSD, yang memiliki waktu akses sangat cepat, Anda mungkin ingin mengarahkan pilihan Anda ke algoritma LRU karena akses disk relatif murah.

Jadi sebenarnya yang ingin saya katakan adalah tidak ada jawaban "terbaik". Jawaban terbaik adalah mengetahui faktor-faktor yang berlaku untuk Anda dan memilih algoritma yang paling baik menanganinya.

Bagaimana menemukan algoritme untuk Anda

Profil sistem Anda. Ini biasanya melibatkan penambahan kode untuk menjaga statistik untuk akses memori. Dengan membuat profil, Anda dapat melihat faktor mana yang paling penting bagi Anda.

Di masa lalu saya telah menambahkan kode untuk melacak semua akses memori selama periode waktu tertentu. Kemudian saya mencari polanya. Saya mencari membaca ulang, menulis ulang, akses sekuensial, akses acak, dll.

Setelah Anda mengidentifikasi hal-hal penting, Anda perlu melihat semua jenis algoritma caching untuk melihat mana yang menangani hal-hal terbaik.


Kerusakan faktor yang hebat. Tapi saya tidak yakin bagaimana cara menerapkannya, mengingat saya tahu domain aplikasi dan faktor-faktornya.
ashes999

@ Eash: Ada teknik rekayasa lama: buat beberapa dengan cara yang berbeda dan ukur mana yang paling baik.
Donal Fellows

Ketika saya mendengar "cache", saya memikirkan penyimpanan antara memori dan register CPU. Di sini Anda berbicara tentang cache disk, yang merupakan lapisan di antara memori dan satu atau lebih perangkat i / o.
Omega Centauri

@ barrem23 Jika Anda melakukan pemrograman terdistribusi, ada juga "jarak antara cache dan penyimpanan back-end yang di-cache" untuk dipertimbangkan. Tidak masalah, banyak, jika Anda memiliki SSD atau karat berputar sebagai penyimpanan Anda yang besar, stabil, jika penyimpanannya berjarak 15 ms, Anda tetap akan mengalami perjalanan pulang pergi minimal 30 ms.
Vatine

9

Dengan asumsi Anda hampir tidak tahu apa-apa tentang aplikasi yang akan Anda kembangkan, Anda harus tahu lebih banyak tentangnya sebelum benar-benar memilih dan menerapkan sistem cache. Dengan kata lain, tidak ada implementasi standar: beberapa baik untuk beberapa tujuan, dan benar-benar buruk untuk yang lain .

Misalnya, ambil hanya dua implementasi: Paling Baru Digunakan dan Paling Sedikit Digunakan. Bagaimana cara memutuskan mana yang akan digunakan sebelum yang lain?

  • LRU bagus ketika Anda cukup yakin bahwa pengguna akan lebih sering mengakses item terbaru, dan tidak pernah atau jarang kembali ke yang lama. Contoh: penggunaan umum klien email. Dalam kebanyakan kasus, para pengguna terus-menerus mengakses surat terbaru. Mereka membacanya, menundanya, kembali dalam beberapa menit, berjam-jam atau berhari-hari, dll. Mereka dapat menemukan diri mereka mencari surat yang mereka terima dua tahun lalu, tetapi itu terjadi lebih jarang daripada mengakses surat yang mereka terima dua jam terakhir.

  • Di sisi lain, LRU tidak masuk akal dalam konteks di mana pengguna akan mengakses beberapa item lebih sering daripada yang lain. Contoh: Saya sering mendengarkan musik yang saya sukai, dan bisa terjadi pada 400 lagu, saya akan mendengarkan lima lagu yang sama setidaknya sekali seminggu, sedangkan saya akan mendengarkan paling banyak sekali setahun 100 lagu yang tidak saya sukai juga banyak. Dalam hal ini, LFU jauh lebih tepat.

Dengan hanya mengambil dua implementasi, Anda melihat bahwa tidak ada algoritma "default" yang dapat Anda gunakan ketika Anda tidak ingin memikirkan mana yang lebih baik atau tidak memiliki cukup informasi tentang aplikasi. Ya, seperti menanyakan apakah secara default, Anda harus menambahkan, mengurangi, mengalikan, atau membagi dua angka untuk menemukan hasil kalkulus ketika Anda tidak tahu apa-apa tentang itu.


Ok, jadi bagaimana cara memilih algoritma? Jalankan melalui daftar Wikipedia dan lihat apa yang paling cocok?
ashes999

@ ashes999: persis! Pertama, Anda mempelajari lebih lanjut tentang persyaratan aplikasi yang harus dilakukan, kemudian Anda menganalisis pro dan kontra dari algoritma cache yang berbeda, dan akhirnya Anda memilih yang lebih tepat.
Arseni Mourzenko

3

Mengapa membatasi pilihan Anda hanya untuk Wikipedia? Jika Anda memiliki akses ke database penelitian seperti Perpustakaan Digital ACM Anda akan menemukan lebih banyak algoritma. Juga waspada tentang mengacaukan paten. Misalnya ARC adalah algoritma yang baik tetapi sayangnya dipatenkan.


2

Anda bisa menghabiskan banyak waktu untuk menderita atas algoritma 'terbaik', atau Anda bisa menerapkan algoritma sederhana dan MENDAPATKAN DENGAN REST OF THE SYSTEM. Ketika Anda memiliki sesuatu yang dapat diuji maka khawatir tentang algoritma.

Optimalisasi prematur ...


0

Tidak ada algoritma cache yang sempurna - Anda selalu dapat menemukan kasus yang berperilaku sangat buruk.

Oleh karena itu penting untuk mengetahui masalah yang sedang di-cache untuk menentukan yang akan berperilaku paling buruk.

Selain itu, Anda harus mempertimbangkan berapa lama Anda perlu menyimpan sesuatu dan berapa lama Anda bisa ...

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.