Выход за пределы кэша второго уровня
Во-первых, не забывайте, что кэш второго уровня хранит не только код, но и данные. Как было показано в предыдущей главе, эффективная емкость кэша второго уровня не всегда совпадает с физической, – ведь исполняемый код и обрабатываемые данные могут претендовать на одни и те же кэш-линейки, в результате чего падение производительности начнется задолго до того, как алгебраическая сумма размеров интенсивно исполняемого кода и обрабатываемых им данных превысит размер кэша второго уровня.
Причем, падание производительности будет… нет, даже не обвальным, а по настоящему, без дураков, ошеломляющим – порядка тридцати (!) крат на AMD Athlon и шести –на P-III. Так никаких мегагерц процессора не хватит! Впрочем, с выходом исполняемого кода за границы кэша второго уровня приходится сталкиваться не так уж и часто, а если и приходится – практически всегда удается разбить его на несколько циклов меньшего размера, обрабатывающихся последовательно.
Таким образом, при разработке программы стремитесь проектировать ее так, чтобы все интенсивно используемые циклы вмещались в кэш первого или по крайней мере второго уровня.
Рисунок 22 graph 04 Изменение удельного времени выполнения команд в зависимости от размера исполняемого кода
