2013-02-16 99 views
1

我發現Visual Studio有一些問題。使用openMP多線程我的項目是在Visual Studio 2010的2倍慢速,比開發-C++,現在我寫了使用CUDA技術,我的其他項目,我認爲我的項目工作,因爲Visual Studio中的慢,所以我需要一些其他的編譯器,將支持CUDA,我的問題是:什麼編譯器支持CUDA

  1. 是Dev-C++支持CUDA嗎?

  2. 什麼編譯器支持CUDA除了Visual Studio的?

  3. ,如果有大量的編譯器支持CUDA什麼將給最佳速度的應用?

回答

3

CUDA Toolkit將Release Notes列表支持的平臺和編譯器。

+0

非常感謝你,因爲我看到支持的Windows編譯器在Windows只Visual Studio 2008和2010年。但也有很多的編譯器在Linux,我的問題是將Windows和Linux編譯器之間有計劃的速度差? – 2013-02-17 20:47:14

+0

是的,所有編譯器都不相同,並且會生成稍有不同的代碼。因此會有程序速度差異。在設備代碼的情況下,nvcc使用的底層設備代碼編譯器應該是相同的,但即使這樣,linux和windows之間的系統級差異也會影響整個程序的速度。我相信Greg已經回答了你的3個問題:1.不支持Dev-C++。 2.對於Windows,唯一支持的編譯器是cl。exe,它包含在VS中。 3.這是一個無法回答的問題。 – 2013-02-17 23:21:02

+0

非常感謝大家:)) – 2013-02-18 21:37:53

0

嗯,我認爲這是相反的方式。事情是,有一個驅動程序叫nvcc。它會生成設備代碼和主機代碼,並將主機代碼發送到編譯器。它應該是一個C編譯器,它應該在可執行文件路徑中。 (編輯:?它應該是GCC在Linux和CL在Windows上,我想我應該忽視MAC作爲發行說明做())

NVCC編譯器信息寫着:

通用的C編譯器通過NVCC在以下 情況需要:

  1. 在非CUDA相(除運行階段),因爲這些階段將由NVCC被轉發到的編譯器

  2. 在CUDA階段,進行幾個預處理階段(另請參閱0)。在Linux平臺上,編譯器被假定爲'gcc'或'g ++'用於鏈接。在Windows平臺上,編譯器被假定爲'cl'。除非指定了選項-compiler-bin-dir,否則 編譯器可執行文件預計位於當前可執行文件 搜索路徑中,其中 大小寫此選項的值必須是這些編譯器可執行文件所在的目錄的名稱 。

請不要這樣說對編譯器。你的代碼在Dev-C++方面效果更好。生成的是彙編代碼。我不是說他們沒有任何區別,但可能是4%到5%,而不是100%。

而且絕對絕對不怪編譯器爲您的慢編程。這絕對是因爲內存訪問效率低下以及不正確使用不同類型的內存。