如何使用CUDA達到加速程式

2021-07-09 14:54:38 字數 2179 閱讀 2654

from:

1 block內的

thread

我們是都飽和使用嗎?

答:不要,一般來說,我們開128

或256

個執行緒,二維的話就是

16*16。

2 grid內一般用幾個

block呢?

答:牛人告訴我,一般來說是你的流處理器的4

倍以上,這樣效率最高。

回答這兩個問題的解釋,我想抄襲牛人的一段解釋,解釋的好的東西就要推廣呀:

gpu的計算核心是以一定數量的

streaming processor(sp)

組成的處理器陣列,

nv稱之為

texture processing clusters(tpc)

,每個tpc

中又包含一定數量的

streaming multi-processor(sm)

,每個sm包含8

個sp。sp

的主要結構為乙個

alu(邏輯運算單元),乙個

fpu(浮點運算單元)以及乙個

register file(

暫存器堆)。

sm內包含有乙個

instruction unit

、乙個constant memory

、乙個texture memory

,8192

個register

、乙個16kb

的share memory、8

個stream processor(sp)

和兩個special function units

(sfu

)。(geforce9300m gs

只擁有1個sm

)thread是

cuda

模型中最基本的執行單元,執行最基本的程式指令。

block

是一組協作

thread

,block

內部允許共享儲存,每個

block

最多包含

512個

thread

。grid

是一組block

,共享全域性記憶體。

kernel

是在gpu

上執行的核心程式,每乙個

grid

對應乙個

kernel

任務。 在程式執行的時候,實際上每32

個thread

組成乙個

warp

,每個 

warp 

塊都包含連續的執行緒,遞增執行緒 

id 。

warp是mp

的基本排程單位,每次執行的時候,由於

mp數量不同,所以乙個

block

內的所有

thread

不一定全部同時執行,但是每個

warp

內的所有

thread

一定同時執行。因此,我們在定義block size的時候應使其為

warp size

的整數倍,也就是

block size

應為32

的整數倍。理論上thread

越多,就越能彌補單個

thread

讀取資料的

latency 

,但是當

thread

越多,每個thread

可用的暫存器也就越少,嚴重的時候甚至能造成kernel

無法啟動。因此每個

block

最少應包含64個

thread

,一般選擇

128或者

256,具體視

mp數目而定。乙個mp

最多可以同時執行

768個

thread

,但每個

mp最多包含8個

block

,因此要保持

100%

利用率,

block

數目與其

size

有如下幾種設定方式: ø 2 blocks x 384 threads ø 3 blocks x 256 threads ø 4 blocks x 192 threads ø 6 blocks x 128 threads ø 8 blocks x 96 threads 

這些電很重要啊,必須要充!不然,我就很難理解為什麼網路執行緒如何分配的。

使用CUDA加速CPU程式的步驟

通過效能分析工具 如vs 找到cpu程式最耗時的多個地方,並確定耗時程式的入口函式 將cpu函式進行清理 1.將迴圈部分的 找出來。2.將函式內所用到的資料從c 類結構變成c的結構體。3.標準化輸入輸出,保證其為c結構,並與原程式的資料進行無縫對接。4.將迴圈內部的函式也做相同處理,最終得到c版本的...

使用numba加速python程式

前面說過使用cython來加速python程式的執行速度,但是相對來說程式改動較大,這次就說一種簡單的方式來加速python計算速度的方法,就是使用numba庫來進行,numba庫可以使用jit技術即時編譯,達到高效能,另外也可以使用cuda gpu的計算能力來加速,對python來說是乙個提速非常...

如何加速你的PHP程式

我一直認為php的執行速度是非常的理想的,尤其是zend引擎的加速之後。但是php仍然有加速的可能,你知道嗎?所有的一切都始於如何優化php的編譯 嘗試使用針對cpu型號的特殊編譯引數 msse mmmx mfpmath sse 在編譯的時候新增 03引數 編譯的時候調節cpu的引數 march m...