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 的乙個執行緒...
OpenGL從入門到精通（三） 第乙個點的理論
一，opengl是乙個狀態機matrix中包括 model view 模型矩陣 worldpos 世界座標,也稱為頂點座標 通過mv 模型矩陣 轉到cameru攝像機下 根據右手座標系，只有在z的負方向才可以看得見 projection 投影矩陣 將攝像機下的三維資訊轉換投影到二維螢幕上 glver...
python第乙個程式設計 第乙個 Python 程式
簡述 安裝完 python 後，windows 中 開始選單或安裝目錄下就會有 idle 開發 python 程式的基本 ide 整合開發環境 幫助手冊 模組文件等。linux 中 只需要在命令列中輸入 python 命令即可啟動互動式程式設計。互動式程式設計 互動式程式設計不需要建立指令碼檔案，是...