2014-03-31 23 views
0

我正在分析一個呼叫詳細記錄的大型數據集。我從mysql數據庫中獲取詳細信息,並提取用戶和通話時間詳細信息,並彙總每個用戶的通話時間總和。使用opencl parallel progarmming分析CDR

我分配了10000000個大小的輸出緩衝區來存儲輸出結果,並調用了從mysql數據庫得到的全部數據的內核。在內核中,我使用原子加法來總結特定用戶的持續時間。

在籽粒代碼

atomic_add(&outputbuffer[userid],duration) 

它完美。

但我擔心大輸出緩衝區分配。即使要獲得100000個數據集的結果,我們也必須通過整個輸出內存。

難道我們不能在內核中做「哈希映射」類的東西嗎?我們如何使用「映射減少」來解決這類問題。

每當我嘗試這種方法,我無法避免與並行進程衝突。

我經歷了許多教程和在這個網站上的問題與我的問題有關。但不幸的是,我無法得到任何有用的指南。

如果有人能提出解決這個問題的想法,那將會有所幫助。

在此先感謝。

回答

0

無論全局內存你分配將是一個問題的數量不同的用戶(賬號,電話號碼......取決於你怎麼想總結一下通話時長),你的列表的數量的函數的CDR包含您的GPU支持的全局內存數量。

例如,GPU卡1GB內存上你也許能大約分配2.5億個32位計數器 - 可能少一點。這可能會或可能不足以爲您的完整批次呼叫記錄生成持續時間摘要。如果這還不夠,你將不得不小批量分批。可通過使用clGetDeviceInfo OpenCL API調用請求CL_DEVICE_GLOBAL_MEM_SIZE屬性來查詢可用的全局內存量。

使用更復雜的數據結構(如內核哈希映射)的問題是,在主機端執行的指針在設備端將毫無意義(OpenCL 2.0將在此處提供解決方案)。因此,無論您設想的哈希映射實現應該只使用其基數的整數偏移量而不是指針。然後,同步更新的同步問題仍然存在於同一個值中,但您可以像原始實施中那樣使用atomic_add。

根據您的一批呼叫數據記錄的特徵,您可能希望按帳戶,源電話號碼或其他密鑰進行排序,並且每個密鑰的CDR數量足夠多(商業客戶就是這種情況像一家大銀行),您可以在給定密鑰的CDR列表上應用減少技術,例如討論的here

希望這會給你一些想法。

+0

謝謝埃裏克。這非常有幫助。 – Jey