我一直在閱讀關於Nvidia Cuda的文章，並且我看到過一些關於人們已經回答了一些問題，他們在這裏回答了「你的問題不適合在GPU上運行」的評論。Nvidia Cuda計劃 - 我的Cuda適合Cuda架構嗎？
在我的辦公室，我們有一個數據庫，其中有大量的記錄，我們查詢到，它可以永遠。我們已經實現了SELECT DISTINCT的SQL查詢，或者它們對值應用了一個大寫函數。作爲Cuda的介紹，我想寫一個可以在GPU上採用所有字符串並將其大寫的程序。
我一直在讀一本關於Cuda的書，作者談論了試圖儘可能多地執行GPU內核，以便隱藏通過PCI總線讀取數據或將內容放入全局內存的延遲。由於內存大小非常小，並且由於我擁有數百萬個不同的單詞，因此我自然會飽和總線並使GPU內核捱餓。
這是一個問題，不會從顯卡獲得奇妙的性能提升，而不是CPU嗎？
感謝，
MJ
我們已經實現了SQL查詢SELECT DISTINCT或者它們對值應用了大寫函數。
你有沒有考慮在你的表中添加一個列，預先計算你的字符串的大寫版本？
我傾向於認爲，如果您的數據庫完全在RAM中，並且查詢仍然「永遠」，那麼您的數據庫可能沒有正確的結構和索引。檢查你的查詢計劃。
我認爲，在正常情況下，您的選擇被索引整齊地覆蓋，您將無法使用GPU進行優化。但也許有些東西可以針對GPU進行優化，比如需要表掃描的查詢，例如帶通配符的LIKE查詢以及基於計算選擇行的查詢（值小於等）。當連接列有許多重複的值時，甚至可能包含許多連接的查詢。
這種實現的關鍵在於保留GPU上數據庫中的一些數據的鏡像並使其與數據庫保持同步。然後對這些數據運行諸如並行減少操作之類的操作，以獲得行ID，然後用於對照常規數據庫進行選擇。
在採取這一步驟之前，我會探索使用空間時間折衷的數據庫查詢優化的無數可能性。
我會說計算LIKE查詢可能會導致在GPU上分支太多，非常有效。 – 2012-04-12 15:52:39
你將不得不因爲你的操作在全局內存訪問一個相當大的瓶頸/轉移比爲O（1）。
在GPU上進行比較可能更有價值，因爲它具有更大的操作/傳輸比率。
當你將一個字符串加載到共享內存中來做到這一點時，你也可以利用它，有效地包括你之前想做的事情，以及更多。
我不禁感到基於CPU的實現可能會給你更好的性能。它至少可以減少頭痛的發生......
查詢時間大部分時間不是由於磁盤I/O的速度所致？如果答案是肯定的，那麼減少查詢時間的唯一方法是提高I/O吞吐量。 GPU不能幫上忙。 – talonmies 2012-04-11 14:01:13
你完全正確。讓我們再添加一個假設，即我正在一臺裝有64個RAM的服務器上，並試圖將所有數據保存在內存中。 – 2012-04-11 14:26:57
仍然沒有。你的任務在計算上並不昂貴，但是內存昂貴。因此GPU不是一個好選擇。如果您已將數據存儲在內存中，則OpenMP可能更適合。 – Azrael3000 2012-04-11 14:32:55