gpu 程式設計入門到精通（三）之 第乙個 gpu 程式 中講到了怎樣利用 cuda5.5 在 gpu 中執行乙個程式。通過程式的執行。我們看到了 gpu 確實能夠作為乙個運算器。可是，我們在前面的樣例中並沒有正真的發揮 gpu 並行處理程式的能力。也就是說之前的樣例僅僅利用了 gpu 的乙個執行緒，沒有發揮程式的並行性。
先來說說 cuda5.5 中 gpu 的架構。
它是由 grid 組成。每乙個 grid 又能夠由 block 組成，而每乙個 block 又能夠細分為 thread。所以，執行緒是我們處理的最小的單元了。
接下來的樣例通過改動前乙個樣例，把陣列切割成若干個組（每乙個組由乙個執行緒實現），每乙個組計算出乙個和，然後在 cpu 中將分組的這幾個和加在一起，得到終於的結果。這樣的思想叫做歸約。
事實上和分治思想幾乎相同，就是先將大規模問題分解為小規模的問題，最後這些小規模問題整合得到終於解。
因為我的 gpu 支援的塊內最大的執行緒數是 512 個，即cudagetdeviceproperties中的maxthreadsperblock屬性。
怎樣獲取這個屬性。請參看 gpu 程式設計入門到精通（二）之 執行第乙個程式 這一章節。
我們使用 512 個執行緒來實現並行加速。
好了，接下來就是敲**的時候了。
編譯後，執行結果例如以下所看到的：
經過改動以後的程式，比之前的快了將近 36 倍（能夠參考博文 gpu 程式設計入門到精通（三）之 第乙個 gpu 程式 進行比較），可見並行化處理還是存在優勢的。
只是細緻想一下，我們使用了 512 個執行緒。 但是效能怎麼才提公升了 36 倍，不應該是 512 倍嗎？？？
這裡就涉及到記憶體的訪問模式了，顯示卡上面的記憶體是 dram，是效率最高的訪問方式，它是一種連續的訪問方式。前面我們的程式確實的連續讀取的呀，都挨個讀取了。怎麼還是沒有達到預期的效果呢？？？
這裡還須要考慮 thread 的執行方式。gpu 程式設計入門到精通（三）之 第乙個 gpu 程式 中說到，當乙個 thread 在等待記憶體資料的時候， gpu 就會切換到下乙個 thread。
所以。實際執行的順序類似於 thread0 —> thread1 —> … … —> thread511。
這就導致了同乙個 thread 在讀取記憶體是連續的。 可是對於總體而言，執行的過程中讀取就不是連續的了（這裡自己細緻想想，就明確了）。所以，正確的做法例如以下**所看到的：
執行緒編號
資料下標
00 ~ 512
… …… …
511511 ~ 1023
依據這個原理，改動核心函式例如以下：
for (int i = tid; i < data_size; i += thread_num)改動後程式。比之前的又快了 13 倍左右，可見。對記憶體的讀取方式對於效能的影響非常大。
至此。並行化後的程式較未並行化之前的程式，速度上快了 493 倍左右，可見，基本上發揮了 512 個執行緒的優勢。
讓我們再來分析一下效能：
此 gpu 消耗的時鐘週期： 1595788 cycles
geforce g 103m 的 clockrate： 1.6 ghz
所以能夠計算出 gpu 上執行時間是： 時鐘週期 / clockrate = 997.3675 us
1 m 個 int 型資料有 4m byte 的資料量，實際使用的 gpu 記憶體頻寬是：資料量 / 執行時間 = 4.01 gb/s
執行後結果例如以下所看到的：
通過與系統引數的對照，能夠知道，基本上達到了系統的極限效能。
GPU 程式設計入門到精通之 第乙個 GPU 程式
gpu 程式設計入門到精通 三 之 第乙個 gpu 程式 中講到了如何利用 cuda5.5 在 gpu 中執行乙個程式。通過程式的執行，我們看到了 gpu 確實可以作為乙個運算器，但是，我們在前面的例子中並沒有正真的發揮 gpu 並行處理程式的能力，也就是說之前的例子只利用了 gpu 的乙個執行緒，...
GPU程式設計 四 並行規約優化
如果之前沒有用過gdb,可以速學一下,就幾個指令.想要用cuda gdb對程式進行除錯,首先你要確保你的gpu沒有在執行作業系統介面,比方說,我用的是ubuntu,我就需要用sudo service lightdm stop關閉圖形介面,進入tty1這種字元介面.當然用ssh遠端訪問也是可以的.接下...
Linux入門到精通（四）
命令模式 command mode 控制游標移動，可對文字進行複製 貼上 刪除和查詢等工作。輸入模式 insert mode 正常的文字錄入。末行命令模式 last line mode 儲存或退出文件，以及設定編輯環境。使用者剛剛啟動 vi vim，便進入了命令模式。此狀態下敲擊鍵盤動作會被vim識...