310 likes | 427 Views
以多緒平行化技術提昇分群地圖上一對一最短路徑求解效能. 指導教授:魏世杰 教授 報告者:淡江大學 資管所 碩士班 何永欣. 研究背景. 雲端 地圖搜索 服務 針對 一對一最短路徑問題,可採用地圖 分 群 快速 求解 ( 鄭 ,2009) 群間地圖:紀錄群邊界到群邊界最短路徑 群內地圖:紀錄群內點到群邊界最短路徑 加快地圖搜索 服務 ,採用技術 CPU OpenMP GPU CUDA 評估指標 回應 時間 單位時間任務數. 研究動機與目的. 在地圖分群下,群間求最短方面
E N D
以多緒平行化技術提昇分群地圖上一對一最短路徑求解效能以多緒平行化技術提昇分群地圖上一對一最短路徑求解效能 指導教授:魏世杰教授 報告者:淡江大學 資管所 碩士班 何永欣
研究背景 • 雲端地圖搜索服務 • 針對一對一最短路徑問題,可採用地圖分群快速求解(鄭,2009) • 群間地圖:紀錄群邊界到群邊界最短路徑 • 群內地圖:紀錄群內點到群邊界最短路徑 • 加快地圖搜索服務,採用技術 • CPU • OpenMP • GPU • CUDA • 評估指標 • 回應時間 • 單位時間任務數
研究動機與目的 • 在地圖分群下,群間求最短方面 • 評估使用GPU相較於純CPU是否可降低最短距離回應時間及增加單位時間任務數 • 評估使用2張GPU相較於1張GPU是否可增加單位時間任務數 • 在地圖分群下,群間+群內求最短方面 • 評估如何搭配GPU及CPU使單位時間任務數最大
文獻探討 • CPU平行化技術-OpenMP • GPU平行化技術-CUDA • Dijkstra演算法 • 地圖分群-METIS • 地圖分群求最短距離與路徑
CPU平行化技術-OpenMP • OpenMP是由OpenMP Architecture Review Board 中的各家知名廠商所制定出的一個平行運算函式庫 • 支援C、C++以及Fortran • OpenMP可跨平台且易用性高,其主要由三個部分所構成: • 編譯器指示(Compiler Directive) • 函式庫(Library) • 環境變數(Environment Variables)
GPU平行化技術-CUDA(1) • CUDA (Compute Unified Device Architecture)是GPU (Graphics Processing Unit)中的一種運算架構 • 支援C、C++、Fortran、OpenCL以及DirectCompute等程式語言
Dijkstra演算法 • Dijkstra演算法為解決最短路徑問題常見演算法之一,主要用於解決一對一及一對多最短路徑問題 • 其使用條件為,地圖中的邊權重必須大於零。 • 在使用順位佇列(Priority Queue)之下時間複雜度為,其中V為節點數,E為邊數
地圖分群-METIS • METIS為Karypis and Kumar (1998)開發的一套多階層(Multi-level)圖形分割軟體,可將資料量大的圖形快速分群,並產生品質較高的分群結果。主要特色有三: • 一是可最小化整體與局部分群的連通度(Connectivity) • 二是每一群內的節點數量相當接近 • 三則是適用於無向圖(Undirected Graph)、有向圖(Directed Graph)、有向加權圖(Weighted Directed Graph)之分群,並可加入條件,調整其分群結果。
地圖分群求最短距離與路徑 • 鄭宇辰(2009)提出了將地圖節點分群,以加快最短路徑搜尋時間。作法先用METIS將台灣路網地圖分群,每一群都有邊界(Border)節點以及非邊界節點。因地圖有方向性, • 在計算最短距離時,使用紀錄距離的三張表格,分別是 • 群內點到邊界距離 (群內圖) • 邊界到邊界距離 (群間圖) • 邊界到群內點距離 (群內圖) • 在找尋最短路徑時,使用記錄下一節點的三張表格,分別是 • 群內點到邊界下一節點 (群內圖) • 邊界到邊界下一節點 (群間圖) • 邊界到群內點下一節點 (群內圖) 透過此六張表格能快速求出最短距離,及找出最短路徑。
方法介紹 • 分群地圖下計算最短路徑 • 群間窮舉配對求最短平行化
情況二 配對組合 邊界X 邊界A 300 40 10 200 50 100 終點T 起點S 400 邊界Y 500 60 20 600 邊界Z 邊界B 群1 群2 SAZT : (10+100+60) = 170
群間窮舉配對求最短平行化-GPU+CPU GPU CPU
實驗結果 • 實驗環境 • 評估方式 • 群間窮舉配對求最短平行化 • CPU單緒 vs 單GPU • 單GPU vs 雙GPU • 群間+群內最佳平行化作法
評估方式 • 評估指標 • 回應時間 • 單位時間任務數 • 評估面向 • 只有最短距離vs最短距離+重建路徑
群間窮舉配對求最短平行化 • 在地圖尋找最短路徑以及距離中,大部分的情況都屬於情況二─起終點不同群且至少一方非邊界之任務居多。因此加快情況二─起終點不同群且至少一方非邊界之任務的部分,對於整體的搜尋時間會有很大的改善。
CPU單緒vs單GPU-只有最短距離 回應時間及任務數為7.7倍,平均一次任務回應時間為0.08 ms
CPU單緒vs單GPU-最短距離+重建路徑 回應時間及任務數為5倍,平均一次任務回應時間為0.13 ms
CPU單緒vs單GPU-變慢原因 總時間變慢原因為紅色重建最短路徑部分都是由CPU做運算
單GPU vs 雙GPU 只有最短距離 雙GPU單位時間任務數為1.9倍 最短距離+重建最短路徑 雙GPU單位時間任務數為1.8倍
群間+群內最佳平行化作法(只有最短距離) 當12個執行緒使用CPU以及4個執行緒使用2張GPU時,效能最佳,一秒內能服務最多任務數,且回應時間為0.55 ms
群間+群內最佳平行化作法(距離+路徑) 當12個執行緒使用CPU以及4個執行緒使用2張GPU時,效能最佳,一秒內能服務最多任務數,且回應時間為0.58 ms
結論 • CPU單緒vs單GPU • 最短距離 • 回應時間及任務數加速比7.7倍 • 平均一次任務回應時間為 0.08 ms • 最短距離+重建最短路徑 • 回應時間及任務數加速比為5倍 • 平均一次任務回應時間為 0.13 ms • 單GPU vs雙GPU • 最短距離 • 單位時間任務數為 1.9倍 • 最短距離+重建最短路徑 • 單位時間任務數為 1.8倍
結論 • 群間+群內最佳平行化作法-最大服務量 • 最短距離 • 當4個執行緒使用GPU,12個執行緒使用CPU時,效能最佳 • 能在一秒內處理25,756個服務需求 • 最短距離+重建最短路徑 • 當4個執行緒使用GPU,12個執行緒使用CPU時,效能最佳 • 能在一秒內處理24,128個服務需求
未來發展 • 後續研究可針對GPU的效能,再次地提升。在圖3-1情況二─起終點不同群且至少一方非邊界之任務中,目前只將單次任務裡面的配對組合,進行平行化,GPU資源利用率不高,未來可將多組任務進行平行化,充分利用GPU硬體的資源,有助於再次提升效能。
報告結束 Q&A