Как стать автором
Обновить

Комментарии 31

Так чем, в итоге, это объясняется? Что мешает процессору оставить кэшлайн в L1/L2?
Тем, что L3 (LLC) в текущих реализациях Core i7 — fully inclusive of L1 and L2. То есть если линия вытеснена из LLC, LLC автоматически посылает сигнал об изменении статуса этих данных на Invalid в нижележащие кэши.

Для сравнения, если по какой-то причине линия пропадает из L2, в L1 она все еще может оставаться.
О, вот это интересно — т.е. уже не полностью inclusive? Есть исключения?
Да, описано в SW Optimization guide (#248966, 2.3.4). L2 не обязательно включает весь L1, но L3 включает L1 I&D и L2.
А там описано почему выбрана именно такая политика? (Страшновато за него браться)
Нет, не описано. Но можно нагуглить несколько релевантных академических статей, в том числе опубликованых архитекторами Intel по запросу «L1 L2 LLC inclusive».

Обычно архитекторы просто прогоняют на модели нового дизайна огромный синтетический бенчмарк и пытаются выбрать вариант политики с лучшей производительности и наименьшим расходом энергии.
Насколько мне известно, у современных процессоров Intel кэш строго инклюзивный, т.е. если данные есть в кэше меньшего уровня, то гарантируется, что они также есть на последующих уровнях.
Я думаю, что с эксклюзивным кэшем AMD все не так печально. Но, к сожалению, под рукой нет компьютера с АМД, чтобы проверить.
Извините за прямолинейность, но я не увидел в статье явного ответа на вопрос в заголовке «Действительно ли у каждого ядра есть «свой собственный» кэш первого и второго уровней?».
В двух словах — они есть, но не совсем «свои собственные». То есть есть вероятность, что ядра в некоторых условиях могут вытеснять чужые данные из чужих L1, L2 кэшей.
действительно, информация лежит на поверхности, и если вдуматься, то разделяемый LLC может позволить одному ядру обнулить L1/L2 другому.
отличный пост! спасибо.
Это скорее подробное разжевывание тезиса о том, что LLC — inclusive. Что описано в документации. Несмотря на это, мне часто приходится объяснять это клиентам, которые ссылаются на первую диаграмму: «вот у вас же в powerpoint нарисовано, что у каждого ядра есть свой кэш. Куда же из него подевались наши данные, почему кэш миссы?».
Саша, ты лучше скажи мне другое. Левенталь говорил, что похожим образом легко сделать eviction для L1 instruction. Но наскоком у меня такой тест не вышел. Сделаешь? ;)
Мне кастомер жаловался, что у него это происходит. Как раз собирался воспроизводить. На след. неделе попробую, если получится напишу тебе.
Спасибо. Я не совсем понял про изменение данных. Если ядро меняет данные, то данные сразу меняются в LLC и становятся автоматически видны всем остальным ядрам? Разве ядро не должно менять данные в L1/L2? Если так то каким образом изменения данных сбрасываются из L1/L2 в LLC?
Cache coherency, и что происходит при записи в L1 в статье я не рассматривал. 2 потока из теста работают над непересекающимися областями данных, которые, однако, конкурируют за место в LLC. Единственный элемент, в который пишут оба потока — спинлок.

В статье Хеннеси, на которую я сослался в тексте, есть инфа, что происходит при L1 hit on store.

Немного оффтоп:
Ребята, подскажите чего бы почитать на эту тему для newbie?
Статья безумно интересная, но я и половины не понимаю. Спасибо
Computer Organization and Design;
Computer Architecture: A Quantitative Approach
Обе книги написаны Хеннеси(которого я уже упоминал) и Паттерсоном.

Я не сказал бы, что они для newbie, но с другой стороны, они (особенно первая) не требует каких-то prerequisites.
Спасибо, буду изучать
Серьёзный подход. Проникся. Интересно. Спасибо.
Что-то мне подсказывает, что этот пост связан с новой возможностью «L3 Cache QoS», о которой вы могли бы рассказать.
А где вы слышали о «новой возможности «L3 Cache QoS» »??
Вот здесь, страница 3-154. CPUID leaf 0xF (ecx = 0):
EDX Bit 01: Supports L3 Cache QoS if 1.
Очень интересно! В официальном документе упомянули фичу, но ничего не написали о том, как ее использовать. Если внимательнее почитать, там же можно найти более подробную ссылку на CQoS monitoring. Вы, очевидно, ссылаетесь на CQoS control. Если бы такая фича существовала и была публична, я бы с радостью запостил статью на публичном ресурсе — Хабре.
Никто не обидится, если я не в свою песочницу залезу?
Вот если я обычный обыватель и купил себе десктоп на LGA2011 и 3960X — 6 ядер, 4 канала памяти, полный фарш во всем остальном, и даше хакинтош было дело попробовал — Mac OS встал как родной, чувствую себя уверенно, весь такой, а тут эта статья… Я правильно понимаю, что это всё может быть сильно обесценено единственным «грамотным» индусским драйвером устройства под виндой?
Второй вопрос это офф-топик, но вытекает из первого — я уже устал себя чувствовать уверенно на 2011 и 39хх — линейка совершенно не обновляется.
Прошло уже полтора «тик-така» по процессу с того времени как купил, но в топовом сегменте десктопов ничего не изменилось.
А у меня же подруги тупые — они не понимают что этот комп до сих пор «самый крутой процессор». Для них этот комп уже такой-же старый, как дата моего рождения в паспорте. Скоро мне вообще никто не даст! О_о
[irony kaput]
А если серьезно, есть какие-то доступные средства мониторинга такой оказии кэша из-за ПО третьих лиц? Может какой-то статистический анализ, выявляющий статистически значимые выбросы при работе определенного ПО или драйвера?
И что с перспективой LGA2011?
Заранее прошу прощения от низкоуровневых гуру, если я чего-то очевидного не знаю, я уже много лет в прикладном ПО, а в этом блоге спасаюсь от минерализации своего мозга в углерод к компании окаменелостоей динозавров. (и не хочу через миллион лет стать процесором телефона у продавца в Макдональдсе)
На десктопных нагрузках вы вряд-ли заметите этот эффект.
1. Речь идет о микросекундах.
2. У десктопных нагрузок сложнее проявить этот эффект, так как у них есть spatial locality, и так как менее приоритетным задачам дается меньше времени на CPU, следовательно, у них меньше возможности вытеснить чужие данные.
3. Измерять можно при помощи Intel Vtune, но учитывая пункты 1,2 — просто незачем.

По поводу вашего вопроса о современном железе, я не знаю ответа, т.к. не интересуюсь десктопным железом. Может быть, мои коллеги ответят.
Знаете, обидно было прочитать, что я десктоп пользователь, и поэтому выходит человек второго сорта.
У вас мог бы возникнуть вопрос, нафиг мне 2011 с топовым Зеоном на борту понадобился, но вы этот вопрос не задали, но сразу отнесли меня к людям второго сорта, которыми можно пренебречь с их ничтожными «десктопами».
Это официальная политика Интел сейчас, пренебрегать десктопами, на которые люди потратили десятки тысяч рублей ради топовых показателей, потому-что не имеют возможности покупать часы на суперкомпьютерах? Мои микросекунды менее нужны чем элите? Меня похоже в мягкой форме послали на#ер.
Это официальная политика Intel сейчас?
Я, к сожалению, не имею права выражать официальную позицию Интел.

Моя должность — инженер в технической поддержке, и я работаю только с embedded клиентами. Поэтому embedded продукты я знаю хорошо, а вот десктопные и серверные — плохо. Так что ваш компьютер для меня — недостижимый хай энд. Поэтому и задал вопрос в конце, вдруг коллеги помогут, если читают пост.

Лет 10 назад, я тоже следил за десктопными компьютерами, но как-то перегорел. Теперь слежу только за тем, что нужно по работе — за микроархитектурой и за платформами своего сегмента.

По поводу микросекунд. Архитектура Интел всегда в первую очередь оптимизировалась под максимальную throughput производительность. В задачах, где важно время отклика (промышленность, алгоритмический трейдинг), часто требуется отдельная работа с софтом для выгадывания микросекунд. Так как человек — система не очень быстро реагирующая, десктопные нагрузки никто не оптимизирует в области микросекунд. Обычно речь идет о десятках миллисекунд.
Я вас немного потроллил конечно ))
На самом деле мой софт лишь составляет тональную карту звуковых треков — задача недостойная суперкомпьютеров по важности, но числомолотилка серьезная, сильно упирается в количество ядер (тут я надеюсь как кодер не налажал), и в кеширование проца. Методом «тыка» подбираю размер обрабатываемых блоков и количество потоков, вот и влез в этот топик.
То что я делаю, это конечно неправильно, и это переоптимизация под конкретную конфигурацию компа, я знаю.
Но других десктопных Зеонов кроме 39хх я не знаю, раньше были Mac Pro, но похоже Apple похоронила эту линейку. В связи с чем и возник вопрос про 2011, ходят слухи, — был ли это неудачный проект для Mac Pro, и после отказа Apple были просто распроданы запасы, и теперь это тупиковая ветка и бесперспективный сокет?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий