Как быстрее очистить большой кусок памяти? (C++) (7 стр)

entryway
> А зачем ты его использовал? Очевидно ведь, что обычного GetTickCount с головой.
> У меня не шалит точно. Проверил с GetTickCount - тоже самое.
GetTickCount() :
time of memset: 0.328 sec
time of memset_my: 0.313 sec
time of memset_sse2: 0.687 sec

Xunter
> time of memset: 0.328 sec
> time of memset_sse2: 0.687 sec
"Преимущество" sse не зависит от выбора таймера :)  Я ведь еще пять страниц назад сказал, что sse финты - это бабка надвое гадала. Как и всегда с расширенными инструкциями - надо быть очень осторожным. Безопасней всего использовать memset от умных пацанов типа Intel Compiler. Как минимум будешь застрахован от двукратного падения производительности.

entryway
дык, мне обещали "ускорения от 1.8 до 3.5 (если память мне не изменяет) раз" перед memcpy - вот, жду =)

Xunter
> дык, мне обещали "ускорения от 1.8 до 3.5
Ни у кого не осталось Пентиума4? Надо Тарасика попросить потестить. У него Компьютер 1.0 как раз. Приду домой, скомпилю ему интелом и майкрософтом.

Реальне. Теперь я сторонник intel compiler, если продолжу писать софтовый растеризатор =)
А как насчет автора? =)

У меня не 1.0
Селерон 600 - это Пень 3 (с кастрированным кешем).

Blew_zc
> Теперь я сторонник intel compiler, если продолжу писать софтовый растеризатор
У меня порт дума работает на 20%-30% быстрее (общий fps) если компилить интелом.

AMD 6000+

time of memset: 2.07463 sec
time of memset_my: 2.16058 sec
time of memset_sse2: 0.58867 sec

чёт как то совсем яро выходит

Был бы еще интеловский компилятор бесплатным, хотя бы для студентов... :/

Smouking
> time of memset: 2.07463 sec
и всё-таки меня терзают смутные сомнения, с результатами memset > 2 сек,
особенно когда асм код, который оптимизатор не трогает, обгоняет C2D @2.667 ..

flatz
> Был бы еще интеловский компилятор бесплатным, хотя бы для студентов... :/
Пишешь на msvc express, перед релизом скачиваешь триальный intel на месяц, компилишь, выкладываешь :)

entryway
Потом пишешь новый проект, переустанавливаешь винду, ставишь триальный ИЦЦ, компилируешь, выкладываешь.

Обнаружил такую особенность, если делать обычный memset два раза подряд, то второй вызов делается намного быстрее.
Причем для 64х бит результаты: ~6GB/s против ~2GB/s
для 32х бит — ~3.5GB/s против ~1.8GB/s

все оптимизации в настройках компиляторы включены (SSE, все дела) и одинаковы для 64 bit и 32 bit
вот тест: http://pastebin.com/qsunZiQ4

rAmpArk
> Обнаружил такую особенность, если делать обычный memset два раза подряд, то
> второй вызов делается намного быстрее

Это кеш так работает.

Мёртвый дельфин
Значит тесты на последних страницах темы некорректны? Они ведь мемсетят один и тот же кусок памяти?
Понятно что что-то кэшируется, но я пробовал делать на _mm_stream_si128 и наблюдал такие же результаты, хотя вот что про неё написано
> Stores the data in a to the address p without polluting the caches
Тогда что же кэшируется?

upd:
похоже что все дело в TLB. Например, если перед memset сделать нечто подобное:

    for (int i = 0; i < size/4096; i++) {
        *(dataPtr + i*4096) = 0;
    }

То сам memset выполнится максимально быстро.
Размер страницы (4096) зависит от процессора, например у меня уже при 8192 производительность падает в ~2 раза, т.е. появляется необходимость в загрузке page table

собственно вот цитата из пэйпера:
> The TLB is a fast memory buffer that is used to improve performance of the translation
> of a virtual memory address to a physical memory address by providing fast access to
> page table entries. If memory pages are accessed and the page table entry is not resident
> in the TLB, a TLB miss results and the page table must be read from memory. The TLB
> miss results in a performance degradation since memory access is slower than TLB access.
> The TLB can be pre-loaded with the page table entry for the next desired page by accessing (or touching) an address in that page.
> This is similar to prefetch, but instead of a data cache line the page table entry is being loaded in advance of its use. This will help
> to ensure that the page table entry is resident in the TLB. This is very important issue for
> prefetch instructions. If the page table entry is not resident in the TLB prefetch
> instructions are retired without successfully bringing data into the cache.

как я понял, в случае как у автора темы с этим не должно быть проблемы, т.к. он этот буфер активно использует и все page tablы загружены.