Pull to refresh

Comments 16

А можно было как-то все 4 части растянуть во времени?
И разбавить картинками а то читается тяжело…
бляха муха. это техническая статья на специализированном ресурсе для программистов и сисадминов, или я на форуме журнала Cosmo нахожусь?


(на картинке дональд кнут работает над выпуском еженедельника «искусство программирования в комиксах»)
даже одна простая картинка (любая иллюстрация) очень сильно разбавляет текст и его становится читать легче. Давайте вообще все картинки из всех статей уберём. Зачем они нам, ага?
Есть перевод еще вот такой статьи того же автора: assets.devx.com/goparallel/18027.pdf
Там и картинок, и таблиц и листингов больше. Однако материал от этого сильно понятнее не становится, а учитывая как активно эту статью минусовали, даже не знаю, стоит ли выкладывать…
Увы, картинок нет в оригинале…
Я попробую написать дополнительно вступление для тех, кто не знаком с принципами работы кэша данных. Надеюсь, это будет полезно и интересно для некоторых читателей и прояснит некоторые моменты настоящей статьи.

Тезисно:

1) |L1| < |L2| < |L3|. В процессоре обычно несколько уровней кэша, причём они разные по объему.
2) В кэше хранится адрес последовательной четверки (но не обязательно четвёрки) данных, 4 64-ёх битных данных, служебные биты валидности, обратной записи и блокировки, а так же биты чётности.
3) При load из ОЗУ процессор сначала проверяет, есть ли затребованные данные в кэше. Сначала смотрит в L1, если нету, смотрит в L2, если нету, смотрит в L3. Ситуация отсутствия данных называется промахом, противоположная ситуация называется попаданием.
3а) Если происходит попадание в кэш, обращение в ОЗУ не производится. Если происходит промах в L1, L2, но попадание в L3 — содержимое из L3 копируется в L1 и L2.
3б) Если происходит промах, то данные берутся из ОЗУ и параллельно помещаются в L1,L2,L3.
4) При store в ОЗУ, аналогично, процессор ищет их в кэше. Если находит, записывает туда, причём в ОЗУ остаётся старое значение! Так же происходит при необходимости обновление других кэшей.
5) Если ячейка кэша перезаписывается данными с другим адресом, то старые данные вытесняются: из L1 в L2, из L2 в L3, из L3 — в ОЗУ.
6) Некоторые кэши являются n-мерными. Это означает, что в одну строку могут быть записаны n различных адресов, а когда приходит (n+1) адрес, вытесняется самый неиспользуемый (впрочем, алгоритмы вытеснения бывают разными).
7) Данные в кэш можно предварительно подтянуть ассемблерной инструкцией, напрямую не используя их. Таким образом можно достичь оптимизации — один поток работает с данными в первой половине кеша (условно), другой в это время подтягивает их во вторую. Потом наоборот.

P.S. Для разных архитектур некоторые пункты могут не соответствовать действительности, но в целом общий принцип такой, как я описал.
4 а) используется два метода store: write-trough и write-back. Write-trough записывает информацию как в cache так и наприамую в ОЗУ.
Write-back записывает информацию после вытеснения информации из cache.
Да, верно. Оно в свою очередь подразделяется на with/without write allocate.
Много вариантов политики кэширования существует, всех не упомянешь…
а если несколько процессоров и у каждого свой кеш а память одна, тогда кеш может не соответствовать действительности.
Если алгоритм написан плохо, тогда да. Возможно что тогда выигрывает последная запись с кеш в ОЗУ.
Но, если алгоритм написан верно, так он может увеличить производительность более чем в 2 раза с использованием кеш на двух процессорах.
Не только процессоров, но и ядер.
Это широко известная проблема когерентности кеша.
Решается на практике на уровне железа штуками типа протокола MESI.
Хороший перевод классической статьи.

Т.к статья классическая, то она вся актуальна, кроме того, что касается FSB, которая на современных процессорах Intel давно не мешает масштабируемости, по очевидным причинам.

Поэтому часть об евентах типа BUS_DRDY_CLOCKS уже можно рассматривать с исторической точки зрения.
Пока еще рано с исторической, ибо Core 2 есть еще у многих, а про промышленные варианты вообще можете забыть про быстрый апгрейд — пару сотен серверов поменять только потому что вышел камень поновее…
Конечно, сравнительно недавно выпущенные процессоры никто не выкинет. Хотя знаю одну компанию, выбрасывающую на вторичный рынок порядка 10000 Xeon EP камней, именно потому, что выходит камень поновее.

С конца 2008 года примерно не пользовался BUS_DRDY_CLOCKS на Xeon'ах, при том, что Vtune использую на работе практически ежедневно. Клиенты, которых настолько волнует производительность, чтобы заботиться о микроархитектурных евентах, сначала апгрейдятся, а потом уже сами или с помощью консультанта типа меня начинают профайлиться.
Ох, так вы из Интел. Afair, наша компания хотела позвать консультанта вроде вас, но с кризисом не срослось. Приходиться изучать тему своими силами :).
Sign up to leave a comment.

Articles