This has been tried many times. Unless you are doing a computation with sufficient arithmetic intensity [0] the cost of shipping the data over PCIe and back dominates any gain you might get over a CPU. [0] - http://www.nersc.gov/users/application-performance/measuring...
BlazingDB uses GPUs to manipulate huge databases in no time
21–30 of 76 posts
Re: BlazingDB uses GPUs to manipulate huge databases in no time
#22How do they guarantee the correctness of results? A major problem with GPUs is you see single bit errors with surprisingly high frequency. For graphics this usually doesn't matter as a minor color or vertex deviation isn't noticeable, but for compute it can be devastating. We do cryptocurrency mining on an industrial scale and constantly see single bit errors from hardware that is brand-new without modifications.
It's surprising you can still do cryptocurrency mining with GPUs. Not bitcoin, then?
Re: BlazingDB uses GPUs to manipulate huge databases in no time
#23How do they guarantee the correctness of results? A major problem with GPUs is you see single bit errors with surprisingly high frequency. For graphics this usually doesn't matter as a minor color or vertex deviation isn't noticeable, but for compute it can be devastating. We do cryptocurrency mining on an industrial scale and constantly see single bit errors from hardware that is brand-new without modifications.
Re: BlazingDB uses GPUs to manipulate huge databases in no time
#24Re: BlazingDB uses GPUs to manipulate huge databases in no time
#25Sounds similar to what Netezza did with FPGA's but here with GPUs. So they may hit patents they say they are unaware of...
Re: BlazingDB uses GPUs to manipulate huge databases in no time
#26Earlier quoted context omitted.
You would need a GPU with an onboard SSD (exists). Or GPUs and drivers with the ability to talk directly to infiniband hardware (exists). Or the ability to not be ridiculously wasteful of existing resources (also exists). Your naysaying doesn't make you smart. Your naysaying makes you cut off from learning a different, better way of doing things.
Database workloads tend to be very branch heavy, e.g. string comparisons. If you've ever programmed a GPU you know that taking a data-dependent branch serializes the execution of the GPU stream processing units. So already the 70-100x benefit GPUs give on vectorized floating point workloads is greatly reduced. Add in the memory bandwidth penalty and it's a complete waste for IO intensive database workloads. Save the…
There have been some very sweet algorithms for doing B+ tree searches for Itanium and for AVX and those work just as well, if not better on GPU.
With some thinking, branch operations can be converted into math and applied to masses of data without checking for branch conditions. This wastes some work but is still faster than branching.
Re: BlazingDB uses GPUs to manipulate huge databases in no time
#27Several companies have implemented databases on GPUs but there is a good technical reason that the approach has never really caught on, and some of these companies even migrated to selling the same platform on CPUs only. The weakness of GPU databases is that while they have fantastic internal bandwidth, their network to the rest of the hardware in a server system is over PCIe, which generally isn't going to be as goo…
Is the data stored in GPU memory?
Re: BlazingDB uses GPUs to manipulate huge databases in no time
#28Earlier quoted context omitted.
Database workloads tend to be very branch heavy, e.g. string comparisons. If you've ever programmed a GPU you know that taking a data-dependent branch serializes the execution of the GPU stream processing units. So already the 70-100x benefit GPUs give on vectorized floating point workloads is greatly reduced. Add in the memory bandwidth penalty and it's a complete waste for IO intensive database workloads. Save the…
You can write code to compare strings without branches. Imagine comparing one string to every string in a database column. Pad to a fixed size first (if you find an ambiguous match later you can do a full string compare then). Subtract the strings, aka compare, and store the result. At the end of all the commparisons you have a memory structure of negative, zero, or positive values. Then you can do something with the…
In particular I mean sorting non-English text which any serious database needs to be able to do. Subtracting characters doesn't work when you're dealing language specific Unicode collation [0].
Re: BlazingDB uses GPUs to manipulate huge databases in no time
#29Several companies have implemented databases on GPUs but there is a good technical reason that the approach has never really caught on, and some of these companies even migrated to selling the same platform on CPUs only. The weakness of GPU databases is that while they have fantastic internal bandwidth, their network to the rest of the hardware in a server system is over PCIe, which generally isn't going to be as goo…
Is the data stored in GPU memory?
Re: BlazingDB uses GPUs to manipulate huge databases in no time
#30Earlier quoted context omitted.
Is the data stored in GPU memory?
Limiting your queries to ~12gb, the max ram on one GPU, (beyond which PCIe I/O becomes a bottleneck) will be a problem for business use, I'd think