Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

BlazingDB uses GPUs to manipulate huge databases in no time

techcrunch.com

Post reply on HN
Print view View original

61–70 of 76 posts

Re: BlazingDB uses GPUs to manipulate huge databases in no time

#61

Post by mcphage »

jandrewrogers wrote: post #8

Several 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…

> 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 good as what a CPU has and databases tend to be bandwidth bound. This is a real bottleneck and trying to work around it makes the entire software stack clunky.

How relevant is that when you're looking at multi-TB data sets that don't fit into computer RAM? Sure, the RAM CPU bandwidth may be very wide, but the SSD connects to the computer over the same PCIe bus.

And also: when did you have this conversation? GPU performance has changed very much year by year, so what wouldn't have been worth it 2 years ago might be a huge gain now.

Re: BlazingDB uses GPUs to manipulate huge databases in no time

#62

Post by mcphage »

hendzen wrote: post #4

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...

> This has been tried many times.

How many fewer cores, and how much less GPU RAM, and how much slower were GPUs in general when this was tried? They're changing quite rapidly—significantly faster than any other component in a modern PC. Any attempts more than 2 or 3 years ago aren't very relevant.

Re: BlazingDB uses GPUs to manipulate huge databases in no time

#63

Post by deafcalculus »

optimiz3 wrote: post #12

How 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.

Do you use compute shaders / CUDA? I'm really surprised at the error rate. I've used fragment shaders in OpenGL ES 2.0 for compute on mobile platforms, and the "errors" turned out to be dithering.

Re: BlazingDB uses GPUs to manipulate huge databases in no time

#64

Post by lightcatcher »

macromaniac wrote: post #51
hendzen wrote: post #4

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...

There was a paper a few months back in deep reinforcement learning that got record setting RL results using only a CPU [0]. Previously, these algorithms would play fewer games and run a gpu over and over on the few games they had played. By using a CPU you can generate more samples that are up to date with your learning algorithm. It sounds obvious in hindsight, but you can't exactly run 60 atari sims on a gpu. [0] -…

> It sounds obvious in hindsight, but you can't exactly run 60 atari sims on a gpu.

Why not?

It's certainly easier to run parallel Atari sims on CPU, because CPU programs are typically written as single-threaded or with parameterized number of threads.

Running parallel Atari on GPU is completely possible, with either running an Atari game on the each of ~30 SMs or each of the 32 * n_SMs ~= 1000 warps. However, because GPU code is typically written and delivered as kernels which utilize the full GPU, this type of embarrassing parallelism over SMs or warps typically can't be gained from using an existing library.

Re: BlazingDB uses GPUs to manipulate huge databases in no time

#65

Post by felipe_aramburu »

brianwawok wrote: post #9
sitkack wrote: post #7

Earlier 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.

Seems like a smarter response to me. Go ahead and use a GPU database if you want?? I have yet to see a good use case of one though.

We have seen many.

Big joins are our best use case. Joins are hard for many databases to optimize when they have not seen them before or are not "expecting" them like when you let amazon know how to partition your different tables onto the same physical machines so that redshift can return your query in a reasonble amount of time. But most SQL operations can be accelerated by the use of GPU's. Order by (holy smokes it helps), arithmetic or date transformations (20-30x for comparable cpu code), predicates, group by. All of these operations are happening over vectors of data. SIMD rock out when it comes to running these kinds of loads. The only use cases that we actually think are very poorly suited to gpus thus far (and this is a nut someone will one day probably crack) is wild card string searches. Some of our competitors handle this by caching all the data in GPU RAM but we consider that to be "cheating" since you would never be able to justify the pcie transfer to do wild card string searches.

Re: BlazingDB uses GPUs to manipulate huge databases in no time

#66

Post by scott_s »

jandrewrogers wrote: post #8

Several 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…

Fully agreed. I wrote a paper six years ago that came to the same conclusion: http://www.scott-a-s.com/files/debs2010.pdf

Re: BlazingDB uses GPUs to manipulate huge databases in no time

#67

Post by scott_s »

mcphage wrote: post #61
jandrewrogers wrote: post #8

Several 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…

> 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 good as what a CPU has and databases tend to be bandwidth bound. This is a real bottleneck and trying to work around it makes the entire software stack clunky. How relevant is that when you're looking at multi-TB data sets…

The difficulty with how most GPUs are connected to the rest of the system is that the data has to go RAM -> CPU -> GPU. If it could go directly RAM -> GPU, then the calculations would be better, but still not great as PCIe is still lower bandwidth and higher latency than RAM -> CPU.

It's not about GPU performance, it's about the latency and bandwidth of getting that dat to the GPU. If once you ship data to the GPU, you reuse it many times for many calculations, that cost is amortized and it doesn't matter as much. But if you ship data to the GPU and use it once, then that cost will probably not be amortized. I think of databases tending to fit in the latter category.

Re: BlazingDB uses GPUs to manipulate huge databases in no time

#68

Post by scott_s »

mcphage wrote: post #62
hendzen wrote: post #4

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...

> This has been tried many times. How many fewer cores, and how much less GPU RAM, and how much slower were GPUs in general when this was tried? They're changing quite rapidly—significantly faster than any other component in a modern PC. Any attempts more than 2 or 3 years ago aren't very relevant.

In my experiments in 2010, GPU speed was irrelevant. The GPU could had performed the calculations literally instantaneously, and the GPU still would have lost to the CPU by several orders of magnitude. Quoting myself, in some contexts, "data movement efficacy trumps raw computational power": http://www.scott-a-s.com/files/debs2010.pdf

Re: BlazingDB uses GPUs to manipulate huge databases in no time

#69

Post by mtweak »

optimiz3 wrote: post #38
n00b101 wrote: post #13

Earlier quoted context omitted.

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 positives: Run candidate solutions through the CPU 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 secondar…

We've been working on an interposing library for guaranteeing GPU computation and it would be great to get your feedback. Any chance we sync up? My email is in my profile.

Re: BlazingDB uses GPUs to manipulate huge databases in no time

#70

Post by [deleted] »

lightcatcher wrote: post #64
macromaniac wrote: post #51

Earlier quoted context omitted.

There was a paper a few months back in deep reinforcement learning that got record setting RL results using only a CPU [0]. Previously, these algorithms would play fewer games and run a gpu over and over on the few games they had played. By using a CPU you can generate more samples that are up to date with your learning algorithm. It sounds obvious in hindsight, but you can't exactly run 60 atari sims on a gpu. [0] -…

> It sounds obvious in hindsight, but you can't exactly run 60 atari sims on a gpu. Why not? It's certainly easier to run parallel Atari sims on CPU, because CPU programs are typically written as single-threaded or with parameterized number of threads. Running parallel Atari on GPU is completely possible, with either running an Atari game on the each of ~30 SMs or each of the 32 * n_SMs ~= 1000 warps. However, becaus…

[deleted]
Post reply on HN