Live data from Hacker News

Postgres on the GPU

wiki.postgresql.org

21–30 of 79 posts

Re: Postgres on the GPU

#21

Brilliant! Perhaps it's just my scars showing, but I'm concerned about database system stability with active GPU hardware added to the box. I probably wouldn't add the GPU hardware to a master but rather do the queries that would benefit from it on a streaming replica, where an occasional kernel panic won't be so severe. Regardless, looking forward to trying it.

It's read only...

Re: Postgres on the GPU

#22
post #15
post #11

Earlier quoted context omitted.

NVidia funds a lot of academics in my space, and I've found academia to be very anti-open source for those reasons, which amuses me greatly. Wait, are you saying academia is anti-opensource because of nVidia funding?

I'm saying there is a systematic advantage to using proprietary technologies in academic research (companies have money, so you can write a grant and they will pay you $). Case in point, look at apps coming out of academia and you'll see a lot of WindowsPhone. It is because Microsoft gives away a ton of free phones (I have one on my desk at this moment) and Azure time.

Ok, that tracks better than it being something nVidia in particular did.

I don't see a serious problem with the scenario you describe, though. You're not really describing a hostile scenario, just an affinity for commercial software.

There is a bit of a problem of course; I find a lot of papers that describe how to do things with commercial technology that isn't in the budget. That hasn't been insurmountable for me in any way, but maybe others have had more serious problems with it.

Re: Postgres on the GPU

#23
post #12

Earlier quoted context omitted.

So why would you go with OpenCL? Is it portability? For a while I thought that was worth it but I am having a hard time remaining convinced of that.

I've been working on a rather large computation library using OpenCL. OpenCL is useful for providing an abstraction over multiple device types. If you are only interested in producing highly-tuned parallel code to execute on NVidia hardware, I suggest sticking to CUDA for the above reasons. I utilised the OpenCL programming interface to write code that would run the same kernel functions on CPU and/or GPU devices (us…

FYI regarding highly-tuned code -- An ex ATI/AMD GPU core designer told me that the price you pay for writing optimized code in OpenCL versus the device specific assembler is roughly 3x. Something to keep in mind if you're targeting a large enough system to OpenCL and you find spots that can't be pushed any faster.

Re: Postgres on the GPU

#24
post #8
post #2

NVidia's CUDA only (for now?) Anyone can explain why opensource projects embrace CUDA over OpenCL? As I understand OpenCL is more generic API which could be potentially used with CPUs and GPUs.

You're preaching to the choir. Looks like NEC funded this. NVidia seems to be the preferred hardware for institutions/big companies. I'm not sure if this is because NVidia's architecture is better for supercomputers or if they're simply better at marketing to those types of customers NVidia funds a lot of academics in my space, and I've found academia to be very anti-open source for those reasons, which amuses me gre…

The free alternatives are not so good for beginners. One of MATLAB's main strengths is the embedded editor + repl, whereas with Python/Numpy/Matplotlib stack, there are just too many moving parts. The environment of MATLAB can be emulated with ipython workbook or emacs, but I don't believe it is easy enough for beginners.

Re: Postgres on the GPU

#25
post #12
post #7

Earlier quoted context omitted.

There are probably a lot of factors. I worked on CUDA code for around a year, and used to understand the landscape pretty well, but if I were to start a high-performance computing project today I'd probably take my lumps and go with OpenCL. There would be a lot of lumps. Firstly, CUDA is just more mature; there is a very large and well-established set of libraries for a lot of common operations, there is a decent siz…

So why would you go with OpenCL? Is it portability? For a while I thought that was worth it but I am having a hard time remaining convinced of that.

Portability, accessibility, etc. "Because it's hard" is never a good excuse to not do something.

Re: Postgres on the GPU

#26
post #2

NVidia's CUDA only (for now?) Anyone can explain why opensource projects embrace CUDA over OpenCL? As I understand OpenCL is more generic API which could be potentially used with CPUs and GPUs.

Another question, is CUDA actually fast enough? Because in bitcoin mining, it's always ATI/AMD and OpenCL because ATI cards are like ten times faster than Nvidia cards. This is because of architecture differencies. Does it not affect this postgres table-scanning task? I wonder if they did any benchmarks.

AMD's advantage in Bitcoin mining was purely due to an architectural quirk: their shader cores supported bitwise rotation, but Nvidia's didn't. Bitwise rotation is a rare instruction outside of certain crypto algorithms (like SHA256!), so this really means very little for general-purpose performance.

http://www.extremetech.com/computing/153467-amd-destroys-nvi...

Re: Postgres on the GPU

#27
post #2

NVidia's CUDA only (for now?) Anyone can explain why opensource projects embrace CUDA over OpenCL? As I understand OpenCL is more generic API which could be potentially used with CPUs and GPUs.

Another question, is CUDA actually fast enough? Because in bitcoin mining, it's always ATI/AMD and OpenCL because ATI cards are like ten times faster than Nvidia cards. This is because of architecture differencies. Does it not affect this postgres table-scanning task? I wonder if they did any benchmarks.

This is because the hashing algorithm is highly dependent on integer rotate right instruction. AMD's implements it in 1 clock cycle, Nvidia in 3. So it's a special case.

Re: Postgres on the GPU

#28
post #2

NVidia's CUDA only (for now?) Anyone can explain why opensource projects embrace CUDA over OpenCL? As I understand OpenCL is more generic API which could be potentially used with CPUs and GPUs.

Another question, is CUDA actually fast enough? Because in bitcoin mining, it's always ATI/AMD and OpenCL because ATI cards are like ten times faster than Nvidia cards. This is because of architecture differencies. Does it not affect this postgres table-scanning task? I wonder if they did any benchmarks.

NVidia cards do not efficiently implement bit rotation, while AMD cards do, and it happens to be the core part of the SHA algorithm used for bitcoin. In general for an arbitrary task they're fairly close in performance.

Re: Postgres on the GPU

#29
post #2

NVidia's CUDA only (for now?) Anyone can explain why opensource projects embrace CUDA over OpenCL? As I understand OpenCL is more generic API which could be potentially used with CPUs and GPUs.

Another question, is CUDA actually fast enough? Because in bitcoin mining, it's always ATI/AMD and OpenCL because ATI cards are like ten times faster than Nvidia cards. This is because of architecture differencies. Does it not affect this postgres table-scanning task? I wonder if they did any benchmarks.

That is really interesting. I had to look it up.

https://en.bitcoin.it/wiki/Mining_hardware_comparison

The fastest Nvidia showing is the Tesla S2070 which is a $18k Server with 8 GPU's! It can just barely keep up with a slightly over clocked single gpu HD7970.

Re: Postgres on the GPU

#30
post #12
post #7

Earlier quoted context omitted.

There are probably a lot of factors. I worked on CUDA code for around a year, and used to understand the landscape pretty well, but if I were to start a high-performance computing project today I'd probably take my lumps and go with OpenCL. There would be a lot of lumps. Firstly, CUDA is just more mature; there is a very large and well-established set of libraries for a lot of common operations, there is a decent siz…

So why would you go with OpenCL? Is it portability? For a while I thought that was worth it but I am having a hard time remaining convinced of that.

Well, the portability can be a killer feature. I've been writing quite a bit of OpenCL code lately. I have an AMD GPU, so CUDA is a non-starter. I'll eventually replace the AMD card with an NVIDIA one, so it won't be as big of a problem, but my OpenCL code will still be fine then.
Post reply on HN