下面是這段**是我的乙個演算法中用來求和以及求平方和的kernel函式：
__global__ static void compsumandsquare(int rate,int i_n,int size,int width,int wsize,int *image,float *sum,float *sumofsquare) }
} }這個函式的執行時間約為12ms，其中視窗大小為15，測試平台為ngeforce 9800gt，由於這個函式佔據了我整個演算法時間的一半以上。所以本人在無聊之餘將累加和平方和運算遮蔽乙個，看單獨運算的時間，結果這個函式執行的時間為3ms多一點。於是我覺得這個函式的效能瓶頸應該是global memory訪問的方式而非計算指令的吞吐量，然後做了下面一點改動。
改動部分：
for(j=-k;j<=k;j++)
for(j=-k;j<=k;j++)
這個版本函式執行的時間結果約為
7ms，相比較第一版本有些提高，但
還是很慢。隨後想到了
share memory作為中間運算的載體
，使用後的**如下，改動之後的函式時間約為
1.65ms
，還不錯哈！改動的**如下：
__global__
static
void
compsumandsquare(int
rate,int
i_n,int
size,int
width,int
wsize,int *image,float *sum,float *sumofsquare)
s_q[n]=pow(s_m[n],2);
for(j=1;j
sum[ix]=s_m[n];
sumofsquare[ix]=s_q[n]; }
} }我在做這個簡單的效能優化過程時，覺得最讓自己滿意的是這種思考方式，首先找到演算法的瓶頸，然後猜測效能不好的原因，起初我以為計算速度是瓶頸，想用快速函式，當通過乙個小的測試發現儲存器的訪問方式才是問題所在（因為計算規模減少一半，但時間卻減少四分之三），最後想到使用高速儲存器share memory作為中間計算載體，得到比較好的程式效能。
乙個bat使用例項
echo off echo.echo echo open svn log.set svntool c program files tortoisesvn bin tortoiseproc.exe command repobrowser path start rem echo 選擇分支 echo 10...
記錄乙個使用ProcessBuilder踩到的坑
最近使用processbuilder執行命令，命令內容正確，但始終報錯命令實行失敗，是因為不熟悉processbuilder用法踩到了坑，記錄一下。先看一下我模擬出來的錯誤 要執行的命令 cp rf tmp monkey a.log home monkey 簡單的cp命令拷貝乙個檔案，卻報錯說檔案不...
使用兩個佇列實現乙個棧，使用兩個棧實現乙個佇列
一 棧與佇列的特點 一 棧 棧 一種特殊的線性表，其只允許在固定的一端進行插入和刪除元素操作。進行資料插入和刪除操作的一端稱為棧頂，另一端稱為棧底。不含任何元素的棧稱為空 棧，棧又稱為後進先出的線性表。棧的特點 後進先出 lifo 二 佇列 佇列 只允許在一端進行插入資料操作，在另一端進行刪除資料操...