Свежие комментарии

мммм...
оно, кажется, ни фига не "ПОСИКС", но тем не менее, насколько помню, можно запросить аллокацию с "коммитом", т.е. уже помэпленный кусок.
может, кстати, и даст прирост в производительности.

Меньше чем ожидал, но вот скорости кэшей
2-мегабайтный working set - ~20Gb/sec
80к - 28Gb/sec
все на одном ядре.
В несколько потоков параллелить бессмысленно, слишком они мелкие получаются.

Естественно, movaps а не non-temporal

Але, мы кажется запись обсуждали, причем тут prefetch?

а ты отключи, и вопросы отпадут сами собой :-))

кстати, коль уж кэш не при чём, то каким образом "если проинитить странички заранее, а не писать в только что выделенные, то скорость записи становится ближе к ожидаемой" ?
сам-то как думаешь ? :-))

тогда уж цитируй дальше: "They are delayed in an internal buffer ... If software cares about data being delayed developers
must deliberately empty the WC buffers"
т.е. операция записи асинхронная.
это, знаешь ли, в свою очередь ну ни фига не typical sense of the memory writing ,-)

да, кстати, таки ты выполняется ли у тебя по коду "deliberately empty the WC buffers" ? ...а ты попробуй ,-)

Он не увидит этого, это из ЖЖ приехало
(http://alextutubalin.livejournal.com/218527.html#comments)

Интел пишет нам
"Writes to the WC memory type are not cached in the typical sense of the word cached"

Чем какбэ намекает нам, что у тебя sense какой-то не typical....

Зачем мне его отключать то? Я щупаю реальный перформанс на реальном таком полуторагигабайтном (уже) working set

Лёша, ты три тезиса связать сумеешь ?
вот они:
*: Move packed single-precision floating-point values from xmm to m128 using non-temporal hint.
*: The non-temporal hint is implemented by using a write combining (WC) memory type protocol when writing the data to memory.
*: Write-combining is a limited caching optimization (more often used for RAM on devices such as graphics cards.)

так понятней ? ,-)

// ну и про прочие prefetch & write back тоже не забываем, ага

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

Какой профайлер используете? VTune?

Концепция отличная и, по всей видимости, для интересных мне приложений (с картинками) будет сильно производительнее на каком-то современном железе.

Но. с этими _mm_... - я в профайлере смотрю на хотспоты и, при условии подходящей организации памяти, пишу буквально десяток инструкций. Или сто.

А с OpenCL/CUDA - нужно довольно большие куски переписывать. Более объемная задача.

Вот кстати gpu в этом плане более православные..
Вот на CPU возможно идёт некий счётный процесс, который грузит все ядра, причём кэши и регистры у него забиты впритык (например тот же gemm), мало того что из-за вклинивания всяких системных и не очень процессов регистры могут тасоваться туда-сюда, так и ещё какая-нибудь сволочь может взять да и сбросить/сожрать весь кэш.. (можно конечно отдавать ядра отдельным процессам, но всё же дёготь есть)
То есть я к тому, что концепция обособленного вычислятора(будь то gpu или larabee), достаточно не плоха. А самое главное - программисты всегда будут сыты ;)

Агабля!

Второй проход той же инициализациями (но другими значениями, чтобы было видно что работает) - 12.3Gb/sec в один поток и 16.7 - во всю дурь.

Во, теперь похоже на правду совсем.

что-то маловато.. я думал если захотеть, то на core i7 можно достичь больше 20GiB/s на чтение и запись..

Может там кто-то по рукам кнутом бьёт?
Например можно попробовать два раза тест прогнать, замеряя только время второго (может calloc, но лучше всё таки один разу "вручную" заполнить).. Может там такой оверхед от ОСи - например windows реально выделяет память только под реально используемые страницы, или ещё какой кнут..