Earlier quoted context omitted.
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
For some reason I am surprised that anyone would want to ship the data whole and as is, to the GPU. Wouldn't it make more sense to use a representative, transformed "GPU-ready" data set, both much smaller in size & designed specifically for the queries that are to be optimized?
BlazingDB uses GPUs to manipulate huge databases in no time
31–40 of 76 posts
Re: BlazingDB uses GPUs to manipulate huge databases in no time
#32Several 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…
It would seem that rationalization would fall apart quickly with the new Power CPUs that have NVLink built right into the CPU. Getting data back and forth shouldn't be a problem anymore. Outside of CPU >> GPU, I'm not sure what other data movement you could be talking about. A SAS HBA or Ethernet NIC or Infiniband HBA are almost always going to be operating over the same PCIe bus the GPU uses. In the rare instances t…
Re: BlazingDB uses GPUs to manipulate huge databases in no time
#33The only thing that matters for them here is the aggregate, cross-sectional bandwidth to your data’s working set in memory. For databases, especially for the approach that many GPU databases take (light on indexes since GPUs aren’t great at data-dependent memory movement or pointer chasing, just brute-force scan much of the data), the working set size is something that will only fit in main memory.
Instead of using 8 GPUs with a peak global, cross-sectional memory b/w of 8 * 320 = 2560 GB/sec and brute-force scans, you can parallelize across ~40 CPU nodes each with ~60 GB/sec b/w to main memory. The cross-sectional bandwidth will be about the same, and the cost to split and join the results of the query is likely small in comparison to actually doing the work, assuming the intermediate results are reasonably small. You can use a broadcast and reduction tree; the added latency of the broadcast and reduction tree's depth likely won't add much, since there isn’t much data to broadcast in a query, and the data returned by each machine for the reduction is hopefully (!) tiny in proportion to the actual data scanned.
If you want to consider indices on data, then maybe the heads of that can remain resident in a CPU’s cache, and will make the individual CPU scans even faster. The GPU caches are tiny and mainly serve to patch up strided loads and other bad uses of memory.
Whether or not it’s worth it one way or another depends upon how large your database size is, the relative cost of GPUs versus CPU nodes to get the memory you want and the cross-sectional b/w you need, perf/W and other issues.
You’re probably nowhere near close to arithmetic throughput bounds on GPUs or CPUs since these workloads have very low op / byte loaded ratios compared to typical HPC workloads, so that aspect of GPUs doesn’t matter. If you’re doing expensive pre- or post-processing on GPUs as well, then that may push the balance more towards GPUs.
Re: BlazingDB uses GPUs to manipulate huge databases in no time
#34Earlier quoted context omitted.
It would seem that rationalization would fall apart quickly with the new Power CPUs that have NVLink built right into the CPU. Getting data back and forth shouldn't be a problem anymore. Outside of CPU >> GPU, I'm not sure what other data movement you could be talking about. A SAS HBA or Ethernet NIC or Infiniband HBA are almost always going to be operating over the same PCIe bus the GPU uses. In the rare instances t…
What is NVLink, and what does it mean in terms of data transfer?
Re: BlazingDB uses GPUs to manipulate huge databases in no time
#35Re: BlazingDB uses GPUs to manipulate huge databases in no time
#36Earlier quoted context omitted.
For some reason I am surprised that anyone would want to ship the data whole and as is, to the GPU. Wouldn't it make more sense to use a representative, transformed "GPU-ready" data set, both much smaller in size & designed specifically for the queries that are to be optimized?
Once you read and prune out the dataset to only include the relevant data, then what's left for the GPU to do?
Re: BlazingDB uses GPUs to manipulate huge databases in no time
#37Earlier quoted context omitted.
What is NVLink, and what does it mean in terms of data transfer?
It's a faster link between between future IBM POWER processors and NVidia GPUs, but won't make waves in database market since those systems are niche HPC/supercomputing hardware.
Re: BlazingDB uses GPUs to manipulate huge databases in no time
#38How 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.
We do cryptocurrency mining on an industrial scale and constantly see single bit errors from hardware that is brand-new without modifications. That's very surprising and interesting. How do you detect these single bit errors?
Detection of false negatives: Compare solution distribution and frequency to expected models; switch to debug kernels if outside tolerance.
However, this works because the mining problem space is stateless and follows strict mathematically predictable models.
A DB is stateful and the answers generally can't be verified without consulting a secondary copy, which is why I'm super curious how they would engineer correctness and reliability in a cost-effective way using GPUs.
Re: BlazingDB uses GPUs to manipulate huge databases in no time
#39Several 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…
Furthermore, all that memory bandwidth is calculated against all the cores. So you have to be VERY careful in usage patterns (it doesn't work like a giant CPU). Not to mention how much it costs involved per GB or TB!
I have some experience in this area, and where GPU's & database really shine is building (and especially) re-building indexes.
Running a database on GPUs isn't going to replace all DBs overnight. But, the hardware does have it's uses; just like improved SIMD on CPU's and NVMe storage, plus developments in networking - Basically look where Intel is going since we're coming to the limits of silicon transistors..
Re: BlazingDB uses GPUs to manipulate huge databases in no time
#40How 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?
SHA-256d (Bitcoin) and Scrypt (Litecoin) have ASICs, X11 (Dash - formerly Darkcoin) has FPGAs.