Re: [請益] C語言memcpy()的效率問題

[i386 (i386 cpu)]

不同的CPU架構, 指令集, OS, Compiler和memcpy function都會影響
效率.

不確定你用的C library裡面的memcpy是怎麼寫的, 單就你結論提到
差距10倍的效率(65536->65535)來推斷,最有可能的原因出在alignment
上面..

以下用32bit CPU架構來舉例.
如果source和destination在memory中的aligment的位址是對齊4bytes
memcpy會選擇用int的單位(32bits)來搬data

如果source和destination在memory中的aligment的位址無法aligment的話,
那memcpy會選擇用char(8bits)單位來搬data

這樣兩者的差別,就有可能會讓效率差10倍, 當然這還是要看memcpy裡面怎麼寫的

就你程式中的source和destination都宣告為local variable, 也就是在stack
裡面, 你可以自己先確認看看這兩個array在記憶體中的位址. 當然你也可以做
個實驗, dst和src在不同的memory aligment下面, 會有怎樣的差異.

另外, 你文中提到的.
: 後來改在linux上測(也是沒有最佳化選項)
: 改變size(65536->65535),時間沒有差異
這個一定會有差異,只是你量測的時間單位無法看出差異而已, 因為就這
兩個size來看, 65535一定要處理3個byte非aligment的部份.




※ 引述《kkkmode (kkk)》之銘言：
: ※ [本文轉錄自 Soft_Job 看板 #1JHAVIT- ]
: 作者: kkkmode (kkk) 看板: Soft_Job
: 標題: [請益] C語言memcpy()的效率問題
: 時間: Wed Apr  9 09:52:15 2014
: 各位好,
: 我測試了一段程式,如下:
: #include <stdio.h>
: #define size 65536
: void main(){
:   char source[size], destination[size];
:   int j;
:   for(j=0; j<100000; j++)
:     memcpy(destination, source, size);
: }
: 把size改成65535或65537執行速度大概會慢10倍(compiler沒設最佳化)
: 其他2的冪次方加減1也有此現象(例如1024改成1023或1025)
: 我覺得可能是cache沒命中造成的
: 但詳細的原因不是很清楚
: 如果各位知道原因的話請幫忙一下,謝謝
: ******************************************************************
: 補上編譯環境:
: IDE: code::blocks 13.12
: compiler套件:  TDM-GCC, v4.7.1, 32 bit
: 作業系統: windows 8.1 64 bit
: CPU: intel core-i3 2100
: 後來改在linux上測(也是沒有最佳化選項)
: 改變size(65536->65535),時間沒有差異
: objdump也試過,我是輸入以下兩行指令:
:   gcc -Wall -O0 -g main.c -o main.exe
:   objdump -Sl --no-show-raw-insn main.exe > output.txt
: 但組語不熟且非常多行
: 看起來和亂碼一樣,所以投降了...

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 220.137.68.34
※ 文章網址: http://www.ptt.cc/bbs/C_and_CPP/M.1397143104.A.DCA.html
推 EdisonX:我看過的實作，如果沒 aligment 的話，會先把頭尾複製到
→ EdisonX:aligment(用 char), 接著再用 int 做複制。
→ akasan:to EdisonX:那也要 src 跟 dst 的 align 一樣才可以
→ akasan:兩個 align 不一樣的話就還是會有一邊 unalign access
推 EdisonX:也是, 忘了這點.
推 yvb:有一些測試數據, 我放在在原原PO文章的推文中.
推 dirkc:這事的結論挺讓人訝異,在使用上不得不考慮有10倍差的可能性