<story><title>Alenka: GPU database engine</title><url>https://github.com/antonmks/Alenka</url></story><parent_chain><item><author>nrjdhsbsid</author><text>I keep hearing the promise of GPU databases but they don&amp;#x27;t seem to be terribly useful for most real world workloads.&lt;p&gt;It reminds me of the big hoopla for GPU h264 encoders. When they came out everyone realized the quality was worse and not much faster.&lt;p&gt;Some things don&amp;#x27;t lend themselves to parallel processing, notably anything linear like transactions.&lt;p&gt;I mean yeah the GPU can sort a hundred billion items a second but how often do you really need to sort that many items using a database? In 99.9% of uses you have indexing or limits on the number of results.&lt;p&gt;Just saying, this program looks more like a stream processing platform with a SQL-like frontend than a full database</text></item></parent_chain><comment><author>arnon</author><text>You&amp;#x27;re thinking about transactional databases, and you&amp;#x27;re right. Transactional databases will probably not benefit hugely from a GPU.
That&amp;#x27;s not saying it&amp;#x27;s impossible, but probably not worth the effort.&lt;p&gt;However, there are so many types of databases around. Lambda architectures are all the rage now - you keep one database for your transactionals, and another for analytics. Analytics are huge, in the multi-billions of dollars every year and they&amp;#x27;ve become one of the most important parts of steering a business and deciding on new strategy.
Larger businesses don&amp;#x27;t just &amp;#x27;go for it&amp;#x27; anymore, they analyze, and inspect, and dig deep into their historical data to find out if something is worth doing.&lt;p&gt;GPUs tend to lend themselves well to analytics, contrary to transactions. Specifically, columnar databases. When the columns are all of the same data type, and the data locality is high, GPUs perform &amp;#x2F;very&amp;#x2F; well.&lt;p&gt;Regarding your sorting point you may not really want to sort everything, you got that bit right. But what if you want to perform a `JOIN` on a bunch of data?&lt;p&gt;It makes more sense to sort it first, because the JOIN would be much faster - matching keys would be much easier.&lt;p&gt;Now, if you were performing really fast SORT on a GPU, you&amp;#x27;re saving precious processing time.</text></comment>
<story><title>Alenka: GPU database engine</title><url>https://github.com/antonmks/Alenka</url></story><parent_chain><item><author>nrjdhsbsid</author><text>I keep hearing the promise of GPU databases but they don&amp;#x27;t seem to be terribly useful for most real world workloads.&lt;p&gt;It reminds me of the big hoopla for GPU h264 encoders. When they came out everyone realized the quality was worse and not much faster.&lt;p&gt;Some things don&amp;#x27;t lend themselves to parallel processing, notably anything linear like transactions.&lt;p&gt;I mean yeah the GPU can sort a hundred billion items a second but how often do you really need to sort that many items using a database? In 99.9% of uses you have indexing or limits on the number of results.&lt;p&gt;Just saying, this program looks more like a stream processing platform with a SQL-like frontend than a full database</text></item></parent_chain><comment><author>floatboth</author><text>&amp;gt; GPU h264 encoders&lt;p&gt;Are there any &lt;i&gt;GPU&lt;/i&gt; (shader) encoders?&lt;p&gt;There are dedicated fixed-function hardware encoders (VCE and NVENC) on graphics cards, and they&amp;#x27;re very popular, because they&amp;#x27;re the best way to record game footage if you don&amp;#x27;t have dedicated capture hardware. You don&amp;#x27;t want x264&amp;#x2F;5 hogging the CPU when you&amp;#x27;re playing games!</text></comment>