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

11–20 of 76 posts

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

#11

Post by cowsandmilk »

sitkack wrote: post #7
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...

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.

BlazingDB is advertising as being run on AWS, Azure, Softlayer; do the GPUs on these systems have these hardware features?

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

#12

Post by optimiz3 »

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.

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

#13

Post by n00b101 »

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.

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?

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

#14

Post by hendzen »

sitkack wrote: post #7
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...

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 GPUs for training neural nets and physics simulations. When the fundamental hardware capabilities of GPUs make them worth investing in for database workloads, I'll change my opinion. Until then, any budget for expensive DB hardware is much better spent on NVMe storage.

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

#15

Post by loeg »

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.

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

#17

Post by glangdale »

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.

I am reminded of a Jack Vance quote, where one of the characters is "capable of performing complex calculations in his head and furnishing the results in an instant, whether they are right or wrong".

I cannot find any reference to handling of soft errors in their material. One rather banal approach is to do everything twice and check the results; effective, but I'm not sure that they do this. They may be simply putting their heads in the sand.

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

#18

Post by AlsoN00b »

n00b101 wrote: post #13
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.

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?

Not OP but a lot of this seems pretty believable and easy to detect to me?

Dont the GPU specs allow for a certain lossiness in the math? Or like, at least they don't conform to IEEE 794 float specs w/ regard to order of operations, precision, degradation, etc.

So like, do a shitload of math ops in a glsl shader with a deterministic outcome, render the result to a texture, take the texture back and make sure the RGBA values match bit for bit with the numbers you expected?

Or to detect single bit errors in the gpu's local memory or caching just attach textures, read data into them, read it back, render back, etc etc.

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

#19

Post by kusmi »

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…

Is the data stored in GPU memory?

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

#20

Post by tw04 »

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 they're built onto the CPU, the "network link" is likely going to still be significantly slower than the fastest PCIe slot.

Post reply on HN