針對大資料的計算，很多程式通過搭建mpi集群進行加速，並取得了很好的效果。演算法內部的加速，當前的並行化趨勢是利用gpu顯示卡進行演算法加速。針對並行性非常好的演算法，gpu加速效果將遠大於集群帶來的加速效果。所以，如果我們面臨非常多的資料，針對資料的處理演算法有具有很好的內部並行性，則我們可以將mpi和gpu結合，獲得更大的加速比。
將mpi和gpu結合的產物就是gpu集群。它可以為我們帶來非常高的加速比。雖說nvidia的cuda為我們提供了類c語言的程式設計環境，但是cuda還不是c語言，這就為mpi和cuda程式設計的融合帶來了難度。我們通過乙個具體例項來說明mpi和cuda混合程式設計的編譯方法。
下面是要編譯專案的makefile檔案，該專案有三個檔案：mpi.cpp，cpp.cpp和cuda.cu，分別表示這三個檔案是mpi檔案，常規cpp和cuda檔案。mpi檔案通過呼叫cpp檔案和cu檔案來實現相應功能。
all: target
cc = mpic++
nvcc = nvcc
cflags+= -o3
ldflags= -l/usr/local/cuda/lib64 -l/root/nvidia_gpu_computing_sdk/c/lib
ldflags+= -lcutil_x86_64 -lm -lcufft -lcublas
nvccflags= -i /usr/local/cuda/include -i /root/nvidia_gpu_computing_sdk/c/common/inc
#nvccflags+= -arch sm_20
target: mpi.o cpp.o cuda.o
$(cc) $(ldflags) -o $@ $^
%.o : %.cu
$(nvcc) $(nvccflags) $(cflags) -o $@ -c $^
%.o: %.cpp
$(cc) $(nvccflags) $(cflags) -o $@ -c $^
clean:
$(rm) *.o *.s *.i target
在程式設計的過程中，盡量不要用.c編寫程式，而要用.cpp編寫程式。在測試過程中發現，用.c編寫程式會發生undefined reference to 「symbols」錯誤。通過makefile檔案我們可以看出：常規的
cpp檔案不是利用
g++進行編譯，而是
mpic++
進行編譯；
cuda
程式還是利用
nvcc
編譯器進行編譯；鏈結的時候要採用
mpic++
編譯器。mpi在呼叫cuda程式的時候，雖然它沒有顯示呼叫cuda相關的標頭檔案，但是它呼叫的cuda程式包含cuda相關的標頭檔案，所以為了保證在編譯mpi.cpp檔案時不出現找不到標頭檔案的錯誤，我們也需要包含相應cuda標頭檔案的目錄。鏈結過程中，即使是mpic++編譯器，我們也需要包含相應cuda庫的目錄，否則也會報錯。
上述makefile是乙個測試模版，但是根據該模版的規則擴充套件就可以正確編譯mpi和cuda程式。
C 和C 混合程式設計
由於歷史原因，很多時候我們的 並不完全是使用.net寫成的。這時候和以往c 的混合程式設計就顯得相當重要了。最近碰到了這樣的問題，將方法簡要記述如下。要在c 中呼叫c 函式，大體的思路是這樣的 首先將c 函式寫成dll形式的庫，然後在c 中匯入dll中的函式進行呼叫。具體的 類似這樣 c 1int ...
c 和Python混合程式設計
1.設定環境 1 在vs的附加包含目錄中新增python的include路徑 2 在vs linker的附加庫目錄中新增python的libs路徑 3 注意，如果安裝的python是64位的，那麼vs工程也要是一直對應的x64活動平台，否則會報 無法解析的外部符號 imp py initialize...
C 和C 混合程式設計
由於歷史原因，很多時候我們的 並不完全是使用.net寫成的。這時候和以往c 的混合程式設計就顯得相當重要了。最近碰到了這樣的問題，將方法簡要記述如下。要在c 中呼叫c 函式，大體的思路是這樣的 首先將c 函式寫成dll形式的庫，然後在c 中匯入dll中的函式進行呼叫。具體的 類似這樣 c 1 int...