中 華 大 學

中 華 大 學 碩 士 論 文

在多圖形運算單元上運用候選項目切割機 制於 OpenCL 之 Apriori 演算法

An OpenCL Candidate Slicing Frequent Pattern Mining Algorithm on Multi -GPUs

系 所 別：資訊工程學系碩士班 學號姓名：M09902029 林哲瑜

指導教授：游 坤 明 博 士

中 華 民 國 101 年 8 月

i

摘要

Apriori 演算法是頻繁樣式探勘(Frequent pattern mining，FPM)中是一種經典 演算法，而 Apriori 演算法於增加資料庫的資料量及門檻值縮小時，其計算時間 將會大量增加，針對此兩項問題的改良演算法更是車載斗量，利用 GPU 改良 Apriori 卻是滄海一粟，特別是使用 OpenCL 作為改良的語法更為稀少。

隨著 GPU 運算能力增加，單一 GPU 已是一種平行運算裝置，利用核心數量 及 Single Instruction, Multiple Data (SIMD)的運算架構達到平行運算，促使 GPU 運算取代叢集及網格運算，使得有一部分利用 GPU 改良 Apriori 的演算法被提出，

例如使用 Bitmap 結合 AND 邏輯運算提升速度，但是都以 CUDA 作為 Kernel 的 運算語言，只有極少使用 OpenCL。

本論文提出兩項改良演算法一為利用 OpenCL 為核心語言的 Candidate Slicing Frequent Pattern Mining (CSFPM)，並利用 Mutli-GPU 架構改良 CSFPM 以 達到更佳效能。於本研究中，由於 GPU 的單一核心運算速度較慢，因此單一核 心不宜大量運算，所以將每一個候選項目切割成更小單元，使單一核心運算量降 低，以達到較佳的運算效能。

在 GPU-FPM 可運算的資料中，CSFPM 都有 1.2 以上的加速比，GPU-FPM 於單一核心運算量過大時將會出現錯誤的狀況，而 CSFPM 利用 GPU 核心數量 多的特點，減少一次 for 迴圈的使用，減少單一核心運算量的問題，並且在運用 Multi-GPU 與 CSFPM 結合後，所呈現的加速比能提高至兩倍，因此我們所提出 的演算法不僅能降低負載平衡，更能大幅降低資料運算的時間。

關鍵字：Apriori、頻繁樣式探勘、OpenCL、Multi-GPU

ii

Abstract

Frequent pattern mining (FPM) is important in data mining field with Apriori algorithm to be one of the commonly used approaches to solve it. However, Aprori algorithm encounters an issue that the computation time increases dramatically when data size increases and when the threshold is small. Many parallel algorithms have been proposed to speed up the computation using computer clusters or grid systems.

GPUs have also been applied on FPM with only few adopting OpenCL although OpenCL has the advantage of being platform independent, but does not have multi-GPU with OpenCL and OpenMP.

GPU computing is a tendency. The GPU is a parallel computing devices, as a simple multi-core CPU, but the number of GPU core is much more than the CPU core.

Single GPU computing will be the constraints on hardware. If using the Multi-GPU to compute, it will get more computing power.

The aim of this research is to develop efficient parallel Aprori strategy using GPU and OpenCL. Our novel method, Candidate Slicing Frequent Pattern Mining (CSFPM) algorithm, improves over the previous method by slicing candidate information to better balance the load between processing units. This strategy is proved to be more efficient according to our experiments. For example, CSFPM is at most 2.6 times faster than the previous method. Multi-GPU is at most 1 times faster than 1 GPU.

Keywords：Apriori, OpenCL, Multi-GPU

iii

誌謝

時間過得很快，終於完成本論文，也代表我的碩士學業即將結束，回首過去 的研究生涯裡，我獲得許多人的幫助，首先感謝我的母親，讓我無金錢上的顧慮，

以及精神上的鼓勵，使我能夠將大部分的時間分配到學習上，而無需為生活擔 心。

而後我要感謝我的指導教授游坤明教授，給予最多專業能力的學習機會，由 於在這兩年研究生涯中，有大量的機會參與到各種不同類型的計畫，因此需要接 觸到更多不同的程式語言、團隊夥伴以及不同的運算平台，並且使我在平行運算 這領域中，從一無所知到了解其中奧秘之處，特別是利用圖形運算單元以達到平 行運算之需求這一領域，以及給予發表國際論文的機會，並且讓我有一趟難忘的 阿拉斯加之旅；在此也感謝歐陽雯教授，在我的英文能力部分給予協助以及指 導。

其次我要感謝嘉奕學長於專業知識上的教導，以及實驗室中的各位，感謝書 豪學長於資料探勘這領域中給予我莫大的協助，促使我的論文能夠順利發表；感 謝建元學長給予我在智慧家庭的計畫中學習的機會；以及逸豪學長於參與比賽時 的程式協助；感謝同儕雋元於 CCI 計畫中的協助，和同儕世川給予很多計畫中 的協助，以及學弟崇碩給予我在逃生規劃的知識；在此我要特別感謝學弟元劭在 很多計畫中的協助，特別是 Ruby on Rails 的撰寫，並且帶給實驗室更多的歡笑。

我很感謝這兩年我是在 E114，這像是我的第二個家，因為有 E114 的成員在，即 使程式寫不出來、Bug 找不到，也有其他夥伴協助及關心，甚至實質的幫助(買 便當)，使我不是孤軍奮戰。感謝曾經幫助過我的每個人。

iv

目錄

摘要... i

Abstract ... ii

誌謝... iii

目錄... iv

圖目錄... vi

表目錄... ix

第一章 緒論... 1

第二章 相關研究... 4

2.1 Apriori 演算法 ... 5

2.2 OpenMP/MPI ... 9

2.3 MATI ... 11

2.4 GPU 平行運算... 12

2.5 Bitmap ... 14

2.6 GPU-FPM ... 16

第三章 研究方法... 19

3.1 候選項目切片及 GPU 平行運算方式(CSFPM) ... 19

3.2 CSFPM 演算法及流程圖 ... 22

3.3 Multi-GPU 利用 CSFPM 運算之架構 ... 26

第四章 實驗與結果分析... 31

4.1 環境設定... 31

4.2 單一 GPU 效能分析... 33

v

4.3Multi-GPU 運算效能分析 ... 38 第五章 結論與未來展望... 50 參考文獻... 52

vi

圖目錄

圖 2-1 範例流程圖 ... 7

圖 2-2 Apriori 流程圖 ... 8

圖 2-3 MPI 分散式記憶體示意圖 ... 10

圖 2-4 OpenMP 共享記憶體示意圖 ... 11

圖 2-5 MATI 可合併的項目 ... 12

圖 2-6 MATI 不可合併的項目 ... 12

圖 2-7 SIMD ... 13

圖 2-8 GPU 計算流程 ... 14

圖 2-9 AND 範例圖 ... 15

圖 2-10 Tid Value 和 Tid Index 表格 ... 17

圖 2-11 Parallel Frequent Patterns Mining Algorithm on GPU 計算範例 . 18 圖 3-1 Tid Value 和 Tid Index 表格 ... 20

圖 3-2 GPU 計算候選項目方法示意圖 ... 21

圖 3-3 CSFPM 的 CPU 部分... 23

圖 3-4 CSFPM 的 GPU 部分 ... 24

圖 3-5 Multi-core CPU 控制多 GPU 運算之流程圖 ... 25

圖 3-6 利用 CPU Thread 控制 Multi-GPU 運算硬體架構 ... 26

圖 3-7 Multi-core CPU 控制 Multi-GPU 運算硬體架構 ... 27

圖 3-8 Multi-GPU CSFPM 的 CPU 部分 ... 29

圖 3-9 Multi-GPU CSFPM 的 CPU 部分 ... 29

圖 4-1 T10I4D100K,T200 使用表 4-5 之主機運算結果 ... 34

vii

圖 4-2 CSFPM 與 GPU-FPM 使用一張 GTX 580 於 T10I4D100K,T200 的比較... 35 圖 4-3 CSFPM 與 GPU-FPM 使用一張 GTX 580 於 T10I4D100K,T100

的比較... 36 圖 4-4 CSFPM 與 GPU-FPM 使用一張 GTX 580 於 T10I4DXK,T0.2%的

比較... 37 圖 4-5 T10I4D100K，門檻值 200，使用 3 張 GTX 580 的不同 Thread 運

算時間... 39 圖 4-6 T10I4D100K，門檻值 200，Thread 為 16385 時使用張數不等的

GTX 580 運算時間 ... 39 圖 4-7 T10I4D100K，門檻值 100，使用 3 張 GTX 580 的不同 Thread 運

算時間... 40 圖 4-8 T10I4D100K，門檻值 100，Thread 為 8192 時使用張數不等的

GTX 580 運算時間 ... 41 圖 4-9 T10I4D1000K，門檻值 2000，使用 3 張 GTX 580 的不同 Thread

運算時間... 42 圖 4-10 T10I4D1000K，門檻值 2000，Thread 為 131072 時使用張數不

等的 GTX 580 運算時間 ... 43 圖 4-11 T10I4D1000K，門檻值 1000，使用 3 張 GTX 580 的不同 Thread

運算時間... 44 圖 4-12 T10I4D1000K，門檻值 1000，使用不同張數的 GTX 580 運算

Thread 32768 ... 45 圖 4-13 Retail，門檻值 1%，使用 3 張 GTX 580 的不同 Thread 運算時

間... 46

viii

圖 4-14 Retail，門檻值 1%，使用不同張數的 GTX 580 運算 Thread 131072... 46 圖 4-15 Chess，門檻值 70%，使用 3 張 GTX 580 的不同 Thread 運算時

間... 47 圖 4-16 Chess，門檻值 70%，使用不同張數的 GTX 580 運算 Thread 131072... 48

ix

表目錄

表 2-1 交易資料庫 ... 6

表 2-2 交易資料庫中各物品出現次數 ... 6

表 2-3 第二階候選項目計算出現次數 ... 6

表 2-4 交易資料庫表 ... 15

表 2-5 資料庫轉換成 Bitmap 表格儲存 ... 16

表 2-6 第二階候選項目 ... 17

表 2-7 TID 表格 ... 17

表 3-1 資料庫轉換成 TID 表格儲存... 20

表 3-2 計算候選項目次數 ... 21

表 3-3 計算候選項目次數 ... 22

表 4-1 與 GPU-FPM 相同規格的主機 ... 31

表 4-2 用於多張 GPU 運算主機 ... 32

表 4-3 IBM 資料產生器的輸入項目 ... 32

表 4-4 用於比較的資料庫 ... 33

表 4-5 用於與 GPU-FPM 比較的 T10I4D100K 門檻值 200 的運算平台與 資料特性... 33

表 4-6 T10I4D100K 門檻值 200 的運算平台與資料特性 ... 34

表 4-7 T10I4D100K 門檻值 200 的運算平台與資料特性 ... 38

表 4-8 T10I4D100K 門檻值 100 的運算平台與資料特性 ... 40

表 4-9 T10I4D1000K 門檻值 2000 的運算平台與資料特性 ... 41

表 4-10 T10I4D1000K 門檻值 1000 的運算平台與資料特性 ... 43

x

表 4-11 Retail 門檻值 1%的運算平台與資料特性 ... 45 表 4-12 Chess 門檻值 70%的運算平台與資料特性 ... 47

1

第一章 緒論

資料探勘(Data Mining)是資料庫知識發現(Knowledge-Discovery in Databases, KDD)的一個步驟。資料探勘的過程分別為資料收集、資料前處理、資料倉儲建 立、資料探勘、樣式評估、結果展示。資料收集為知識發現的首要條件，需要擁 有大量的資料才能夠尋找出有用的知識，而收集來的資料是非常雜亂的，因此需 要完成整理及檢察，其中包含資料的淨化、轉換格式、表格的連結等前置作業以 利於資料探勘。資料探勘所需要的資料庫將會在資料前處理後被建立。資料探勘 是一種已被廣泛使用的方法，其從大量的資料中搜尋出隱藏訊息的過程，於資料 庫知識發現過程中的重要步驟。在探勘完成後所得到的結果，還需要透過樣式評 估，檢查是否為有用的資訊，最後則完成知識發現的過程。

購物籃分析[5]為資料探勘中的一項應用，購物籃分析是將顧客的購買活動 中所購買的商品做組合，並依組合後的相關性進行研究，其目的是為了找出不同 商品間的購買特性。購物籃分析中常被使用的是頻繁樣式探勘(Frequent pattern mining, FPM)，目前雖然已經有大量相關的頻繁樣式探勘演算法被提出，但是主 要可分為兩類：FP-growth[8,10]及 Apriori[1,15]演算法，FP-growth 使用樹狀結構 (Tree)將資料儲存於 FP-tree 中，達到不需要產生候選項目集(Candidate itemsets) 及減少重覆存取資料庫，使其運算加速，且在單一核心運算時可以得到較佳的效 能，但移植到多核心運算時會有因樹狀結構的切割及負載平衡不易等問題，因而 不利於平行運算；而 Apriori 的演算法利用循序漸進的方式產生出每一階的候選 項目集，由於需要產生並檢查後選項目集是否屬於高頻項目，但是其利用陣列作 為主要的儲存方式，陣列優勢是方便於切割及平行運算，當運算核心數量越來越 多，則 Apriori 的優勢將會越來越顯著。

2

Apriori 使用 Transaction Identification (TID) 的目的與 FP-tree 相同，目的在 減少重複讀取資料庫達到整體加速的效果。TID 為資料庫的資料形態轉換方式，

以往的資料儲存方式多為已訂單編號為索引的資料表，使用 TID 後資料表將以 物品為索引，並且將其存放於記憶體中，以利後續運算時使用。

除了演算法的加速之外，硬體設備發展的速度更快。以往為單核心運算到現 在的多核心運算以為一大突破，當單一主機已經無法負擔大量運算時，而延伸出 的叢集式運算，利用多台電腦串連成一台超級電腦，但是因為高耗電量及運算效 能無法突破等問題，硬體設備開始轉換成以往提供影像運算的圖形運算單元 (Graphic processing units, GPU)[4,11]發展，由於現在的 GPU 核心數量暴增、運算 速度提升，單一的 GPU 核心數量已可到達上百或上千顆核心，每顆核心可以提 供數 MHZ 甚至數 GHZ 的運算速度，因此 GPU 成為新式的運算單元。GPU 擁有 大量的核心數，並且 GPU 屬於單指令流多數據流(Single instruction, multiple data, SIMD)的運算方式，利用此方法達到有效的平行運算，但是直接移植的演算法是 無法使用 GPU 進行加速，因此演算法的修正及改良是很重要的。由於 GPU 單一 核心的運算速度較慢，因此單一核心運算的工作量不宜太多，當運算量較大時需 要的時間較長，而等待的時間也相對增加，並且當任一顆核心運算工作尚未完成 時，GPU 是無法回傳結果到主記憶體中，因此需要等待剩餘的工作完成後才能 一次回傳，因此負載平衡的工作非常重要[17]。

在本論文中提出了兩種改良方法，一為 Candidate Slicing Frequent Pattern Mining Algorithm(CSFPM)，二為結合 Multi-GPU 的 CSFPM，利用切割候選項目 成為更小的運算單元以達到更佳的負載平衡[17]，並且運算過程中都為等號運算，

當訂單編號相同時則代表檢查的物品於同一訂單被購買，而回傳值為 1；當沒有 等於的狀況發生時，代表訂單不相同，而程式將會跳過並且回傳值為 0 。當計 算完成後，CPU 只需要計算 1 的數量即可知道是否高於門檻值，當高於或等於

3

門檻值時則為高頻項目，當低於門檻值則該候選項目將被刪除。而 結合了 Multi-GPU 的 CSFPM 則是利用更多的 GPU 協助運算，並且利用 OpenMP 的多 核心 CPU 語言控制不同的 GPU，以一個 CPU core 對應一張 GPU 的運算方式，

達到更快速的加速比。

在本論文中的第二章相關研究內介紹了一些關於 Apriori 的演算法，例如 Bitmap[6.7.9.18] 的 運 算 方 式 及 直 接 移 植 至 GPU 中 的 GPU-FPM 以 及 使 用 Multi-Core CPU 作 為 運 算 平 台 的 Multi-core Apriori Transaction Identifiers (MATI)[16]。在第三章研究方法內提出了 CSFPM 及 Multi-GPU 使用 CSFPM 方 法計算，並且於第四章結果分析內說明各資料運算後的加速比，最後，第五章是 對本論文提出結論以及未來研究方向。

4

第二章 相關研究

資料探勘技術則是從大量的資料中自動尋找出隱藏於資料中的特殊關係，資 料探勘應用因資料的收集技術成熟、高速的處理器架構及探勘演算法之成熟使其 興起。資料探勘演算法中常被使用的一種方法為購物籃分析中的頻繁樣式探勘，

其應用例如：用於賣場的消費紀錄中尋找顧客購買的習慣之購物籃分析，將常同 時被購買的商品擺設於附近可使顧客更加方便，或是一同購買便可取得促銷優惠 則可達到提升顧客之購買意願。探勘頻繁樣式需要大量的資料作為探勘的依據，

資料量因快速的網路及資料庫普遍而遽增，又因多核心 CPU 技術加速演算法之 運算，使資料探勘技術更廣泛被使用，因而資料探勘技術備受重視，但是 CPU 的改良速度已無法滿足資料量遽增的資料探勘運算時間，促使學者大量投入其演 算法改良之研究。

早在 1994 年 R. Agrawal 及 R. Srikant 學者於論文[1]中提出了 Apriori 演算 法，其演算法方法為循序的產生候選項目( Candidate itemsets )並且利用原始的資 料庫檢查候選項目的次數，高於門檻值或支持度則為高頻項目，此演算法特性為 簡單、容易了解、容易實作，但是需要大量並且重複的掃描資料庫以確定候選項 目的次數，而重複掃描需要大量的 I/O 時間，因此 AprioriTid 的被提出，為了節 省重複讀取資料庫所增加的運算時間，達到有效的頻繁樣式探勘演算法，現在也 有大量的改良 Apriori 演算法被提出。

現在的電腦基本上都是多核心的 CPU，而 MATI[16]演算法就是一個利用 Multi-Core CPU 的平行運算，並且提出了較快速的合併的方法，Multi-Core CPU 的運算方式是使用 OpenMP 語言控制不同核心運算，達到演算法加速的效果。

然而只使用 CPU 是無法達到更佳的速度，由於 GPU 可運算核心的數量暴增，單

5

一 GPU 卡的核心數量已可達到上百或是上千顆核心，其數量遠大於 CPU，每一 顆核心都可以視為一顆簡易的 CPU 核心，單一科 GPU 核心可提供數 MHZ 甚至 數 GHZ 的運算速度，因此有部分研究開始以 GPU 作為主要運算的平台。

單一顆 GPU 核心速度較 CPU 慢，但是擁有大量的核心數量的 GPU，成為 了新式的運算單元，例如 Bitmap[6.7.9.18]及 GPU-FPM 都是以 GPU 作為運算平 台，並改良自 Apriori 演算法。其中 Bitmap 是使用 CUDA[13]作為運算，而 GPU-FPM 是使用 OpenCL[14]作為 Kernel 的編譯語言，其語言差別於 OpenCL 可於 ATI[3]及 NVidia 的 GPU 中運算，而 CUDA 只限制於使用 NVidia 的 GPU 中。

兩者所提出的演算法概念雖不相同卻各有優缺點，Bitmap 的優點是運算速度快，

因為利用 AND 邏輯運算的概念提升速度，但是記憶體使用量大，由於每個物品 都需要有一個對應的儲存空間，因此運算量較大，並且計算的概念為 bit 作為運 算的欄位，於計算數量時較為困難；而 GPU-FPM 是利用候選項目的集合完整傳 入 GPU，優點是只須保留滿足門檻值條件的物品資料，因此記憶體需求較少，

但是因為計算量較大，並且負載平衡較差。

2.1 Apriori 演算法

Apriori 演算法在 1994 年由 R. Agrawal 與 R. Srikant 共同提出對於頻繁樣式 探勘問題的演算法[1]，為最早提出關聯式探勘的演算法，也是關聯式法則演算 法中最具代表性的演算法之一。其特性為簡單且易於實作，利用循序漸進的方式，

不斷的重複掃瞄資料庫用於計算候選項目出現次數。使用此方法計算前需要先給 定一門檻值(minsup)，當候選項目在清單上出現次數多於門檻值，則該候選項目 為當階高頻項目，假設合併為第 K 階，則是利用 K-1 階的高頻項目合併成為第 K 階的候選項目，並且在重新計算每個候選項目次數，一階一階的尋找隱藏在資 料庫中的高頻項目。

6

例如：有一交易資料庫為{T1，T2，T3，T4}，表 2-1 為每筆交易項目，每 項物品的交易次數為表 2-2，例如所設定的門檻值為 50%，代表交易清單 4 筆的 50%，則交易次數需大於等於 2 才為高頻項目，因此{D}和{E}將會被刪除，只為 {A}、{B}和{C}為第一階高頻項目，利用第一階高頻項目倆倆合併，可得到{A，

B}、{A， C}和{B，C}的候選項目。在重新掃描資料庫並且計算每一個候選項 目所出現的次數，如表 2-3，計算出現次數後可得知只有{A，B}符合門檻值，因 此{A，B}為此階的高頻項目，由於{A，B}已經無法再合併為下一階之候選項目，

故也為此資料庫的高頻項目，以下介紹演算法範例及其流程，如圖 2-1 與 2-2。

表 2-1 交易資料庫

9 交易編號

T1 { A,B,C } T2 { A,B } T3 { B,D } T4 { C,E } 表 2-2 交易資料庫中各物品出現次數

物品 次數

A

B

C

D

E

表 2-3 交易資料庫中各物品出現次數

物品 次數

AB 2

AC 1

BC 1

7

圖 2-1 範例流程圖

8

開始

輸入門檻值

產生候選項目

計算候選項目 出現次數

次數大於或等於 門檻值

高頻項目 刪除該候選項目

否

是

是否可以再合併 是

否 結束

圖 2-2 Apriori 流程圖

9

2.2 OpenMP/MPI

隨著多核心處理器的普及，平行處理演算法的重要性與日俱增，過去平行化 都是由不同主機透過網路互相傳遞訊息，例如：叢集及網格運算，連同現在討論 熱絡的雲端系統也是透過網路連結不同主機提供大量的運算能力，由於以往的運 算通常屬於多台主機分別運算少量資料，而後回傳至主要控制主機，其中各主機 所執行的程式為單一執行序，因而達到平行化之目的，即使使用多核心運算CPU 也如同單一核心運算方式，包含現在利用多核心運算的方法也是分配不同核心運 算不同工作，因此多核心並不能對於單一程式進行加速。

由於一般的單一執行序程式並無法利用多核心運算進行提升運算效能，但多 執行序程式即可利用不同的核心同時運算，藉此提升運算效能，例如：執行一次 運算時間需要花費 1 秒，執行 100 次的運算將需要 100 秒之運算時間，而利用四 核心同時運算則各核心只需要執行 25 次，執行時間也只需要 25 秒。多核心運算 時間並非增加一個核心即可得到一倍加速比，但卻可得到一部分的加速，也是提 升效率的方法。

為了達到多核心運算的效能，常使用的方法有兩種，一為 MPI (message passing interface)，另一種為 OpenMP。MPI 為一種標準化的平行語言，可使用於 C、C++、Fortran 等語言上，不但可於分散式記憶體平行系統上使用，也可使用 於共用記憶體的平行運算系統，MPI 大多使用於不同主機間的平行運算，而 OpenMP 是由 OpenMP Architecture Review Board 提出，目前已被廣泛使用於共 享記憶體的平行運算， OpenMP 提供了高階的程式語言，只需要於原始碼中加 入 OpenMP 所需的程式碼，支援的編譯器即可自動產生平行化之執行檔，如果 編譯器不支援 OpenMP 時，即可使用一般的執行序完成運算。

OpenMP 與 MPI 最大差異是記憶體的使用方式，由於以往的 MPI 大多使用

10

於叢集或網格運算，故記憶體的使用方式多為分散式，並且使用網路作為記憶體 的溝通橋樑，如圖 2-3，優點為可利用網路將所有主機連接，並且由於記憶體為 分散的，可避免重複使用相同記憶體的產生，例如：程式撰寫時需要儲存至 int x 的變數中，由於各主機都有獨立的記憶體，程式撰寫時無需特別注意覆蓋問題。

而缺點則是主機間資料交換時依賴網路作為傳遞，而網路的速度則影響到資料的 存取速度，並且不同主機讀取資料時較為困難。

圖 2-3 MPI 分散式記憶體示意圖

OpenMP 則是使用 Shared Memory 的共享記憶體概念，如圖 2-4 所示，由於 此應用為同一主機上使用，因此可共享記憶體，其優點則是記憶體的存取速度由 於都在主機內，因此速度較快也較容易，缺點則是需要良好的記憶體管理方式，

以防止覆蓋記憶體，例如：當四個核心皆需要儲存資料到 int x 的變數中，將會 出現碰撞問題，其解決方法可能為 x 變數修正為一維陣列，各核心只存放於對應 的陣列中。

11

圖 2-4 OpenMP 共享記憶體示意圖

2.3 MATI

Multi-core Apriori Transaction Identifiers (MATI)[16]其方法使用 Multi-core CPU 作為運算之平台，雖不是使用 GPU，但其論文中所使用的合併方式可以消 除大量的重複項目。

其演算法為：當產生 K+1 階候選項目並且 K 大於 1 時，是由 K 的高頻項目 兩項進行合併，當是可以合併的項目則從項目開頭的 K-1 項是相同的物品，代表 可以合併。

例如圖 2-5，K 等於 2，AB 及 AC 是第二階的高頻項目，當要合成為第三階 的候選項目時，需要滿足 2-1 項物品，代表需要 1 項物品相同即可，而 AB 和 AC 的開頭都是 A 物品，代表滿足此項規定，則可以合併為 ABC 做為下一階候 選項目。如圖 2-6，而當 AC 與 BC 需要合併時，由於不滿足演算法之規定，未 達到第 1 項物品相同，因此無須合併為 ABC 項目。由於原始方法的合併原則為 須滿足所有項目才可合併，例如要合併成 ABC 項目則需要在前一階高頻項目中 滿足 AB、AC 及 BC 三項，檢查過程繁忙，因此此演算法可以快速的合併候選 項目，並且可以有效的減少過多重複的候選項目產生。

12

圖 2-5 MATI 可合併的項目

圖 2-6 MATI 不可合併的項目

2.4 GPU 平行運算

GPU 原是專門處理影像運算工作的微處理器，如今可用於運算原先由中央 處理器負責的通用計算稱為通用圖形運算單元(General-purpose computing on graphics processing units, GPGPU, GP²U )[12]，這類型的通用計算是與圖形處理無

13

關，並且 GPU 擁有強大的平行處理能力，當運算量遠大於資料傳輸量時，GPU 運算將會遠超過傳統中央處理器的效能。

GPU 擁有數百甚至數千個計算單位，採用的運算方式為：單指令流多數據 流(Single Instruction Multiple Data, SIMD)，並且使用控制器控制多個處理器，可 同時對一組資料中的個別數據分別運算相同的指令，如圖 2-7，以達到平行運算 的效果，但是由於單一 GPU 運算核心速度比 CPU 慢，因此較適合負責簡易並且 重複性高的運算。

圖 2-7 SIMD

目 前 GPU 運 算 有 兩 種 主 要 被 使 用 的 工 具 ， Compute Unified Device Architecture (CUDA)[13]及 Open Computing Language (OpenCL)[14]，CUDA 是 NVidia 所提出的技術，是該公司的 GPGPU 正式名稱。使用此項技術，將能利用 NVidia 的 GeForce 8 以後之 GPU 進行通用運算。OpenCL 是由一非盈利性技術組 織 Khronos Group 管理，OpenCL 為一異質性平台撰寫程式的框架，此異質性平 台可為 CPU 及 GPU 或是其他類型的處理器組成。只需要撰寫 OpenCL 的 kernel 語言，即可使用 GPU 運算。無論是 CUDA 或是 OpenCL，所有程式碼都會被轉 換成 PTX 編碼，再透過 GPU 計算。

以 OpenCL 為例，在 GPU 計算過程中需先由 CPU 編譯 .CL 的檔案，並且

14

將 GPU 建立以備後續計算所使用，再由主記憶體傳入所需要計算的資料到 GPU 記憶體中，當開始呼叫 GPU 計算時，GPU 將會利用先前儲存於記憶體中的資料，

利用 SIMD 的概念計算 .CL 檔案中的指令，計算完成後將會回傳結果到原先設 定的主記憶體中，達成一次計算過程，如圖 2-8。

圖 2-8 GPU 計算流程

由於 GPU 核心數量多，利用 SIMD 的方式計算即可達到有效的平行運算，

因此需要符合單一指令多資料計算的條件，但又因為 GPU 屬於外部裝置，資料 的傳送需要相當的時間，因此 GPU 適合計算重複性高且資料傳送小且資料間關 聯性低，運算量可於 GPU 內完成的計算，Apriori 也是屬於這類型的運算，由於 每一階候選項目的計算的方式是相同的因此重複性極高，並且資料傳送上只需要 將候選項目集傳入 GPU 即可，因此相當適合於 GPU 上使用，由於 GPU 的環境 尚未實現樹狀結構(Tree)的運算，並且樹狀結構的節點相互有關聯性，因此較不 易傳入 GPU 中運算。

2.5 Bitmap

Bitmap[6.7.9.18]是很多論文用來加快 Apriori 的方法，特別是在 GPU 運算的

15

時候被使用，通常 Bitmap 是用來儲存 TID 表格的一種方法，需要先建立最大物 品清單能夠儲存的空間，例如表 2-4 的交易資料庫中有 4 筆訂單，將會使用 4 bit 的空間儲存每項物品的交易資料，並且將訂單出現的編號設為 1，未出現的設為 0，如表 2-5，物品 A 只有在 T1 及 T2，因此物品 A 將會轉換成 0011，也等於 3 作為儲存，而物品 B 則會被轉換成 0111，等於 7。利用此方法儲存在計算時可以 使用 AND 的方式檢查是否為共同的交易筆，例如 A 和 B 的 AND 為 0011，則有 兩個為 1，代表有兩筆交易筆數中都有 A 和 B 物品，如圖 2-9 所示。

圖 2-9 AND 範例圖

表 2-4 交易資料庫表

交易編號 物品

T1 { A,B,C }

T2 { A,B }

T3 { B,D }

T4 { C,E }

16

表 2-5 資料庫轉換成 Bitmap 表格儲存

Bitmap

物品 T4 T3 T2 T1

A

B

C

D

E

但是此方法有一些缺點，例如，需要很多 Int 空間儲存一個物品的 Bitmap 資料、資料過於稀疏將會儲存很多 0 及 AND 後的 1 數量計算不易。當交易筆數 過大，例如交易筆數為 100K 筆，將要先產生 3125 個 32Bit 的 Int 陣列儲存 1 個 物品的交易資料，且每一個物品並非在每一筆交易中都會出現，因此會有大量的 0 被儲存。利用 AND 計算過後的數值，需要計算其 1 的數量不易。

2.6 GPU-FPM

GPU-FPM[19]使用 OpenCL 作為撰寫語言，並且使用頻繁樣式探勘演算法 Apriori 並且使用 Tid 的方法計算，並且將表格轉換成 Tid Value 和 Tid Index 兩陣 列儲存如圖 2-10，計算其相同訂單之數量，表 2-6 第二階候選項目，表 2-7 為運 算時所需要的 TID 表格，利用此演算法計算的方式為圖 2-11，每一個 GPU Thread 都分配一組候選項目，例如當 Thread 數量為 1024，則 GPU 一次處理 1024 個候 選項目，每個 Thread 需要計算多次，由於 K 階候選項目，當 K 大於等於 2 時，

則需要有多個物品清單需要檢查，並且每筆物品清單長度不一，因此每個 Thread 的運算時間相差過大，因此部分 Thread 需要等待其他 Thread 完成其運算工作後

17

才可以同時回傳結果，且此演算法將會有無法使用全部 GPU 核心的問題，GPU 核心數量眾多，使用的 Thread 數量因候選項目數量限制，例如：當資料量大時，

候選項目多則可使用較多的 GPU Thread，但又因負載不平衡失去加速的優勢；

又或資料量小時，候選項目少則無法有效的使用完所有 GPU Thread，造成不必 要的浪費，因此效能提升有限。

表 2-6 第二階候選項目

物品 次數

AB ?

AC ?

BC ?

表 2-7 TID 表格

物品

TID Value

A

B

C

圖 2-10 Tid Value 和 Tid Index 表格

18

圖 2-11 Parallel Frequent Patterns Mining Algorithm on GPU 計算範例

MATI 是一種使用 CPU 運算的方法，但是論文中提出一種新式的合併方式，

利用檢查兩高頻項目的前項物品，當物品相同時則代表可以合併，利用此方法可 以快速的合併出候選項目，因此後續使用此方法合併候選項目。

Bitmap 利用 AND 的邏輯運算可快速檢查候選項目的相同訂單數量，但當資 料越稀疏則儲存 0 的欄位越多，因此更加浪費記憶體；而 GPU-FPM[19]利用 Tid 的概念只需儲存高頻項目，因此記憶體較節省，但是卻因負載平衡較差而執行效 率較差，因此本文結合以上兩種演算法之優點，並 MATI 的合併方式提升運算速 度，並利用 Multi-GPU 達到更佳的運算效能。

19

第三章 研究方法

由於頻繁樣式探勘已被廣泛應用，在資料庫的資料量越來越多的情形之下，

需要使用更為快速的演算法來加速資料的運算，之前的章節中有提到兩種方法 Bitmap[6.7.9.18]及 GPU-FPM[19]，Bitmap 由於需要大量的記憶體空間作為儲存，

並且 AND 運算後由於是利用 Bit 的方式儲存，因此計算 1 的數量較為困難；而 GPU-FPM 則因為運算的項目依候選項目的不同而運算量不一，因此負載平衡較 差，由於 GPU 運算需要等待所有運算工作完成後才會回傳到 CPU 的主記憶體中，

當負載平衡不佳的狀況發生時，將會增加大量的等待時間而造成運算時間過長的 問題。

本論文結合了 GPU-FPM 以及 Bitmap 的優點，並利用 Multi-GPU 架構提出 Multi-GPU CSFPM 的演算法，由於 CSFPM 如同 GPU-FPM 只需保留符合高頻的 候選項目，因此記憶體使用較少，而運算部分利用 Bitmap 的平行運算方式，一 個 GPU Thread 只負責一個 Int 運算，能夠達成較佳的負載平衡，並且利用 MATI[16]

的合併方式快速合併出各項候選項目。單一 GPU 的運算效能會依 GPU 的速度限 制，當使用更多 GPU 協助運算，則可以得到較佳運算效能，因此利用優點較多 的 CSFPM 結合 Multi-GPU 概念，所完成的 Multi-GPU CSFPM 則可大幅度提升 運算效能。

3.1 候選項目切片及 GPU 平行運算方式(CSFPM)

Apriori 分為兩個重要的工作，一為「合併候選項目」，二為「檢查是否滿 足門檻值」

。「合併候選項目」使用 MATI 的合併方式，由於 MATI 的合併方式

20

方式，因此只剩下「檢查是否滿足門檻值」的工作。

在運算開始時需要先轉換 Apriori 的 Tid 格式並且將不屬於高頻的物品刪除，

而後將 Tid 的表格表 3-1 轉換成為 GPU-FPM 所使用的 Tid Value 及 Tid Index，

如圖 3-1，並且傳入 GPU 中。

表 3-1 資料庫轉換成 TID 表格儲存

物品

TID Value

A

B

C

圖 3-1 Tid Value 和 Tid Index 表格

Apriori 第一階是由 CPU 所完成的，並且利用 Tid Value 的數量檢查該物品是 否滿足高頻項目，從第二階運算開始才交由 GPU 負責檢查訂單是否相同，由於 第二階以後需要由前一階的高頻項目合併，合併的部分是由 CPU 使用 MATI 的 合併方式完成，在傳入 GPU 用運算。

CSFPM 將會對候選項目切割成更小單位平行於 GPU 的運算核心，一個 GPU Thread 只負責一個候選項目的物品 Tid Value 檢查， GPU 只需要檢查數字是否 相等，當數字發生大於的現象時則跳出該 Thread 運算時間，並且回傳 0，當等於

21

的狀況發生，則回傳 1，如圖 3-2。

表 3-2 計算候選項目次數

物品 次數

AB ?

AC ?

BC ?

圖 3-2 GPU 計算候選項目方法示意圖

第二階候選項目集{AB}、{AC}、{BC}，如表 3-2，分別的 Tid Value 如圖 3-1，因此傳入 GPU 後，GPU 的各 Thread 只需要將對應的物品 Tid Value 檢查後 並將結果存入 Output 陣列中，每個 GPU Thread 都有一個對應的 Output 陣列格 可以存放結果，例如: GPU Thread ID 0，分配到物品 A 的 TID Value 1，與物品 B 的完整 TID Value，GPU Thread ID １，分配到物品 A 的 TID Value 2，與物品 B 的完整 TID Value，GPU Thread ID 2，分配到物品 A 的 TID Value 1，與物品 C 的完整 TID Value，而每個 GPU Thread 都針對自有的資料檢查是否有相同數字，

如果有則輸出 1，如果沒有則輸出 0。例如物品 A 和 B 都擁有 1 和 2 的 TID Value，

22

則 GPU Thread ID 0 與 GPU Thread ID １都會輸出 1，而 GPU Thread ID 3，由於 物品 A 和物品 C 沒有共同的交易清單 2，則輸出 0，利用此輸出結果的陣列回傳 至 CPU 進行統計。

當一次運算完成時，例如圖 3-2 的運算結果為 1110100 的陣列回傳，由於物 品 A 的 Tid Value 為 2，物品 B 的 Tid Value 為 3，因此 Output 陣列的分段為 2 2 3，

第 0~1 陣列為候選項目{AB}，第 2~3 為候選項目{AC}，第 4~6 為候選項目{BC}，

只需要計算 1 的數量就可以得到個候選項目相同的訂單數量，如表 3-3。

表 3-3 計算候選項目次數

物品 次數

AB 2

AC 1

BC 1

3.2 CSFPM 演算法及流程圖

GPU 無法直接存取主記憶體中的資料，因此需要透過 CPU 的 I/O 將所需的 資料傳入 GPU 的記憶體中，GPU 的運算需要利用 CPU 編譯 OpenCL Kernel 建 立 GPU 的環境，所以 CPU 會將運算工作分配至 GPU 運算及資料的 I/O 中，如 圖 3-3 所示。而主要的候選項目檢查工作則是 GPU 負責，如圖 3-4 所示。

CPU: Main Function ( C++ )

Database is D, merge round is K, candidate itemsets in K round is Ck, Frequent pattern if Fk.

Ck is candidate patterns and more than 1.

Fk is frequent pattern and more than 1.

GPU thread is GT.

23

Input a threshold

Compile the .CL and build GPU device Scan and structure a Tid table

if ( the number of orders in any item < Threshold ){

Delete the item

}

Transform the Tid table into a Tid Value and Tid Index Allocate memory space in GPU for Tid Value and Tid Index Stores arrays Tid Value and Tid Index into GPU memory

For ( K = 2 ; ; K++ ){

Using MATI to generate Ck

Do {

If ( size of Ck > GT ){

Portion the Ck = PCk }

Allocate memory space in GPU for PCk Store PCk in GPU

Allocate memory space in GPU to save the results Wait until GPU finishes its program execution.

Calculate the number of nonzero entries of each PCk comparison.

If ( this number ≧ the threshold ){

The pattern is frequent and save into Fk

}

} while(size of Ck ≠ 0 )

If( candidate cannot be combine ) Break;

Else

Fk Combine the candidate to next level ( K+1 ).

}

圖 3-3 CSFPM 的 CPU 部分

24

GPU: Kernel Function ( .CL ) Receive the candidate

Int idx = get_glonal_id(0) // idx = GPU Thread id number Int gpu_thread_value = identify the corresponding Tid Value

if (gpu_thread_value == Tid Value of Other candidate pattern ){

result = 1;

}

Else if (gpu_thread_value > Tid Value of Other candidate pattern ){

result = 0;

}

圖 3-4 CSFPM 的 GPU 部分

25

開始

輸入門檻值

產生候選項目

計算候選項目 出現次數

次數是否大於或 等於門檻值

高頻項目 刪除該候選項目

否

是

是否可以再合併

是 否

結束 GPU的環境建置

CPU資料轉換成 TID表格

候選項目傳入GPU

計算結果回傳到CPU 記憶體

圖 3-5 Multi-core CPU 控制多 GPU 運算之流程圖

26

3.3 Multi-GPU 利用 CSFPM 運算之架構

單一 GPU 已經可以達到較佳的運算速度，如果擁有更多顯示晶片同時計算，

理應可以達到更好的結果。由於 CSFPM 的方法於 GPU 內部運算時，各 GPU Thread 無須與其他溝通，因此增加更多 GPU 也可正常的運作。但是並不適合使 用 CPU 的 Thread 方式切換，如圖 3-6，由於 Thread 切換需要時間，並且需要等 待運算到一段落時切換，時間不易拿掌握，例如不能在資料傳送的過程中切換，

以免資料傳輸過程出錯，因此利用單一 CPU 控制多 Thread 切換是較為困難實現，

並且也無法發揮最佳的運算效能。

圖 3-6 利用 CPU Thread 控制 Multi-GPU 運算硬體架構

利用相關研究中的 OpenMP 則可利用多核心運算，並且利用不同核心負責 控制對應的 GPU，以一對一的方式負責傳遞資料及回收運算結果，如圖 3-7，既 可減少運算資源的浪費，也可達成較佳運算效能。

27

圖 3-7 Multi-core CPU 控制 Multi-GPU 運算硬體架構

由於改成 Multi-GPU 的運算方式，因此原本的 CSFPM 演算法也需要修改，

如圖 3-5 所示，在建置 GPU 環境的過程中因其無法同時間建立，所以需要循序 將 GPU 的環境建置完成，包含 Kernel code 的編譯過程。

利用 OpenMP 修改的部分為:由於候選項目眾多，需要更多的 GPU 協助運算，

因此循序將各 GPU 的 Thread 填滿，開始 GPU 運算和等待 GPU 運算完成後，再 經由各 CPU Core 回收 GPU 的運算結果，並且計算各候選項目的出現次數。

Multi-GPU CSFPM 與 CSFPM 不同的地方，在加入了 OpenMP 分配工作，

由於只使用 OpenCL 無法控制多張 GPU，因此利用 OpenMP 建立一個 CPU 核心 控制一個 GPU，為此只需要修改部分演算法流程，如 OpenMP 控制不同核心的 CPU 分配工作到 GPU 中及回收運算結果，如圖 3-8 所示，而 GPU 的工作部分無 須修改依舊如同 CSFPM，如圖 3-9，即為 Multi-GPU CSFPM 演算法。

28

CPU: Main Function ( C++ )

Database is D, merge round is K, candidate itemsets in K round is Ck, Frequent pattern if Fk.

Ck is candidate patterns and more than 1.

Fk is frequent pattern and more than 1.

GPU thread is GT.

Input a threshold

For ( times of Multi-GPU number ){

Compile the .CL and build GPU device

}

Scan and structure a Tid table

if ( the number of orders in any item < Threshold ){

Delete the item

}

Transform the Tid table into a Tid Value and Tid Index Allocate memory space in GPU for Tid Value and Tid Index Stores arrays Tid Value and Tid Index into GPU memory

For ( K = 2 ; ; K++ ){

Using MATI to generate Ck

Do {

Using OpenMP to parallel computing

If ( size of Ck > GT ){

Portion the Ck = PCk }

Allocate memory space in GPU for PCk Store PCk in GPU

Allocate memory space in GPU to save the results Wait until GPU finishes its program execution.

Calculate the number of nonzero entries of each PCk comparison.

29

If ( this number ≧ the threshold ){

The pattern is frequent and save into Fk

}

} while(size of Ck ≠ 0 )

If( candidate cannot be combine ) Break;

Else

Fk Combine the candidate to next level ( K+1 ).

}

圖 3-8 Multi-GPU CSFPM 的 CPU 部分

GPU: Kernel Function ( .CL ) Receive the candidate

Int idx = get_glonal_id(0) // idx = GPU Thread id number Int gpu_thread_value = identify the corresponding Tid Value

if (gpu_thread_value == Tid Value of Other candidate pattern ){

result = 1;

}

Else if (gpu_thread_value > Tid Value of Other candidate pattern ){

result = 0;

}

圖 3-9 Multi-GPU CSFPM 的 CPU 部分

Bitmap 由於每個 GPU Thread 都只是相同運算量，並且利用 AND 的方式計 算，利用 AND 運算時需要將每一筆訂單資料互相對應，如有缺少或該筆訂單未 包含此商品，則需要儲存為 0，以達到物品訂單對應，正常的資料大多屬於稀疏 的交易訂單，因此需要浪費大量的記憶體儲存 0，而 GPU-FPM 只需要保留高頻 項目，所以記憶體較為節省，卻因每個候選項目的長度不一而造成負載平衡較為 不佳的情況。

30

本論文中提出了一種結合 Bitmap 及 GPU-FPM 的優點，並且利用 MATI 的 合併方式，達到更快速的 Apriori 演算法，並且利用 Multi-Core CPU 控制 Multi-GPU 運算，提升更快的運算效率，解決了單一 GPU 運算速度的核心運算 速度之限制。

31

第四章 實驗與結果分析

本章節將會描述實驗的結果及環境，將會分為與之前演算法比較以及多張 GPU 計算效能，比較運算效能的部分是與 Jiayi Zhou 學者所發表的論文 Parallel Frequent Patterns Mining Algorithm on GPU 做為比較的對象，以及比較 Bitmap 於 記憶體使用上的差別，於多張 GPU 運算部分也分為多項資料庫運算進行比較。

4.1 環境設定

為了確實驗證本研究(CSFPM)與所提的 GPU-FPM 演算法執行效能，故使用 同一軟硬體平台作為運算評估的平台，並且 OpenCL 也為 ATI 顯示卡公司主導，

因此使用 GPU 為 ATI Radeon HD 5850 並且使用 OpenCL 1.1 的 SDK，詳細軟硬 體規格如表 4-1。

表 4-1 與 GPU-FPM 相同規格的主機

項目 描述

CPU AMD Phenom II X4 965 3.4 GHz Memory 4G DDR3 memory

GPU ATI Radeon HD 5850 1G DDR5 OS Microsoft Windows 7

Compiler Microsoft Visual C++ 2008

SDK ATI Stream SDK 2.3 / OpenCL 1.1

於多張顯示卡平行運算的 GPU 使用 NVidia GTX 580，並且記憶體為 3G 的 版本，詳細軟硬體規格如表 4-2。

32

表 4-2 用於多張 GPU 運算主機

項目 描述

CPU Intel Core i7-3960X 3.3GHz Memory 16G DDR3 memory

GPU NVidia GTX 580 1536MB GDDR5 OS Microsoft Windows 7

Compiler Microsoft Visual C++ 2010 SDK Cuda 3.0 beta 1/ OpenCL 1.1

於比較的資料庫分為合成資料與真實資料兩種，合成資料使用 IBM 資料產 生器[2]產生，合成資料可隨需求設定各項參數如表 4-3，其中 T 代表資料交易的 平均長度；I 代表最大頻繁項目平均長度；D 代表交易筆數；N 代表物品項目數 量，例如：T10I4D100KN100K 資料，則可代表交易筆數有 100,000 筆，而每筆 資料的平均交易量為 10 項物品，並且整份資料庫內隱藏有最大頻繁項目的平均 值為 4，而且共有 100,000 項物品可供購買。

表 4-3 IBM 資料產生器的輸入項目

項目 描述 Description

T 資料平均交易長度 Avg. items per transaction.

I 最大頻繁項目平均長度 Avg. length of maximal pattern

D 交易筆數 Number of transactions

N 物品項目數量 Number of different items

真實資料庫是使用 Wenbin Fang 學者於 2009 年所發表的論文 Frequent Itemset Mining on Graphics Processors 中所使用的 Retail 以及 Chess 資料庫，Retail 為一匿名的比利時零售市場所交易的數據，交易筆數(D)為 88, 162 筆，並且交易 平均長度(T)為 10.3，物品項目(N)為 16469，並且資料密度較為稀疏。Chess 則是 相反特性的資料庫，其資料密度較緊密，並且物品項目(N)只有 75 筆，而平均交 易長度(T)為 37，並且每一筆交易長度都相同，而交易筆數(D)為 3,196 筆，如表。

33

表 4-4 用於比較的資料庫

資料庫名稱 T D N 類型

T10I4D100KN100K 10 100,000 100,000 合成 T10I4D1000KN1000K 10 1,000,000 1,000,000 合成

Retail 10.3 88,162 16,469 真實/稀疏

Chess 37 3,196 75 真實/緊密

4.2 單一 GPU 效能分析

在 這 個 實 驗 中 使 用 與 論 文 相 同 的 軟 硬 體 架 構 ， 並 且 輸 入 的 資 料 為 T10I4D100K 門檻值 200 (0.2%)，硬體架構及輸入資料如表 4-5。

表 4-5 用於與 GPU-FPM 比較的 T10I4D100K 門檻值 200 的運算平台與資料特性 CPU AMD Phenom II X4 965

GPU ATI Radeon HD 5850

T 10

I 4

D 100,000 N 100,000 門檻值 200

如圖 4-1 顯示，CSFPM 有效的改良 GPU-FPM 的執行速度，並且可以得到 約 2.6 倍的加速比，由於 GPU 的各核心速度較慢，故較不適合使用高運算量的 計算方式。

34

圖 4-1 T10I4D100K,T200 使用表 4-5 之主機運算結果

表 4-6 T10I4D100K 門檻值 200 的運算平台與資料特性 CPU Intel Core i7-3960X 3.3GHz

GPU NVidia GTX 580 1536MB GDDR5 記憶體

T 10

I 4

D 100,000 N 100,000 門檻值 200

由於 GPU-FPM 只使用單一張 GPU 作為運算，因此圖 4-2 為單一張 GTX 580 的運算時間比較如表 4-6，使用的資料庫為 T10I4D100K，門檻值 200，由於 GPU 的效能增加了，因此運算時間也相對縮短，但是 CSFPM 於 Thread 65536 運算時

Thread 256 Thread 512 Thread 1024

GPU-FPM 121.462 63.82 35.787

CSFPM 49.4804 26.183 13.756

0 20 40 60 80 100 120 140

T im e (se c.)

T10I4D100K,T200

35

可提升 1.4 倍的加速比。

圖 4-2 CSFPM 與 GPU-FPM 使用一張 GTX 580 於 T10I4D100K,T200 的比較 當門檻值下降為 100 時，候選項目集開始增加，但 CSFPM 依然有較好的加 速效果，於 Thread 為 16384 時還是擁有 1.22 的加速比，但是因為候選項目的數 量變多，CSFPM 的運算時間下降較快，因為此運算量都算小的運算量，每個核 心都可以負擔，因此分散於更多核心的加速效果將會更好，但是由於負載平衡較 為差，因此運算時存在著等待時間，因此運算效能較差。

Thread 256

Thread 1024

Thread 2048

Thread 4096

Thread 8192

Thread 16384

Thread 32768

Thread 65536 GPU-FPM 9.797 5.226 5.133 2.66 1.138 0.936 0.717 0.546

CSFPM 3.9 1.06 0.53 0.312 0.249 0.234 0.39 0.39

0 2 4 6 8 10 12

T im e (se c.)

T10I4D100K,T200

36

圖 4-3 CSFPM 與 GPU-FPM 使用一張 GTX 580 於 T10I4D100K,T100 的比較

利用不同的資料量，並且使用相同門檻值相同 Thread 數量之運算結果，於 圖 4-4 所示，T10I4DXK,T0.2%,Thread 16384，X 為變化的資料量，因資料量不 同其門檻值非固定常數，故使用 T0.2%表示，其代表意義為門檻值等於資料量乘 以 0.2%，例如資料量 100 k，則門檻值為 200。

圖中 GPU-FPM 於資料量 300K 以後並無法運算，GPU-FPM 利用𝑘個 for 迴 圈檢查物品出現次數，其運算複雜度為𝑛^𝑘，以 T10I4D300K,T0.2%為例，超過門 檻值的數量至少需要 600，其中𝑛為大於門檻值之常數在此範例為 600 以上，𝑘為 階層數量，由於 GPU 無法運算，因此一再出現錯誤訊息並且跳出 GPU 運算，故

Thread 4096

Thread 8192

Thread 16384

Thread 32768

Thread 65535

Thread 65538 GPU-FPM 142.598 80.073 44.86

CSFPM 60.996 37.393 36.769 43.112 64.197 61.074

20 40 60 80 100 120 140 160

T im e (se c.)

T10I4D100K,T100

37

GPU-FPM 無法正常運算，而後的數據將無法顯示。

圖 4-4 CSFPM 與 GPU-FPM 使用一張 GTX 580 於 T10I4DXK,T0.2%的比較

使用 OpenCL 不但可以於 ATI 的 GPU 中運算，也可利用 NVidia 的 GPU 中 提供相同運算功能。由以上各圖可知當需要運算的資料量較小時，GPU-FPM 及 CSFPM 都可以正常運算，但是 CSFPM 在以上的範例中都可以比 GPU-FPM 得到 較快的速度，並且 GPU-FPM 可運算的資料類型限制較多，以圖 4-4 為例，

GPU-FPM 只能夠運算至 200K 的資料量，而 CSFPM 卻可以正常地提供運算，因 此 CSFPM 更適合使用。

Size 100K

Size 200K

Size 300K

Size 400K

Size 500K

Size 600K

Size 700K

Size 800K

Size 900K

Size 1000K GPU-FPM 0.936 4.041

CSFPM 0.234 0.406 0.624 1.014 1.357 1.872 2.59 3.292 4.509 4.977 0

0.5 1 1.5 2 2.5 3 3.5 4 4.5 5 5.5

T im e (se c.)

T10I4DXK,T0.2%, Thread 16384

38

4.3Multi-GPU 運算效能分析

利用不同數量 GTX 580 進行加速，硬體及輸入資料如表 4-7。

表 4-7 T10I4D100K 門檻值 200 的運算平台與資料特性 CPU Intel Core i7-3960X 3.3GHz

GPU NVidia GTX 580 1536MB GDDR5 記憶體

T 10

I 4

D 100,000 N 100,000 門檻值 200

圖 4-5 是使用三張 580 同時運算相同 Thread，可以看出一開始增加 Thread 數量時即可得到部分加速效能，但是當使用越來越多的 Thread 執行時間越長，

由於資料傳入 GPU 後需要等待到有閒置的核心才能進行運算，而越多的工作堆 積在 GPU 中反而增加了等待時間，因此適量的選擇 Thread 可以達到更好的加速 效果，由此圖可得知 T10I4D100KN100K 最佳的 Thread 數量為 16385。

Thread 4096

Thread 8192

Thread 16384

Thread 16385

Thread 32767

Thread 32768

Thread 65536

CSFPM 0.201 0.169 0.166 0.164 0.276 0.284 0.311

0.15 0.17 0.19 0.21 0.23 0.25 0.27 0.29 0.31 0.33

T im e (se c.)

T10I4D100K,T200

39

圖 4-5 T10I4D100K，門檻值 200，使用 3 張 GTX 580 的不同 Thread 運算時間

每張 GPU 使用的 Thread 數量為 16385，如圖 4-6 顯示，當增加第二張 GTX 580 時可以得到 25%加速比，而在增加第三張時可以得到 40%加速比，可見增加 GPU 可以得到有效的加速效果。

圖 4-6 T10I4D100K，門檻值 200，Thread 為 16385 時使用張數不等的 GTX 580 運算時間

利用相同的資料 T10I4D100K，門檻值 100，並且利用三張 GTX 580 為計算 平台，其硬體及輸入的資料格式如表 4-8。

GTX580 X 1 GTX580 X 2 GTX580 X 3

CSFPM 0.23 0.184 0.164

0.15 0.16 0.17 0.18 0.19 0.2 0.21 0.22 0.23 0.24

T im e (se c.)

T10I4D100K,T200

40

表 4-8 T10I4D100K 門檻值 100 的運算平台與資料特性 CPU Intel Core i7-3960X 3.3GHz

GPU NVidia GTX 580 1536MB GDDR5 記憶體

T 10

I 4

D 100,000 N 100,000 門檻值 100

由圖 4-7 可看出 3 張 GTX 580 Thread 數量為 8192 時運算效能最佳，因此利 用 Thread 數量為 8192 時運算 1~3 張不等的 GTX 580 作為運算數據如圖 4-8。

圖 4-7 T10I4D100K，門檻值 100，使用 3 張 GTX 580 的不同 Thread 運算時間

Thread 4096

Thread 8192

Thread 16384

Thread 16385

Thread 32767

Thread 32768

Thread 65536 CSFPM 26.895 19.5 21.716 21.528 31.012 29.749 52.806

15 20 25 30 35 40 45 50 55

T im e (se c.)

T10I4D100K,T100

41

利用 GTX 580 1~3 張進行相同數據的運算 T10I4D100K，如圖 4-8 可以看出 增加第二張 GTX 580 時可以得到 50%的加速比，當增加第三張 GTX 580 時卻可 以得到 89%的加速比。

圖 4-8 T10I4D100K，門檻值 100，Thread 為 8192 時使用張數不等的 GTX 580 運算時間

利用資料量更大的資料庫 T10I4D1000K 門檻值 2000 作為運算的資料庫，其 硬體及輸入資料的特性如表 4-9。

表 4-9 T10I4D1000K 門檻值 2000 的運算平台與資料特性 CPU Intel Core i7-3960X 3.3GHz

GPU NVidia GTX 580 1536MB GDDR5 記憶體

T 10

I 4

D 1,000,000 N 1,000,000 門檻值 2000

GTX580 X 1 GTX580 X 2 GTX580 X 3

CSFPM 36.925 24.086 19.5

15 20 25 30 35 40

T im e (se c.)

T10I4D100K,T100

42

圖 4-9 可以看出使用 3 張 GTX 580 運算不同的 Thread 數量時，於 Thread 數 量為 131072 時速度最快，因此圖 4-10 將使用 Thread 數量為 131072 運算不同的 GTX 580。增加為兩張 GTX 580 時可以得到 22%的加速比，增加到第 3 張 GTX 580 時，即可增加到 47%加速比

圖 4-9 T10I4D1000K，門檻值 2000，使用 3 張 GTX 580 的不同 Thread 運算時間

Thread 8192

Thread 16384

Thread 16385

Thread 32767

Thread 32768

Thread 65536

Thread 131072

Thread 262144 CSFPM 0.468 0.358 0.406 0.312 0.312 0.359 0.234 0.421

0.2 0.25 0.3 0.35 0.4 0.45 0.5

T im e (se c.)

T10I4D1000K,T2000

43

圖 4-10 T10I4D1000K，門檻值 2000，Thread 為 131072 時使用張數不等的 GTX 580 運算時間

門檻值縮小則超過門檻值得資料將會增加，因此運算量也會相對增加，此測 驗是將 T10I4D1000K 門檻值縮小至 1000 (0.1%)，如表 4-10，並且測試最快速的 Thread 數量。

表 4-10 T10I4D1000K 門檻值 1000 的運算平台與資料特性 CPU Intel Core i7-3960X 3.3GHz

GPU NVidia GTX 580 1536MB GDDR5 記憶體

T 10

I 4

D 1,000,000 N 1,000,000 門檻值 1000

GTX580 X 1 GTX580 X 2 GTX580 X 3

CSFPM 0.344 0.281 0.234

0.22 0.24 0.26 0.28 0.3 0.32 0.34 0.36

T im e (se c.)

T10I4D1000K,T2000

44

如圖 4-11，使用 3 張 GTX 580 執行不同 Thread 數量，最佳的 Thread 數量為 32768，因此使用 32768 Thread 數量執行不同張數的 GTX 580 測試加速比，如圖 4-12，增加一張 GTX 580 可得 64%的加速比，如果再增加一張 GTX 580，則可 提升 1.11 的加速比，由於此運算量較多，GPU 可以得到更有效的加速，在三張 GTX 580 同時運算下已經可以得到 1 倍以上的加速比。

圖 4-11 T10I4D1000K，門檻值 1000，使用 3 張 GTX 580 的不同 Thread 運算時 間

Thread 16384

Thread 16385

Thread 32767

Thread 32768

Thread 65536

Thread 131072

Thread 262144 CSFPM 61.97 61.964 53.539 53.493 57.643 75.925 116.828

40 50 60 70 80 90 100 110 120

T im e (se c.)

T10I4D1000K,T1000

45

圖 4-12 T10I4D1000K，門檻值 1000，使用不同張數的 GTX 580 運算 Thread 32768

以上資料皆為 IBM 資料產生器所產生的資料庫，而後使用的 Retail 與 Chess 皆是真實資料。先是使用 Retail 作為輸入資料，其中資料庫與硬體架構如表 4-11，

並且利用不同 Thread 尋找最佳運算速度，最佳 Thread 數量為 131072，如圖 4-13。

表 4-11 Retail 門檻值 1%的運算平台與資料特性 CPU Intel Core i7-3960X 3.3GHz

GPU NVidia GTX 580 1536MB GDDR5 記憶體

T 10.3

D 88,162 N 16,469

門檻值 1%

GTX580 X 1 GTX580 X 2 GTX580 X 3

CSFPM 112.82 68.749 53.368

40 50 60 70 80 90 100 110 120

T im e (se c.)

T10I4D1000K,T1000

46

圖 4-13 Retail，門檻值 1%，使用 3 張 GTX 580 的不同 Thread 運算時間 圖 4-14 是 Retail 門檻值 1% 並且使用數量不等的 GTX 580 於 Thread 數量 為 131072 時運算的結果，從圖上可得知，增加一張 GTX 580 可得 62% 加速比，

而增加到第三張時就可增加到 1.08 的加速比，即可縮短一倍的運算時間。

圖 4-14 Retail，門檻值 1%，使用不同張數的 GTX 580 運算 Thread 131072

Thread 4096

Thread 8192

Thread 16384

Thread 16385

Thread 32767

Thread 32768

Thread 65536

Thread 131072

Thread 262144 CSFPM 3.354 3.182 3.51 3.526 7.426 7.924 2.699 2.075 5.834

1 2 3 4 5 6 7 8

T im e (se c.)

Retail,T1%

GTX580 X 1 GTX580 X 2 GTX580 X 3

CSFPM 4.335 2.672 2.081

2 2.5 3 3.5 4 4.5

T im e (se c.)

Retail,T1%

47

Chess 資料庫的資料特性為資料緊密，並且重複性高，當門檻值為 70%時已 經需要合併至第 13 階才為最終的高頻項目集，其資料庫特性如表 4-12，由圖 4-15 可得知 131072 為最佳 Thread 數量，由於再增加 Thread 數量會使系統開始出現 錯誤狀況，因此無法再增加 Thread 數量。

表 4-12 Chess 門檻值 70%的運算平台與資料特性 CPU Intel Core i7-3960X 3.3GHz

GPU NVidia GTX 580 1536MB GDDR5 記憶體

T 37

D 3,196

N 75

門檻值 70%

圖 4-15 Chess，門檻值 70%，使用 3 張 GTX 580 的不同 Thread 運算時間 利用 Thread 數量 131072 並且使用不同張數的 GPU GTX 580，計算 Chess 門檻值 70%，使用兩張 GTX 580 可以得到 65%的加速比，而使用三張 GTX 580

Thread 4096

Thread 8192

Thread 16384

Thread 16385

Thread 32767

Thread 32768

Thread 65536

Thread 131072 CSFPM 327.469 127.468 73.145 73.232 39.787 39.766 29.341 27.419

0 50 100 150 200 250 300 350

T im e (se c.)

Chess,T70%

48

就可以得到 1.1 倍的加速比，由於運算量很大，因此在 GPU 內部的時間很長，

故可以得到更好的加速比，如圖 4-16 所示。

圖 4-16 Chess，門檻值 70%，使用不同張數的 GTX 580 運算 Thread 131072

於 GPU-FPM 可運算的資料中，CSFPM 都有 1.2 以上的加速比，並且 GPU-FPM 於單一核心運算量過大時將會出現錯誤的狀況，而 CSFPM 利用 GPU 核心數量多的特點，減少一次 for 迴圈的使用，有效的減少了單一核心運算量的 問題，並且從以上各圖可顯示出當資料運算量大時，使用 3 張 GTX 580 的加速 比是很好的，但是由於 Thread 數量不固定，因此在使用前須估計 Thread 的數量，

並且可以從圖上可得知 Thread 越多不一定可以得到越快的運算速度，因為 Thread 數量越多，則一次傳入 GPU 記憶體的數量越大，但是等待 GPU Core 有空閒時 間時才能計算，因此延遲時間越長，但是使用多張 GPU(本實驗最多使用到 3 張) 是可以達到一定量的加速比，以 Chess 為例，三張 GTX580 可提升約兩倍的加速 比。不論資料量大小以及資料的特性，例如 T10I4D100K 門檻值 100 或 200，甚 至 T10I4D1000K 以及真實資料 Retail 及 Chess，由於 Retail 是屬於較稀疏的資料，

GTX580 X 1 GTX580 X 2 GTX580 X 3

CSFPM 57.692 34.928 27.415

25 30 35 40 45 50 55 60

T im e (se c.)

Chess,T70%

49

其運算的 Thread 較不固定，運算時間起伏較大，但是 Chess 則是較密集的資料，

使用不同的 Thread 運算時間較為平滑，也較為直覺。

50

第五章 結論與未來展望

頻繁樣式探勘是一個很重要的問題，而 Apriori 演算法因資料量增加，或是 門檻值過小，其運算時間將會增加很多，由於 GPU 是一種核心數量多的平行運 算裝置，但是演算法不能直接轉移，由於 GPU 不宜計算樹狀結構，因此並非所 有問題都可以使用 GPU 解決，但是 GPU 擁有大量的運算核心，使用 GPU 解決 適合 GPU 環境的問題即可得到較佳的加速比。

在本研究中提出了兩種方法，一為 CSFPM，二為 Multi-GPU CSFPM，CSFPM 結合三種演算法的優點，利用 Bitmap 的負載平衡概念計算，並利用 GPU-FPM 的儲存方式以節省不必要的空間，並且利用 MATI 的合併方式，解決檢查重複及 達到快速合併的演算法，因此 CSFPM 是一種較佳的演算法，並且提出 Multi-GPU 的運算方式，以解決單一 GPU 運算效能的限制，並且使用 OpenMP 達到控制 Multi-Core CPU 控制不同 GPU 的方式完成 Multi-GPU 的實作。

由於 CSFPM 是將候選項目切割成片狀，利用 GPU 的 SIMD 的運算方式，

每一切片都交由一 GPU Thread 計算，與 GPU-FPM 相比當使用 ATI Radeon HD5850，資料庫為 T10I4D100K 門檻值 200，加速比最高可得 2.6 倍，以 Mulit-GPU 而言，最高又可得 1 倍的加速比，由於每個 GPU Thread 運算項都減少，並且達 到較佳的負載平衡，並且 GPU-FPM 利用兩個 for 迴圈檢查候選項目的相同訂單 次數會使於單一核心運算量過大，例如門檻值 1000，則單一核心將至少需要執 行 1000 x 1000 次的檢查，當門檻值更高時，檢查次數將會更多，因此將會出現 無法運算的狀況。

由於目前的 Mulit-GPU 是使用相同的 GTX 580 三張，如果可以使用不同的 GPU，可能會遇到不同的 GPU 的運算效能不同，則會發生等待的狀況發生，因

51

此需要針對不同 GPU 的運算效能分配不同數量的候選項目，以達到異質性 GPU 之更佳運算效能，則此演算法將可運算於更多元的環境。

52

參考文獻

[1] R. Agrawal, and R. Srikant, “Fast algorithms for mining association rules,”

International Conference on Very Large Data Bases, pp. 487-499, 1994.

[2] R. Agrawal, and R. Srikant, “Quest Synthetic Data Generator”. IBM Almaden Research Center, San Jose, California, 2009.

[3] ATI. "Stream SDK," http://developer.amd.com/gpu/ATIStreamSDK/.

[4] Christian Bohm, Robert Noll, Claudia Plant, et al., “Data Mining Using Graphics Processing Units,” Transactions on Large-Scale Data- and Knowledge-Centered

Systems I, pp. 65-90, 2009.

[5] Sergey Brin, Rajeev Motwani, Jeffrey D. Unman and Shalom Tsur, “Dynamic itemset counting and implication rules for market basket data” ACM SIGMOD international conference on Management of data, vol. 26 Issue 2, pp. 255-264, June 1997.

[6] Wenbin Fang, Ka Keung Lau, Mian Lu et al., “Parallel Data Mining on Graphics Processors,” Technical report, Hong Kong University of Science and Technology, 2008.

[7] Wenbin Fang, Mian Lu and Xiangye Xiao et al., “Frequent Itemset Mining on Graphics Processors” The Fifth International Workshop on Data Management on New Hardware, 2009.

[8] J. Han, J. Pei, Y. Yin et al., “Mining frequent patterns without candidate generation: A frequent-pattern tree approach,” Data Mining and Knowledge

Discovery, vol. 8, no. 1, pp. 53-87, 2004.