Скорость разбросанной записи по сравнению со скоростью разбросанного чтения на современных процессорах Intel или AMD?

Я думаю об оптимизации программы, взяв линейный массив и записав каждый элемент в произвольное место (случайное с точки зрения ЦП) в другом массиве. Я делаю только простые записи и не читаю элементы обратно.

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

К сожалению, я не знаком со всеми деталями классической архитектуры памяти ЦП, и поэтому могут быть некоторые сложности, которые могут привести к тому, что это также будет довольно медленным.

Кто-нибудь пробовал это?

(Должен сказать, что я пытаюсь инвертировать проблему, которая у меня есть. В настоящее время у меня есть линейный массив, из которого я считываю произвольные значения — разрозненное чтение — и это невероятно медленно из-за всех промахов кеша. Мои мысли что я могу преобразовать эту операцию в разрозненную запись для значительного выигрыша в скорости.)


person bhouston    schedule 23.06.2010    source источник
comment
Я был бы удивлен, если бы разрозненные записи были быстрее, но, как всегда, вы должны тестировать и измерять.   -  person Peter Ruderman    schedule 23.06.2010


Ответы (2)


Как правило, вы платите большие штрафы за разбросанные записи по адресам, которые еще не находятся в кеше, поскольку вам приходится загружать и хранить целую строку кеша для каждой записи, следовательно, требования к пропускной способности FSB и DRAM будут намного выше, чем для последовательных записей. И, конечно же, вы будете сталкиваться с промахом кеша при каждой записи (обычно это пара сотен циклов на современных процессорах), и вам не поможет никакой автоматический механизм предварительной выборки.

person Paul R    schedule 23.06.2010
comment
Как вы думаете, помогут ли инструкции SSE для кеша, особенно _mm_stream_ps в случае данных с плавающей запятой? В документации MSDN указано, что эта инструкция сохраняет данные в a по адресу p, не загрязняя кеши. msdn.microsoft.com/en-us/library /78x83000(v=VS.80).aspx - person bhouston; 23.06.2010
comment
Вот ответ на вопрос _mm_stream_ps, который я только что задал: gamedev.net/community/forums/ - person bhouston; 23.06.2010
comment
Вы можете немного подкорректировать, но, вероятно, было бы лучше вложить эти усилия в реструктуризацию вашего алгоритма, чтобы он писал последовательно (или, по крайней мере, с разумной локальностью), если это вообще возможно. . - person Paul R; 23.06.2010

Должен признать, это звучит как-то хардкорно. Но я рискну и все же отвечу.

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

person GvS    schedule 23.06.2010
comment
Да, это звучит выполнимо. Я мог бы разделить его на поддиапазоны и читать данные только в этом диапазоне. Какой размер страницы вы бы порекомендовали? И мои входные, и выходные наборы дат имеют размер 10 МБ. Возможно, лучше всего разделить ввод и вывод на страницы - таким образом, у меня будет N разделов с M проходами каждый. Я мог бы выполнять каждый из проходов по нескольким ядрам одновременно. - person bhouston; 23.06.2010