2023年2月25日 星期六

究竟 nVidia Gefore GTX 1060 在 TensorFlow-gpu 的表現如何? (Part 3)

照理說,這次的標題是下錯的,因為這次是想要測試一下 nVidia Gefore GTX 1060 在微軟的 Windows Subsystem for Linux (WSL 2) 利用所謂的 DirectML 來開發 tensorflow 2(或者說,在 WSL 2 下能夠使用 GPU 來發揮 tensorflow 2)的程式。但是由於是心得式的文章,我就以 Part 3 來延續這個主題。另外,我想知道,如果以之前安裝的純 tensorflow-gpu 2.3 版來比較,DirectML 的架構效能究竟是怎麼樣的情形。

經過了兩年,我簡單的試圖在 win10 的環境下再次利用 anaconda 3 架設 Tensorflow-GPU 的環境,結果還是不很成熟,我真心認為安裝的過程很沒必要東拿西挪的,直覺式的 conda install 就應該要能做的到,很不幸的,目前最直覺的安裝方式還是幾年前試出來的 tensorflow-gpu 2.3 版。

前幾天學生告訴我,在 win10/win11 的環境下未來的趨勢似乎是 WSL 的天下(雖然我的直覺告訴我,台灣一般資管系的學生比較難接受 Linux),所以我就試了一下所謂的 WSL 2。我幾年前就試過所謂的 WSL,但是可能是所謂的 WSL 1,所以效能不怎麼樣,我就放棄了;這次嘗試 WSL 2,我有了截然不同的體驗,所以安裝完了 WSL 2 就下手嚐試 tensorflow-gpu。

根據文章最後的參考資料一步一步做,可以把 WSL 2 輕鬆的建立起來,而至於利用 GPU 開發 tensorflow 2 的程式(請留意,下列的參考文章中有些是開發 tensorflow 1 的步驟,可以略過),目前似乎有兩種方式,一種是安裝 Docker,另一種是使用微軟自行開發的 DirectML 套件。

快速翻了一下資料,我發現 DirectML 可以支援 nVidia 顯卡之外,包含 Intel 和 AMD 的顯卡,而且似乎效能也不差,所以我第一回合就嚐試了這個方式。根據文章一步一步的作,在建立環境上非常的快速。印象所及,tensorflow 必須安裝 cpu(不是 gpu)的套件[版本居然是 2.10 喔],以及 DirectML 的 plugin,而且簡單的測試是可以使用 GPU 的。

既然安裝完成,我就先拿以前的程式來測試,測試的程式是 Part 2 中提到的將英文翻譯成法文的程式。首先是 tensorflow-gpu 2.3 版效能,大概前幾個 epoch 之後,之後平均一個 epoch 大約是 31 秒左右。

而 GPU 的使用率大致維持在 41% 左右。

有了這個標準之後,我嚐試將同樣的程式在 WSL2 + DirectML 的環境下執行,很可惜無法成功,目前看起來是記憶體不足的原因;至於是什麼造成記憶體不足(超過分配給 WSL 2 這個子系統的記憶體上限?),我還沒時間去瞭解。[註:How to configure memory limits in WSL2 解釋了在預設的情形下,WSL 2 僅佔用了所有記憶體的一半;由於我電腦有 32GB,所以 WSL 2 在預設的情形下使用了 16 GB。後來我根據檔案的做法把 24GB 的記憶體分配給 WSL 2,但是就算是把資料的筆數降到 8000 筆,記憶體還是不夠,看起來 DirectML 的記憶體管理還有改進的空間。]我推測下圖是 WSL 的記憶體管理程序。


下圖是使用 DirectML 無法執行的畫面。

第二回合,我試著嚐試 docker 的方式,結果卻發現似乎只有在完整的 Linux 上才行,可是檔案是微軟寫的,這是真的嗎?後來我東翻西找,把問題解決了,但是我也不記得我做了些什麼,似乎問題在於 docker daemon(或者說 docker 的 server)沒執行所造成的,畢竟 WSL 2 不是一個完整的執行中的 Ubuntu。請記得執行 'sudo service docker status' 來查看 daemon 是否執行;如果沒有,請執行 'sudo service docker start' 來啟動 daemon。

nVidia 的 docker 中的 tensorflow 似乎是 2.1.0 版的,而執行這個 nVidia 的 docker,又想要能夠存取你在 Win10 上的檔案,我們執行指令是 'docker run --gpus all -it --shm-size=1g --ulimit memlock=-1 --ulimit stack=67108864 -v /mnt/d:/myfiles nvcr.io/nvidia/tensorflow:20.03-tf2-py3',其中紫色的代表 docker 的名稱,尤其該檔案一開始並不存在於 Win10 的電腦上,所以第一次執行時會從遠端下載下來;紅色的部分 -v 代表 volume,而緊接其後的字串代表把 /mnt/d (WSL 中代表 D 槽的路徑)並將其掛載在 /myfiles 的路徑上。[註:這些都是 Linux 的檔案系統的概念]

我再次執行放在 D 槽上的 tensorflow 2 的翻譯程式,這次的情形好很多,把處理的資料從 15000 筆降到 8000 筆就可以執行,但是一旦改回 15000 就無法完成執行(雖然兩種情形下都有記憶體不足的警告)。執行 8000 筆的訓練時間,當然少很多。

不知道是資料量變小,還是 docker 運用 GPU 的運算量不佳,如下圖所示,GPU 平均使用率大約在 20%。


我找了一下是否還有其他 nVidia 包好的 tensorflow 2 的 docker,結果找到 nVidia docker 的網站,客官們可以自行下載來試試看。docker 的執行指令還有個有趣的可能:--shm-size=1g。不知道如果增加數字,狀況會不會好些?

結論:以目前的經驗來說,在安裝上 DirectML 比較簡單;而在執行上 nVidia 提供的 docker 似乎比較容易成功。 

後記:隨著經驗的累積,我嘗試了最新的 docker image (tensorflow:23.02-tf2-py3),結果是"就算是 8000 筆資料,也跟 DirectML 一樣,會不正常結束。仔細觀察兩個 docker images 的差異,我發現 tensorflow:20.03-tf2-py3 使用了 libcudart.so.10.2 和 libcudnn.so.7,這樣的組合跟我的 tensorflow-gpu 2.3 的環境相似,而最新的 docker image,我相信是使用比較新的 cudatoolkit 和 cudnn(但是執行畫面未呈現任何可以用以判斷的資訊),因此限制了程式的執行。

1. Enable NVIDIA CUDA on WSL

2. 在 WSL 中使用 GPU 加速進行 ML的 開始

沒有留言:

張貼留言