Чи є процесори, які виконують цю можливу оптимізацію запису кешу L1?

Коли процесор із кешем L1 робить запис, звичайно відбувається таке (якщо припустити, що лінія кеша, до якої він пише, вже є в кеші L1) кеш (крім оновлення даних) позначає цю кешову лінію як брудну , і буде виписати рядок із оновленими даними пізніше.

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

Моє запитання: чи є процесори, які виконують цю оптимізацію?

Передумови, чому я запитую: я пишу якийсь код, який повинен мати постійний доступ до пам'яті; тобто хтось, хто вміє слухати поведінку кеша, не повинен мати змогу виводити те, що я роблю. Деякі мої звернення - це записи, і, очевидно, для реалізації цього коду, багато записів будуть писати ті самі дані, які вже є. Мені потрібно робити записи, тому що, залежно від даних, дані, які я записую, можуть бути або не бути однаковими, і важливо виконувати ті самі дії незалежно. Якщо центральний процесор оптимізує насправді не записуючи "без зміни запису", це означатиме, що поведінка кешу буде змінюватися залежно від того, що я роблю, що підриває мою мету.

Отже, чи є процесор, який намагається оптимізувати запис таким чином?

За години пошуку я не зміг знайти процесор, який використовує цю специфічну оптимізацію. Більшість згаданих оптимізацій, як правило, стосуються удару / пропуску за допомогою операцій читання / запису та доступу до даних:

(сторінки 7 та) https://cseweb.ucsd.edu/classes/fa14/cse240A-a/pdf/08/CSE240A-MBT-L15-Cache.ppt.pdf

Однак це не означає, що цю оптимізацію неможливо здійснити. Взагалі, можна програмно отримати доступ до розміру кеш-лінії CPU. Також можна отримати доступ до поточних значень в регістрах кешу, але це дещо небезпечно. Якщо ви отримаєте неправильні регістри в поганий час, ви можете підробити ті, що стосуються запущеної програми. Або ви могли ненавмисно змінити вміст рядків, які ви намагаєтеся прочитати.

Отримання поточного значення в кеші реєстру

Крім того, всі теоретичні рішення потребують певної форми реалізації програмного забезпечення (асемблера). Найближче, що я знайшов, стосується архітектури ARM, яка, можливо, дозволяє керувати кешем. На додаток до цього, ви також повинні знати розмір лінії кешу для потрібного процесора. Ви можете уважно прочитати вміст кешу до другого місця в пам'яті, з кроком розміру рядків, і порівняти його з даними, які збираються записати в регістри (або в цьому випадку рядки кешу L1).

Прочитайте вміст кешу CPU

Звідти ви могли б розробити програмну систему, що запобігає однакові переписування. Хоча це трохи спрощено, це так, тому що рішення повинно бути застосовне до будь-якого ЦП, який існує.

Ще одна можливість, яку я знайшов, пов'язану з узгодженістю кешу:

Відповідний уривок із статті Вікіпедії про тісну узгодженість

Основним моментом, який привернув мою увагу, стосовно цього питання, був опис Snarfing:

Це механізм, коли кеш-контролер спостерігає за адресою та даними, намагаючись оновити власну копію місця в пам'яті, коли другий ведучий модифікує місце в основній пам'яті. Коли спостерігається операція запису до місця, в якому кеш має копію, контролер кешу оновлює свою власну копію місця прискореної пам’яті новими даними.

Іншими словами, можливо, вже існують механізми. Просто вони можуть не використовуватися для запропонованої вами оптимізації. Вам доведеться реалізувати програмне забезпечення, яке виконувало порівняння читання / запис.

Запис у кеш-пам'ять L1 - дуже важлива за часом операція.

Запис тих самих даних назад здається досить рідкісним. Оптимізація, яка прискорює роботу в даному конкретному випадку, не отримає багато загального прискорення.

З іншого боку, ця оптимізація вимагає порівняння старих даних та нових даних для кожного запису в кеш-пам'ять. Що ще гірше це те, що він вимагає, щоб дані, які потрібно записати, мали бути фактично доступними на момент написання!

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

Наприклад, якщо у вас є код C a [i] = x / y; поділ x / y займає надзвичайно багато часу для роботи на більшості процесорів. Однак більша частина роботи, необхідної для збереження результату до [i], відбулася задовго до закінчення поділу; єдине, чого не вистачає, - це переміщення восьми байтів результатів до рядка кешу. Операція, що промиває рядок кеша, автоматично чекає, поки ділення закінчиться. Операція зчитування [i], ймовірно, буде перенаправлена, щоб отримати результат прямо з дільника.

Однією з можливих оптимізацій було б, щоб кеш порівнював вміст запису та попередній вміст кешу, і якщо вони однакові, не позначайте рядок як брудний

Невже така оптимізація не збільшиться вдвічі, ніж потрібно, щоб процесор щось записав у кеш? Оскільки кожне записування рядка кеша тепер буде супроводжуватися операцією порівняння, яка не є безкоштовною.

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