Размер строки кэша
Это может быть очень распространенный и простой вопрос, но мне нужно некоторое объяснение кривой, которую я только что получил из кода тестов кеша. Цель здесь — найти размер строки кэша. Я использовал код отсюда:
(Ч ** пс: //github.com/jiewmeng/cs3210-assign1/blob/master/cache-l1-line.cpp)
Это кривая, которую я получил при запуске кода на моей машине (Macbook Pro с ядром i7 — размер строки кэша равен 64 байтам — кэш данных L1 равен 32 КБ).
Время против другой кривой размера шага
- Я думаю, что пик приходится на 128 байтов, а не на 64 байта. если это правда, я хочу знать, почему?
- Почему время сокращается на 512 байт?
Обновить:
Я также запустил код для определения размера кэшей L1 и L2. Вот рисунок только для документирования данных. Как вы можете видеть, есть два пика в 32 КБ (размер кэша L1) и 256 КБ (размер кэша L2).
Вопрос:
Мне интересно, есть ли способ найти размер общего кэша L3.
Спасибо
Решение
Мой тест BusSpeed был предназначен для определения размеров кэша и производительности на разных этапах, чтобы показать пакетное чтение на шинах:
http://www.roylongbottom.org.uk/busspd2k%20results.htm
Ниже приведены результаты на Core i7 с 8 МБ L3:
Memory Reg2 Reg2 Reg2 Reg2 Reg1 Reg2 Reg1 Reg2 Reg1 Reg8
KBytes Inc64 Inc32 Inc16 Inc8 Inc4 Inc4 Inc4 Inc4 Inc8 Inc8
Used MB/S MB/S MB/S MB/S MB/S MB/S MB/S MB/S MB/S MB/S
4 10025 10800 11262 11498 11612 11634 5850 11635 23093 23090
8 10807 11267 11505 11627 11694 11694 5871 11694 23299 23297
16 11251 11488 11620 11614 11712 11719 5873 11718 23391 23398
32 9893 9853 10890 11170 11558 11492 5872 11466 21032 21025
64 3219 4620 7289 9479 10805 10805 5875 10797 14426 14426
128 3213 4805 7305 9467 10811 10810 5875 10805 14442 14408
256 3144 4592 7231 9445 10759 10733 5870 10743 14336 14337
512 2005 3497 5980 9056 10466 10467 5871 10441 13906 13905
1024 2003 3482 5974 9017 10468 10466 5874 10467 13896 13818
2048 2004 3497 5958 9088 10447 10448 5870 10447 13857 13857
4096 1963 3398 5778 8870 10328 10328 5851 10328 13591 13630
8192 1729 3045 5322 8270 9977 9963 5728 9965 12923 12892
16384 692 1402 2495 4593 7811 7782 5406 7848 8335 8337
32768 695 1406 2492 4584 7820 7826 5401 7792 8317 8322
65536 695 1414 2488 4584 7823 7826 5403 7800 8321 8321
131072 696 1402 2491 4575 7827 7824 5411 7846 8322 8323
262144 696 1413 2498 4594 7791 7826 5409 7829 8333 8334
524288 693 1416 2498 4595 7841 7842 5411 7847 8319 8285
1048576 704 1415 2478 4591 7845 7840 5410 7853 8290 8283
End of test Fri Jul 30 16:44:29 2010
CPUID and RDTSC Assembly Code
CPU GenuineIntel, Features Code BFEBFBFF, Model Code 000106A5
Intel(R) Core(TM) i7 CPU 930 @ 2.80GHz Measured 2807 MHz
Другие решения
Я предполагаю, что пик 128B наиболее вероятен из-за пространственной предварительной выборки. Вы можете увидеть в Intels Руководство по оптимизации, в соответствии с разделом 2.1.5.4
Этот предварительный сборщик стремится завершить каждую строку кэша, извлеченную в кэш L2, парной строкой, которая завершает его до 128-байтового выровненного фрагмента.
Это не был бы чистый прыжок, так как эта предварительная выборка не всегда срабатывает, и даже когда она делает это, она выполняет только предварительную загрузку в L2, но это намного лучше, чем загрузка из памяти. Чтобы убедиться, что это так, вы можете отключить предварительные выборки (через BIOS или другие средства, хотя некоторые системы могут не поддерживать это) и проверить еще раз.
Что касается размера L3 — вы не указали свою точную модель, но я предполагаю, что у вас больше 4M L3 — просто продолжайте кривую и посмотрите, не скачет ли она.
РЕДАКТИРОВАТЬ
Просто заметил еще одну вещь — ваше выражение k * i, вероятно, переполняется int в максимальном диапазоне, что означает, что ваш шаблон доступа может быть не цикличным, как вы ожидаете.