TL: DR: нет, аппаратное обеспечение ЦП уже оптимизировано для хранения одного ядра, загрузки другого ядра. Там нет волшебного высокопроизводительного метода с низкой задержкой, который вы можете использовать вместо этого. Если сторона записи может каким-либо образом форсировать обратную запись в L3, это может уменьшить задержку для стороны чтения, но, к сожалению, нет хорошего способа сделать это (кроме Tremont Atom, см. Ниже).
Общий кэш последнего уровня уже поддерживает трафик когерентности, избегая записи / повторного чтения в DRAM.
Не дайте себя одурачить диаграммами MESI;в них показаны одноуровневые кэши без общего кэша.
В реальных процессорах хранилищам из одного ядра требуется только обратная запись в кэш последнего уровня (LLC = L3 в современном x86) для загрузки из других ядер вполучить доступ к ним. L3 может содержать грязные линии;все современные процессоры x86 имеют L3 с обратной записью, а не сквозную запись.
В современной многосокетной системе каждый сокет имеет свои собственные контроллеры памяти (NUMA), поэтому отслеживание обнаруживает, когда должна произойти передача из кеша в кешчерез соединение между розетками. Но да, закрепление потоков на одном физическом ядре улучшает задержку между ядрами / потоками. (Аналогично для AMD Zen, где кластеры из 4 ядер имеют общую долю LLC, внутри / между кластерами имеет значение межъядерная задержка даже в пределах одного сокета, потому что нет одного большого LLC, совместно используемого всеми ядрами.)
Вы не можете сделать намного лучше, чем это;нагрузка на одно ядро сгенерирует запрос на совместное использование, как только он достигнет L3 и обнаружит, что строка модифицирована в частном L1d или L2 другого ядра. Вот почему задержка выше, чем попадание L3: запрос на загрузку должен получить L3, прежде чем он даже узнает, что это будет не просто попадание L3. Но Intel использует свои большие совместно используемые теги inclusiv L3 в качестве фильтра отслеживания, чтобы отслеживать, какое ядро на чипе могло его кэшировать. (Это изменилось в Skylake-Xeon; его L3 больше не является включающим, даже не включающим теги, и должен иметь некоторый отдельный фильтр snoop.)
См. Также Какой метод отображения кэша используется в ядре IntelПроцессор i7?
Интересный факт: на процессорах Core 2 трафик между ядрами действительно был таким же медленным, как DRAM в некоторых случаях
Ранние процессоры Core 2 Quad на самом деле были двумя двухъядерными кристаллами в одном пакете, и не не разделяли кэш последнего уровня. Это могло бы быть еще хуже;некоторые процессоры, подобные этому, не имели общего LLC и IDK, если бы логика «склеивания» могла даже выполнять кэш-> кэш-передачу грязных данных без обратной записи в DRAM.
Но эти дни давно прошли; Современные многоядерные и многоядерные процессоры оптимизированы для межъядерного трафика.
Вы не можете сделать ничего особенного всторона чтения, которая может сделать все быстрее.
Если у вас было cldemote на стороне записи, или другой способ вернуть данные обратно в L3, сторона чтения могла бы просто получить попадания L3. Но это доступно только в Tremont Atom
x86 MESI делает недействительной проблему задержки строки кэша - это еще один вопрос о попытке заставить сторону записи высвободить строки кэша обратно в L3,этот из-за конфликта пропускает.
clwb может работать для уменьшения задержки на стороне чтения, но недостатком является то, что заставляет выполнить обратную запись в DRAM.