gpu分析的python,gpu概念

本文目錄一覽：

• 1、使用python在GPU上構建和訓練卷積神經網路
• 2、如何用Python一門語言通吃高性能並發，GPU計算和深度學習
• 3、用GPU做python程序並行到底用什麼好

使用python在GPU上構建和訓練卷積神經網路

我將對代碼進行補充演練，以構建在數據集上訓練的任何類型的圖像分類器。在這個例子中，我將使用花卉數據集，其中包括102種不同類型的花。需要數據集和代碼都可以私信我。

Pytorch是機器學習和Python上的免費軟體包，非常易於使用。語法模擬numpy，因此，如果你在python中有一些科學計算經驗，那麼會相當有用的。只需幾行代碼，就可以下載預先訓練的數據集，使用定義的變換對圖像進行標準化，然後運行訓練。

創建和擴充數據集

為了增加數據集，我使用’ google_images_download’API 從互聯網上下載了相關圖像。顯然，您可以使用此API不僅可以擴充現有數據集，還可以從頭開始創建自己的數據集。

確保從圖像中挑選出異常值(損壞的文件或偶然出現的無關圖像)。

圖像標準化

為了使圖像具有相同的大小和像素變化，可以使用pytorch的transfors模塊：

轉移學習

從頭開始訓練的模型可能不是最明智的選擇，因為有許多網路可用於各種數據集。簡單地說，像edge-和其他簡單形狀檢測器等低級特徵對於不同的模型是相似的，即使clasificators是針對不同目的進行訓練的。在本項目中，我使用了一個預訓練網路Resnet152，只有最後一個完全連接的層重新用於新任務，即使這樣也會產生相當好的效果。

在這裡，我將除最後一層之外的所有層都設置為具有固定權重（requires_grad = False），因此只有最後層中的參數將通過梯度下降進行更新。

訓練模型

下面介紹一下進行訓練的函數：

如何獲得GPU？

當然，對CPU的訓練太慢了。根據我自己的經驗，在GPU僅需要一個小時就可以完成12次訓練周期，但是在CPU上相同數量的訓練周期可能需要花費大約15個小時。

如果您沒有本地可用的GPU，則可以考慮使用雲GPU。為了加速CNN的訓練，我使用了floydhub（）上提供的雲GPU 。

這項服務非常指的使用：總有很好的文檔和大量的提示，所以你會很清楚的知道下一步需要如何去做。在floydhub上對於使用GPU的收費也是可以接受的。

首先，需要將數據集上傳到伺服器

然後，需要創建項目。需要在計算機上安裝floydhub客戶端，將數據集上載到其網站並在終端中運行以下命令：

其中’username’是您的登錄名，’i’是數據集所在的文件夾。

這樣子在訓練網路時就會很輕鬆了

結果和改進想法

得到的模型在數據集上訓練了1.5小時，並在驗證數據集上達到了95％的準確度。

如何用Python一門語言通吃高性能並發，GPU計算和深度學習

第一個就是並發本身所帶來的開銷即新開處理線程、關閉處理線程、多個處理線程時間片輪轉所帶來的開銷。

實際上對於一些邏輯不那麼複雜的場景來說這些開銷甚至比真正的處理邏輯部分代碼的開銷更大。所以我們決定採用基於協程的並發方式，即服務進程只有一個(單cpu)所有的請求數據都由這個服務進程內部來維護，同時服務進程自行調度不同請求的處理順序，這樣避免了傳統多線程並發方式新建、銷毀以及系統調度處理線程的開銷。基於這樣的考慮我們選擇了基於Tornado框架實現api服務的開發。Tornado的實現非常簡潔明了，使用python的生成器作為協程，利用IOLoop實現了調度隊列。

第二個問題是資料庫的性能，這裡說的資料庫包括MongoDB和Redis，我這裡分開講。

先講MongoDB的問題，MongoDB主要存儲不同的用戶對於驗證的不同設置，比如該顯示什麼樣的圖片。

一開始每次驗證請求都會查詢MongoDB，當時我們的MongoDB是純內存的，同時三台機器組成一個複製集，這樣的組合大概能穩定承載八九千的qps，後來隨著我們驗證量越來越大，這個承載能力逐漸就成為了我們的瓶頸。

為了徹底搞定這個問題，我們提出了最極端的解決方案，乾脆直接把資料庫中的數據完全緩存到服務進程里定期批量更新，這樣查詢的開銷將大大降低。但是因為我們用的是Python，由於GIL的存在，在8核伺服器上會fork出來8個服務進程，進程之間不像線程那麼方便，所以我們基於mmap自己寫了一套夥伴演算法構建了一個跨進程共享緩存。自從這套緩存上線之後，Mongodb的負載幾乎變成了零。

說完了MongoDB再說Redis的問題，Redis代碼簡潔、數據結構豐富、性能強大，唯一的問題是作為一個單進程程序，終究性能是有上限的。

雖然今年Redis發布了官方的集群版本，但是經過我們的測試，認為這套分散式方案的故障恢復時間不夠優秀並且運維成本較高。在Redis官方集群方案面世之前，開源世界有不少proxy方案，比如Twtter的TwemProxy和豌豆莢的Codis。這兩種方案測試完之後給我們的感覺TwemProxy運維還是比較麻煩，Codis使用起來讓人非常心曠神怡，無論是修改配置還是擴容都可以在配置頁面上完成，並且性能也還算不錯，但無奈當時Codis還有比較嚴重的BUG只能放棄之。

幾乎嘗試過各種方案之後，我們還是下決心自己實現一套分散式方案，目的是高度貼合我們的需求並且運維成本要低、擴容要方便、故障切換要快最重要的是數據冗餘一定要做好。

基於上面的考慮，我們確定基於客戶端的分散式方案，通過zookeeper來同步狀態保證高可用。具體來說，我們修改Redis源碼，使其向zookeeper註冊，客戶端由zookeeper上獲取Redis伺服器集群信息並根據統一的一致性哈希演算法來計算數據應該存儲在哪台Redis上，並在哈希環的下一台Redis上寫入一份冗餘數據，當讀取原始數據失敗時可以立即嘗試讀取冗餘數據而不會造成服務中斷。

用GPU做python程序並行到底用什麼好

因為我的程序中需要並行的是優化計算的evaluation部分，所以如果能夠找到一些支持並行優化的庫就可以。 從python官網上，可以找到一個DEAP庫（git上有），利用map進行並行計算。 這個庫的優點是，documents和例子是非常詳細的。