Postgres on the GPU • Hacker News Board

Re: Postgres on the GPU

#41

Post by hippich » Tue, Apr 23, 2013, 5:47 PM UTC

perlgeek wrote: post #38

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.

GPU is good at calculating stuff (nVidia in particular at calculating floats.) I do not see reasons to do text stuff with GPU

Re: Postgres on the GPU

#42

Post by jamesaguilar » Tue, Apr 23, 2013, 5:48 PM UTC

dljsjr wrote: post #39

jamesaguilar wrote: post #34

Earlier quoted context omitted.

> "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/resour…

I suggest you read "It's too hard" when written by other developers as, "It's too hard [given that I spend N hours a week on this and would rather actually accomplish something in the next two months than learn the 'right' API]." Or, "It's too hard [given various constraints that I'm not going to explain to you but are valid to me.]" It'll save you having to give speeches about shitty excuses.

That said, if it makes sense for your project, make it happen! :)

Re: Postgres on the GPU

#43

Post by metrix » Tue, Apr 23, 2013, 6:13 PM UTC

Postgres on the GPU just screams HSA http://hsafoundation.com and more importantly AMD and their upcoming Kaveri processor. which will significantly reduce the latency of performing GPU calculations since the CPU and GPU will share the same cache.

Re: Postgres on the GPU

#44

Post by metrix » Tue, Apr 23, 2013, 6:16 PM UTC

smosher wrote: post #12

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

You go with OpenCL so that you can use AMD's Fusion processor that will start will soon allow a GPU and CPU to share main memory.

Re: Postgres on the GPU

#45

Post by mjn » Tue, Apr 23, 2013, 6:30 PM UTC

fixxer wrote: post #20

mjn wrote: post #9

Earlier quoted context omitted.

Matlab seems like inertia/culture to me: it's the longtime de-facto standard in engineering. Since it's what everyone uses, it's got packages for everything, and papers will often come with prototype Matlab implementations. Roughly like the cultural position R holds in statistics. Matlab's hold on engineering is also bolstered by its widespread use in industry: students want to learn it, because it's what their futur…

I've heard this argument a lot (since 1999), but I'm not confident it holds true anymore. The free alternatives are so good. You may be right regarding Professors, but that is also changing as they age out.

Could be; we don't use Matlab much in my own research area, so recent change could've happened under my radar. When I've occasionally had contact with engineers in industry, though, Matlab still seemed to be everywhere. The most recent two examples were someone doing DSP, and someone doing mechanical engineering, and both had all their stuff built on top of Matlab+Simulink.

Re: Postgres on the GPU

#46

Post by potkor » Tue, Apr 23, 2013, 6:32 PM UTC

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.

Nvidia software has always been much better than AMD. AMD on Linux is a complet disaster. So if you work on GPU it's natural to go Nvidia.

Re: Postgres on the GPU

#47

Post by nwhitehead » Tue, Apr 23, 2013, 6:43 PM UTC

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.

The fun part of parallel programming is getting things running on your GPU, parallelizing the algorithm, then tuning and optimizing the code. This is easier, faster, and more pleasant in CUDA with it's mature tools and ecosystem. That's why open source projects often use CUDA.

The advantage of OpenCL is that it runs on more platforms (not just NVIDIA). The problem is that it's more complicated and more of a headache.

My advice to programmers is to start with CUDA and play around with your problem for a while. Time spent learning how GPUs work, what kinds of operations are efficient, and how to parallelize algorithms is not wasted if you switch to OpenCL later. Once you've made some progress then make an informed decision about whether you want to go to production with CUDA or OpenCL.

Re: Postgres on the GPU

#48

Post by agnsaft » Tue, Apr 23, 2013, 6:43 PM UTC

This is cool, however, Postgres could probably achieve higher performance without the GPU as well if they added concurrency on the CPU for certain type of operations (e.g. aggregation, sorting, etc). That would be a killer feature.

Re: Postgres on the GPU

#49

Post by homerowilson » Tue, Apr 23, 2013, 6:44 PM UTC

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.

Nvidia uses ECC RAM on their GPU compute cards, an important consideration for serious HPC computing.

Re: Postgres on the GPU

#50

Post by mrb » Tue, Apr 23, 2013, 7:03 PM UTC

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

"AMD's advantage in Bitcoin mining was purely due to an architectural quirk"

False. I authored a Bitcoin miner utilizing this quirk (bit_align). I was also the first to leverage another instruction exclusive to AMD (bfi_int): https://bitcointalk.org/?topic=2949 bit_align "only" gave AMD a 1.7x advantage over Nvidia. The biggest perf gains (2x-3x!) came from the fact AMD has more execution units: https://en.bitcoin.it/wiki/Why_a_GPU_mines_faster_than_a_CPU... (I also authored this section of the wiki).