作者查詢 / yvb

總覽項目：發文 | 留言 | 暱稱

作者 yvb 在 PTT [ C_and_CPP ] 看板的留言(推文), 共847則

限定看板：C_and_CPP

看板排序：

首頁

尾頁

[問題] C++ 亂數產生

[ C_and_CPP ]28 留言, 推噓總分: +7

作者: yangmeme - 發表於 2014/04/23 20:09(12年前)

21^F推yvb:基本上 Dev-C++ 用了 MinGW, 就是用 MS-Windows 的 C-Runtime04/25 00:22

22^F→yvb:DLLs,其中主要就是 MSVCRT.DLL (Microsoft C runtime library)04/25 00:24

23^F→yvb:而MSVC的 rand() 實作大概就是04/25 00:24

24^F→yvb: seed=seed*0x343fd+0x269EC3; return (seed>>0x10)&0x7FFF;04/25 00:25

25^F→yvb:因為 return 時做了 right-shift, 而 seed 的乘數不夠大,04/25 00:29

26^F→yvb:所以造成srand()用相近的seed,第一次rand()會得到相近的值.04/25 00:31

[問題] 中央堆疊記憶體配置與釋放

[ C_and_CPP ]25 留言, 推噓總分: +3

作者: Sunofgod - 發表於 2014/04/17 12:34(12年前)

17^F推yvb:去編譯器選項, 開個最佳化, 再試試看執行結果吧...04/17 13:38

18^F→yvb:至少我用 gcc 測試, 最佳化用 -O1 和 -O2, 答案都不是 10 1004/17 13:44

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

[ C_and_CPP ]7 留言, 推噓總分: +4

作者: i386 - 發表於 2014/04/10 23:18(12年前)

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

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

[ C_and_CPP ]50 留言, 推噓總分: +8

作者: kkkmode - 發表於 2014/04/09 11:10(12年前)

16^F推yvb:以glibc-2.19為例,x86的memcpy實作有i586(以下)及i686(以上),04/11 01:33

17^F→yvb:i686下還做了multiarch,除了原來的i686,另增SSSE3及SSSE3+REP,04/11 01:33

18^F→yvb:當做成shared library時,可在runtime時,才判斷用i686的哪一種,04/11 01:33

19^F→yvb:但若是編譯時用 static link, 則固定使用原來的i686實作.04/11 01:34

20^F→yvb:我將上述i586,i686,sssse3,ssse3+rep幾種實作各別獨立出來,04/11 01:34

21^F→yvb:在幾款CPU上執行原PO程式搭配不同size,得到下列執行時間:04/11 01:34

22^F→yvb: (CPU:E5410) (size:65535) (size:65536) (size:65537)04/11 01:34

23^F→yvb: i586 0m5.183s 0m1.488s 0m1.951s04/11 01:34

24^F→yvb: i686 0m8.779s 0m0.873s 0m4.951s04/11 01:35

25^F→yvb: ssse3 0m0.697s 0m0.671s 0m0.696s04/11 01:35

26^F→yvb: ssse3+rep 0m0.645s 0m0.873s 0m0.648s04/11 01:35

27^F→yvb: (CPU:i3-2130) (size:65535) (size:65536) (size:65537)04/11 01:35

28^F→yvb: i586 0m0.542s 0m0.519s 0m1.262s04/11 01:35

29^F→yvb: i686 0m0.539s 0m0.244s 0m0.679s04/11 01:35

30^F→yvb: ssse3 0m0.191s 0m0.319s 0m0.190s04/11 01:36

31^F→yvb: ssse3+rep 0m0.218s 0m0.203s 0m0.218s04/11 01:36

32^F→yvb: (CPU:i5-650) (size:65535) (size:65536) (size:65537)04/11 01:36

33^F→yvb: i586 0m0.837s 0m0.608s 0m0.640s04/11 01:36

34^F→yvb: i686 0m0.954s 0m0.222s 0m0.547s04/11 01:36

35^F→yvb: ssse3 0m0.208s 0m0.322s 0m0.208s04/11 01:36

36^F→yvb: ssse3+rep 0m0.211s 0m0.219s 0m0.211s04/11 01:36

37^F→yvb:在上述的E5410搭配i686實作,確實發生類似原PO所述的狀況;04/11 01:36

38^F→yvb:而稍早的glibc版本(ex:2.7),並無i686 multiarch的方式,04/11 01:37

39^F→yvb:且i586和i686的實作在進版時,也常有修改.04/11 01:37

40^F→yvb:怎樣的搭配,會發生原PO的情況,也許都需要實測才可得知吧.04/11 01:38

42^F推yvb:根據大家推測應該是 alignment 的問題, 我把原PO程式的04/11 02:12

43^F→yvb: char source[size], destination[size];04/11 02:12

44^F→yvb:修改為04/11 02:12

45^F→yvb: char data[65536*4];04/11 02:13

46^F→yvb: char *source=data, *destination=data+65536*2;04/11 02:13

47^F→yvb:重複同樣的測試, 結果時間大約都是 size:65536 那行時間04/11 02:13

48^F→yvb:正負 2% 之內. 所以我想 alignment 的推測相當合理;04/11 02:13

49^F→yvb:但有個疑問是, E5410搭ssse3+rep看來似乎很反常?04/11 02:13

50^F→yvb:回uid88, 我是因為不了解, 才用這樣的笨方法呀...04/11 02:15

[問題] process 之間傳遞資料

[ C_and_CPP ]21 留言, 推噓總分: +8

作者: redbxh - 發表於 2014/04/02 21:23(12年前)

8^F推yvb:樓上可以 google: codeblock wiki 和 devc wiki 了解一下.04/03 14:57

20^F推yvb:對不起, 我眼殘了, 請忽略我前面的推文.04/07 12:51

[問題] UVA 10290{Sum+=i++} to Reach N

[ C_and_CPP ]4 留言, 推噓總分: +2

作者: w22116972 - 發表於 2014/03/27 00:26(12年前)

2^F推yvb:樓上, 不支援的訊息, 只是 codepad.org 附加 ISO C++ 的限制,03/27 15:37

3^F→yvb:而非 UVa 的限制, 否則就是 CE 而非 WA 了.03/27 15:41

4^F推yvb:問題在於Line34的 i*i<MAX; 如果MAX=100,那i=11時就跳出了.03/27 15:44

Re: [問題] function的問題

[ C_and_CPP ]14 留言, 推噓總分: +5

作者: Move192 - 發表於 2014/03/25 17:57(12年前)

4^F推yvb:從組語來學 C/C++ , 這恐怕不是一般人做的事...03/25 22:08

Re: [問題] c++ 和 ++c 的差別在哪裡

[ C_and_CPP ]13 留言, 推噓總分: +9

作者: Move192 - 發表於 2014/03/25 08:44(12年前)

5^F推yvb:當程式有了上下文, 又開了最佳化, 是否還有差異就難說了.03/25 12:30

[問題] 請問string轉double精度問題

[ C_and_CPP ]7 留言, 推噓總分: +5

作者: everydate - 發表於 2014/03/24 23:16(12年前)

6^F推yvb:這 9.69999993 的數值似乎只有 float 的精度而非 double ??03/25 12:43

Re: [問題] fscanf讀txt檔大量數值錯誤問題

[ C_and_CPP ]18 留言, 推噓總分: +2

作者: dirkc - 發表於 2014/03/18 16:53(12年前)

1^F推yvb:若是64位元電腦,可能是發生資料錯亂,而不是堆積損毁程式掛掉;03/18 18:37

2^F→yvb:反而是32位元電腦搭上double,造成後面資料讀超出配置範圍掛掉.03/18 18:38

9^F推yvb:抱歉, 一時沒想清楚, 以為64位元搭配int只是指標指的範圍太小,03/19 12:44

10^F→yvb:在data內重疊, 可能重覆蓋寫資料, 造成資料錯亂而已; 沒考慮到03/19 12:45

11^F→yvb:讀取資料時, 會蓋寫到 data[i], 而可能讓 data[i] 指向錯誤;03/19 12:45

12^F→yvb:當然, 若運氣超好, 讀進 (&data[i]) 的資料值恰巧指向合法位址03/19 12:45

13^F→yvb:也可能純粹搞亂資料而已, 而未造成 segfault.03/19 12:46

14^F→yvb:相對32位元搭配double, 則是在設定 data[i] 指標時就超出範圍;03/19 12:46

15^F→yvb:但如果在讀入 data 前又額外配置記憶體, 也可能後續的讀取只是03/19 12:46

16^F→yvb:蓋寫後來配置區域的資料, 而不會發生 segfault.03/19 12:47

17^F→yvb:至於堆積損毁, 其實是原PO附圖中的詞, 也就是heap corruption,03/19 12:47

18^F→yvb:有幾種情況, 其中之一就是指標錯誤又去存取資料而發生的.03/19 12:48

首頁

尾頁