Нещодавно я зацікавився загальною проблемою оптимізації використання пам’яті в ситуації, коли доступно більше одного виду пам’яті, і існує компроміс між ємністю певного сегмента пам’яті та швидкістю доступу до неї.
Знайомий приклад - програма, яка вирішує, коли читати з / запису в кеш процесора, оперативної пам’яті та жорсткого диска (через віртуальну пам’ять).
Мене особливо цікавить особливий випадок, коли обсяг даних (включаючи саму програму), які потрібно завантажити, значно перевищує ємність найшвидшого доступного сховища (тобто тривіальне рішення "просто завантажувати все" не застосовується).
Я виявив, що сторінка Вікіпедії, що описує деякі загальні алгоритми кешування, це майже те, що я хочу. На жаль, це дещо низькі рівні:
- Багато з них, наприклад, LRU або MRU, мають сенс лише у тому випадку, якщо у вас є підпрограми, до яких можна отримати доступ багато разів. Якщо у мене є програма з великою кількістю підпрограм, до яких ніколи не можна отримати доступ за певний цикл, а до деяких з них звертаються один-два рази, ця стратегія ніколи не працюватиме, оскільки вона не може зібрати достатньо даних про те, що зазвичай використовується, а що ні.
- Інші, наприклад, CLOCK, схоже, мають справу з особливостями впровадження, а не насправді атакують корінь проблеми.
- Я знаю, що існує стратегія, коли один спочатку профілює програму під час тестового запуску, а потім забезпечує профіль для операційної системи, щоб оптимізувати її відповідно. Однак ми все ж повинні вирішити проблему надання справді репрезентативного «прикладу використання» під час створення профілю.
Я дійсно хочу дізнатись про це: Коли ми абстрагуємо всі технічні засоби та програмне забезпечення і говоримо в чисто теоретичному контексті, чи можна якось проаналізувати структуру алгоритму, розробити ефективну стратегію кешування для це грунтується на високому рівні розуміння того, що алгоритм працює?