Найефективніший алгоритм заміни кешу [закритий]

У Вікіпедії перелічено 11 алгоритмів заміни кешу . Якщо припустити, що я майже нічого не знаю про програму, яку я буду розробляти, що я повинен використовувати як алгоритм заміни кешу за замовчуванням?

Якщо я пам'ятаю правильно з курсу моєї ОС, LRU - найкращий загальний алгоритм заміни кешу. Але, можливо, я помиляюся.

Крім того, це трохи академічне запитання, оскільки, як правило, основна пам'ять дешева і велика, і мені не дуже потрібно турбуватися про розмір кешу.

Я думаю, найкраща відповідь - це залежить. На мій досвід, існує багато факторів, які входять у вибір алгоритмів кешування.

Фактори, які слід враховувати

1. Читання / запис балансу. (Який відсоток доступу читається проти запису)
2. Обсяг кешу.
3. Тип носія за кешем. (Це повільні диски SATA або швидкі SSD-накопичувачі?)
4. Хіти проти Місс. (Як часто речі переписуються чи перечитуються?)
5. Середній розмір доступу (це залежить від вибору розміру сторінки)
6. Наскільки дорого читають і пишуть.

Після розгляду всіх різних факторів вам потрібно знайти алгоритм кешування, який найкраще обробляє. Наприклад, скажіть, що у вас є програма, у якій багато записів, переписується, читається нещодавно написані дані та якісь спінінг-носії. У цьому випадку ви хочете свого роду гібридний алгоритм кешування. Для обробки даних запису вам може знадобитися щось на кшталт Мудрий порядок записів (WOW) та алгоритм LRU для даних, зчитаних з диска. Причиною цього є те, що доступ до диска є дуже дорогим, а алгоритм WOW зробить більш ефективним записування даних, і LRU буде постійно зберігати дані, які часто отримують доступ до кешу.

Скажімо, у вас є диски SSD, які мають дуже швидкий час доступу, можливо, ви захочете перенести свій вибір до алгоритму LRU, оскільки доступ до диска порівняно недорогий.

Тож справді, що я хочу сказати, це те, що немає "найкращої" відповіді. Найкраща відповідь - це знати фактори, які застосовуються до вас, і вибрати алгоритм, який найкраще справляється з ними.

Як знайти алгоритм для вас

Профілюйте свою систему. Зазвичай це включає додавання коду для збереження статистики для доступу до пам'яті. За допомогою профілювання ви можете бачити, які фактори є найбільш важливими для вас.

Раніше я додав код для відстеження всіх доступів до пам'яті протягом певного періоду часу. Потім пізніше шукаю візерунки. Я шукаю перечитування, повторне записування, послідовний доступ, випадковий доступ тощо.

Після того, як ви визначили важливі речі, вам слід переглянути всі різні алгоритми кешування, щоб побачити, яка обробка речей найкраща.

Якщо припустити, що ви майже нічого не знаєте про додаток, яке ви збираєтеся розробляти, вам слід дізнатися про нього більше, перш ніж вибирати та впроваджувати кеш-систему. Іншими словами, реалізацій за замовчуванням не існує: одні хороші для одних цілей, а для інших цілком погані .

Наприклад, візьміть лише дві реалізації: Найменш нещодавно використані та Найменш часто використовувані. Як вирішити, який з них використовувати до іншого?

• LRU - це добре, коли ви майже впевнені, що користувач частіше отримуватиме доступ до останніх предметів і ніколи або рідко повертається до старих. Приклад: загальне використання клієнта електронної пошти. У більшості випадків користувачі постійно отримують доступ до останніх листів. Вони читають їх, відкладають, повертаються назад за кілька хвилин, годин чи днів тощо. Вони можуть опинитися в пошуку пошти, яку вони отримали два роки тому, але це трапляється рідше, ніж звернення до листів, які вони отримували за останні дві години.

• З іншого боку, LRU не має сенсу в контексті, коли користувач буде отримувати доступ до деяких елементів набагато частіше, ніж до інших. Приклад: Я часто слухаю музику, яка мені подобається, і може статися, що на 400 пісень я б слухав ті самі п’ять хоча б раз на тиждень, тоді як слухатиму максимум раз на рік 100 пісень, які мені теж не подобаються багато. У цьому випадку ЛФУ набагато доречніше.

Беручи лише дві реалізації, ви бачите, що не існує алгоритму «за замовчуванням», який можна використовувати, коли ви не хочете думати, який з них кращий або не має достатньої інформації про програму. Ну, як запитати, чи за замовчуванням потрібно додавати, віднімати, множувати або ділити два числа, щоб знайти результат обчислення, коли ви нічого про це не знаєте.

Навіщо обмежувати свій вибір лише Вікіпедією? Якщо у вас є доступ до бази даних досліджень, як-от Цифрова бібліотека ACM, ви знайдете ще більше алгоритмів. Також слід пам’ятати про возитися з патентами. Наприклад, ARC - хороший алгоритм, але, на жаль, він запатентований.

Ви можете витратити багато часу на агонізацію над "найкращим" алгоритмом, або можете просто реалізувати простий алгоритм і ЗАПОВІДИТИ З РЕШИМИ СИСТЕМИ. Коли у вас є щось перевірене, то хвилюйтеся про алгоритм.

Передчасна оптимізація ...

Не існує ідеального алгоритму кешування - ви завжди можете знайти випадок, який веде себе дуже погано.

Тому важливо знати проблему, яку кешують, щоб визначити ту, яка буде вести себе найменш погано.

Крім того, ви повинні розглянути питання про те, як довго потрібно кешувати речі і скільки часу ви можете кешувати речі ...