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

51–60 of 76 posts

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

#51

Post by macromaniac »

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] - https://arxiv.org/abs/1602.01783

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

#53

Post by gaius »

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…

you don't want your engine to live on a coprocessor

Well yes and no. Both IBM and Oracle have gotten impressive performance using database-specific co-processors, but these are not GPGPUs, they are dedicated hardware that sits on the storage path. Baidu are reinventing that wheel with FPGAs too.

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

#54

Post by fasteo »

Every time I read about offloading work to the GPU, good old times come to my mind.

I vividly remember the Intel 8087, a math co-processor to the Intel 8086 that came out in 1980-1981. All the floating point arithmetic was offloaded to it.

It ended up disappearing as a separate chip with the Intel 80486 in the late eighties.

[1] https://en.wikipedia.org/wiki/Intel_8087

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

#55

Post by dspillett »

dharma1 wrote: post #44
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…

When did you ask? GPUs have been getting a lot faster year on year. Though, I would like to see Xeon Knights Landing compared to GPUs for db uses.

The data bandwidth between main memory and that which the GPU works with isn't speeding up by the same factors though. This is fine when working with a dataset that fits into the GPU's memory pool and your workload involves relatively few (or zero) changes because you can transfer it once and repeatedly ask the GPUs to analyse it in what-ever ways. As soon as the common dataset doesn't fit neatly into the GPU's RAM (leaving enough spare for scratch space) you end up thrashing the channel and it becomes the main bottleneck.

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

#56

Post by gaius »

fasteo wrote: post #54

Every time I read about offloading work to the GPU, good old times come to my mind. I vividly remember the Intel 8087, a math co-processor to the Intel 8086 that came out in 1980-1981. All the floating point arithmetic was offloaded to it. It ended up disappearing as a separate chip with the Intel 80486 in the late eighties. [1] https://en.wikipedia.org/wiki/Intel_8087

Also https://en.m.wikipedia.org/wiki/Original_Chip_Set#Copper

The good old days indeed!

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

#57

Post by valarauca1 »

tw04 wrote: post #20
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…

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…

>It would seem that rationalization would fall apart quickly with the new Power CPUs that have NVLink

NVLink has 80GB/s [1]. DDR4 quad channel (Xeon Servers) has ~120GB/s [2]. So no this rationalization doesn't fall apart. Furthermore in the event NVLink gets faster then RAM, then you'll still be bottlenecked by RAM access, as you'll buffer here.

This of course is ignoring weird systems where you attempt to maintain ACID coherence of tables between GPU, CPU, and Disk memory. But then GPU memory size become inherently limiting as even the biggest max out at ~32GB.

[1] https://en.wikipedia.org/wiki/NVLink

[2] http://www.corsair.com/en-us/blog/2014/september/ddr3_vs_ddr... (2channel -> 4channel x2)

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

#58

Post by valarauca1 »

tw04 wrote: post #20
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…

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…

>It would seem that rationalization would fall apart quickly with the new Power CPUs that have NVLink

NVLink has 80GB/s [1]. DDR4 quad channel (Xeon Servers) has ~120GB/s [2]. So no this rationalization doesn't fall apart. Furthermore in the event NVLink gets faster then RAM, then you'll still be bottlenecked by RAM access, as you'll buffer here.

This of course is ignoring weird systems where you attempt to maintain ACID coherence of tables between GPU, CPU, and Disk memory. But then GPU memory size become inherently limiting as even the biggest max out at ~32GB.

[1] https://en.wikipedia.org/wiki/NVLink

[2] http://www.corsair.com/en-us/blog/2014/september/ddr3_vs_ddr... (2channel -> 4channel x2)

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

#59

Post by dharma1 »

dspillett wrote: post #55
dharma1 wrote: post #44

Earlier quoted context omitted.

When did you ask? GPUs have been getting a lot faster year on year. Though, I would like to see Xeon Knights Landing compared to GPUs for db uses.

The data bandwidth between main memory and that which the GPU works with isn't speeding up by the same factors though. This is fine when working with a dataset that fits into the GPU's memory pool and your workload involves relatively few (or zero) changes because you can transfer it once and repeatedly ask the GPUs to analyse it in what-ever ways. As soon as the common dataset doesn't fit neatly into the GPU's RAM (…

That's true. There are some workarounds though, like distributing the workload between multiple GPUs - actively under development in machine learning for instance

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

#60

Post by _asummers »

velox_io wrote: post #39
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…

You pretty much hit the nail on the head, a big limitation is the feeding the GPUs in the first place. 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 especi…

I can definitely see value in offloading a bunch of number crunching on sufficiently large data sets to a graphics card (particularly parts that are trivially parallelizable). But to me, that seems like an optimization a database would make in its query planner, not one that you'd necessarily want to build an entire standalone product around.
Post reply on HN