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

看板C_and_CPP作者 (i386 cpu)時間11年前 (2014/04/10 23:18), 編輯推噓4(403)
留言7則, 4人參與, 最新討論串2/2 (看更多)
不同的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

04/10 23:45, , 1F
我看過的實作,如果沒 aligment 的話,會先把頭尾複製到
04/10 23:45, 1F

04/10 23:45, , 2F
aligment(用 char), 接著再用 int 做複制。
04/10 23:45, 2F

04/11 00:40, , 3F
to EdisonX:那也要 src 跟 dst 的 align 一樣才可以
04/11 00:40, 3F

04/11 00:40, , 4F
兩個 align 不一樣的話就還是會有一邊 unalign access
04/11 00:40, 4F

04/11 01:08, , 5F
也是, 忘了這點.
04/11 01:08, 5F

04/11 01:42, , 6F
有一些測試數據, 我放在在原原PO文章的推文中.
04/11 01:42, 6F

04/15 17:04, , 7F
這事的結論挺讓人訝異,在使用上不得不考慮有10倍差的可能性
04/15 17:04, 7F
文章代碼(AID): #1JHhP0tA (C_and_CPP)
文章代碼(AID): #1JHhP0tA (C_and_CPP)