В кэше L1, L2 и DRAM последовательный доступ быстрее случайного доступа из-за возможности установить опережающее чтение? Я знаю, что в HDD это, конечно, быстрее на порядки.
решение1
ДА, некоторые одинаковые, но не совсем одинаковые.
Согласно мануалу к процессору :-)
http://www.intel.com/content/dam/doc/manual/64-ia-32-architectures-optimization-manual.pdf
Есть конкретная аппаратная предварительная выборка, и программист может указать ей на предварительную выборку, плюс есть способы, которыми она работает с размером фрагмента данных, из которых знающий программист может получить преимущества. Кроме того, те же самые аппаратные или программные методы, выполненные немного неправильно, могут привести к тому, что предварительная выборка будет отброшена, снова и снова, плюс такие вещи различаются для разных процессоров.
Перемещение данных на более высокие уровни, предполагая, что они понадобятся (например, опережающее чтение), и данные находятся там, потому что они находятся в пределах размера фрагмента, который они перемещают на эти уровни (последовательное выполнение может помочь).
Процессор, зная, какой набор инструкций он там записал, или список того, что он собирается сделать, подготавливает эти данные.
2.1.5.4 Предварительная выборка данных Данные могут быть предварительно загружены в кэш-память L1 DCache с использованием программной предварительной выборки, аппаратной предварительной выборки или любой их комбинации. . . .
--
Streamer: Этот предварительный выборщик отслеживает запросы на чтение из кэша L1 для восходящих и нисходящих последовательностей адресов. Отслеживаемые запросы на чтение включают запросы L1 DCache, инициированные операциями загрузки и сохранения и аппаратными предварительными выборщиками, а также запросы L1 ICache для выборки кода. При обнаружении прямого или обратного потока запросов ожидаемые строки кэша предварительно выбираются. Предварительно выбранные строки кэша должны находиться на той же странице 4K. . . .
--
Wide Dynamic Execution
Smart Memory Access - prefetches data
Branch Prediction Unit
Instruction Fetch Unit
Instruction PreDecode
Список можно продолжать и продолжать, ведь многие функции нацелены на будущее.
Начните со страницы 60 указанного документа.
https://stackoverflow.com/questions/1922249/c-cache-aware-programming Больше ссылок на PDF-файлы можно найти на Stack Overflow, и я уверен, что там гораздо больше информации по этому поводу.
Данные об этом и технике слишком длинные, чтобы публиковать их здесь, и все "как это работает на самом деле" от программистов тоже были бы слишком длинными. Мало того, что я едва понимаю это. После прочтения этого (и информации о программистах) неудивительно, почему одна часть программного обеспечения, делающая почти то же самое, может быть в 50 раз быстрее другой, все можно было бы тщательно сделать, протестировать и перепроверить, чтобы получить максимальную оптимизацию, или они могли бы упустить несколько вещей и быть нормальными.
&НЕТ, RAM — это полностью произвольный доступ, есть только крошечные величины задержки, это «RAM», который жесткий диск использует для выполнения действий опережающего чтения, и пакетной передачи во много раз быстрее, чем может быть прочитано с пластин. Последовательность чрезвычайно важна для жестких дисков, потому что движение головки занимает время и не извлекает данные с пластины тогда. После того, как головка прибывает на место, она должна ждать, пока данные не появятся во вращении.
С опережающим чтением жесткого диска он может извлекать данные на том же вращении, экономя много миллисекунд времени.
Было бы большой натяжкой :-) предположить, что между ними есть что-то похожее.