Одной строкой: mov[a|nt]ps

Сам интел пишет, что записи, ининциируемы movntps исользуют WC-протокол, т.е кешируются только во write-буферах процессора. Поскольку буферов единицы (максимум десятки) штук, записи, после заполнения имеющихся буферов, начинают выполнятся на скорости памяти. Буферы имеют размер строки кеша, так то срабатывает C (combining) и запись идет все-таки быстрее чем совсем медленная память, но медленнее, чем в кеш.

Могу поугадывать.

Если тестовым примером был код из http://blog.lexa.ru/2011/09/01/o_kompilyatorakh_i_protsessorakh.html, то хочу обратить внимание, что тут производится кешируемое чтение по тем же страницам, по которым идет WC-запись. Интел называет это неопределенным поведением и требует обязательно использовать как минимум store fence вокруг WC-записей.

Мое предположение состоит в том, что self-snoop на core i7 и старше замечает, что строка уже в кеше, а на старых Core2 нет.

Даже на терабайтных записях кеш помогает за счет более гибкого write coalescing. Писатели драйверов видеокарт давно знают, что линейная запись текстуры в основной памяти и ремап в апертуру в разы быстрее записи через WC-апертуру.

Я пробовал как то _mm_stream_ps на Core2Duo. Медленнее, чем обычный store. Тоже не понял, в чем же фокус.

MOVNTPS нужно использовать только для тех участков памяти, которые не читаются в кэш. Если данные в кэше, прироста в скорости он не даст

i7 по-моему сильно оптимизирован под потоки данных, то есть нельзя возвращаться к старым данным, нельзя писать туда, откуда читали, даже из IPP функции in-place интел обещает выкинуть - они не хотят поощрять дизайн, в котором данные пишутся обратно

Дизайн приложения должен быть устроен так, что данные читаются последовательно read-only, пишутся последовательно write-only в другое место, и кэш, как таковой, только сглаживает неровности, вроде отсутствия выравнивания (которое по сравнению с Core2/P4 более не критично)