... <看更多>
「memcpy c」的推薦目錄:
- 關於memcpy c 在 Re: [請益] C語言memcpy()的效率問題- 看板C_and_CPP 的評價
- 關於memcpy c 在 Is copying 2D arrays with "memcpy" technically undefined ... 的評價
- 關於memcpy c 在 glibc/memcpy.c at master · lattera/glibc - GitHub 的評價
- 關於memcpy c 在 C Programming Tutorial 64, Memory Functions pt.2 memcpy 的評價
- 關於memcpy c 在 PCMan - 分享有趣C 語言小常識: 1. 為什麼memcpy() 多了 ... 的評價
memcpy c 在 glibc/memcpy.c at master · lattera/glibc - GitHub 的推薦與評價
glibc/string/memcpy.c ... The GNU C Library is free software; you can redistribute it and/or ... memcpy (void *dstpp, const void *srcpp, size_t len). ... <看更多>
memcpy c 在 PCMan - 分享有趣C 語言小常識: 1. 為什麼memcpy() 多了 ... 的推薦與評價
分享有趣C 語言小常識: 1. 為什麼memcpy() 多了一個function call overhead,有時候還是比自己用迴圈copy 資料快? 2. 什麼情況下不能用memcpy() 來在 ... ... <看更多>
memcpy c 在 Re: [請益] C語言memcpy()的效率問題- 看板C_and_CPP 的推薦與評價
不同的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
※ 文章網址: https://www.ptt.cc/bbs/C_and_CPP/M.1397143104.A.DCA.html
... <看更多>