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

Postgres on the GPU

wiki.postgresql.org

Post reply on HN
Print view View original

31–40 of 79 posts

Re: Postgres on the GPU

#31

Post by oakwhiz »

jonknee wrote: post #21
rarrrrrr wrote: post #17

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

I think that he is referring to the tendency of GPU drivers to crash. Even if the DB is read-only from the GPUs' standpoint, if the DB goes down because of faulty drivers it's still a problem.

Re: Postgres on the GPU

#32

Post by spitfire »

I notice the GPU load time is about 53ms. This is a discrete graphics card so I do wonder how an integrated APU will affect this. I can imagine the overhead there being virtually nil.

The long term trend is for the GPU to merge with the CPU, so I think we'll see more of this in the future.

Re: Postgres on the GPU

#33

Post by lrem »

ludwigvan wrote: post #24
fixxer wrote: post #8

Earlier quoted context omitted.

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.

Are you aware of Sage [1]? It's a Python-based, batteries-included, integrated maths system. It is actually more popular than Matlab around the lab here. Incidentally, we don't get much funding from corporations (but yes, we have licenses for Matlab, Maple and Mathematica for everyone, just somehow Sage is more popular).

[1]: http://sagemath.org/

Re: Postgres on the GPU

#34

Post by jamesaguilar »

dljsjr wrote: post #25
smosher wrote: 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.

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

> "Because it's hard" is never a good excuse to not do something.

Well that's certainly not true in the general case.

Re: Postgres on the GPU

#35

Post by jacquesm »

guard-of-terra wrote: post #16
hippich wrote: 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.

Don't use hashing/bitcoinmining/password cracking as your benchmark if that is not your workload.

Re: Postgres on the GPU

#36

Post by guard-of-terra »

duskwuff wrote: post #26
guard-of-terra wrote: post #16

Earlier quoted context omitted.

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

Scrypt too? Because Nvidia performance on scrypt is bad either.

Re: Postgres on the GPU

#37

Post by jacquesm »

hippich wrote: 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.

CUDA is a lot more mature and easier to program for. OpenCL likely has the future, but it takes more work to set it up and if you have Nvidia cards it is harder to optimize.

Re: Postgres on the GPU

#38

Post by perlgeek »

All the examples seem to use numbers (integers and floats). It would be interesting to see if it can work efficiently with variable-width strings, which is the main workload that I encounter. But even if not, I see the value working with lots of data.

Re: Postgres on the GPU

#39

Post by dljsjr »

jamesaguilar wrote: post #34
dljsjr wrote: post #25

Earlier quoted context omitted.

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

> "Because it's hard" is never a good excuse to not do something. Well that's certainly not true in the general case.

On the contrary, I'd argue that it's not true in specific cases.

"Because it's hard" is a cop-out.

"It's too hard to accomplish given constraint [X]" where X is a deadline, financial constraints, or other real/tangible resource limitations might be one thing. But if you're working on your own timeline on some sort of open-source project, or there is nothing external preventing you from acquiring the expertise/resources to conquer the hard problem, then "Because it's hard" is an absolutely shitty excuse to not do something.

Re: Postgres on the GPU

#40

Post by smosher »

dljsjr wrote: post #25
smosher wrote: 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.

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

It's often a great excuse to do something else instead. If you can't get what you need done without the more difficult option, sure do it. But there's no sense in going down the harder path needlessly.

I'm not trying to convince you you don't need it or shouldn't do it, I was looking for a datapoint about what you find valuable in OpenCL.

Post reply on HN