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

71–79 of 79 posts

Re: Postgres on the GPU

#71

Post by pjmlp »

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

OpenCL is a standards compliant compute API that is supported by Nvidia, AMD, Intel, IBM, Sony, Apple, and several other companies. Nvidia is in the slow process of eventually discontinuing further CUDA support, and it is recommended to write new code in OpenCL only.

How come, given that only CUDA has direct support for C++ and FORTRAN compilers that target the GPU?

Re: Postgres on the GPU

#72

Post by pjmlp »

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.

It is the same story as OpenGL vs DirectX, it is all about the support the developers get from the vendors.

Re: Postgres on the GPU

#73

Post by sanxiyn »

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

there are matrix multiplication routines developed for CUDA. OpenCL you would have to do everything from the ground up. So Nvidia gave everyone a head start for numerical computation, and that edge has ever since snowballed.

You can use http://viennacl.sourceforge.net/ for OpenCL.

Re: Postgres on the GPU

#74

Post by m_mueller »

pjmlp wrote: post #71
DiabloD3 wrote: post #59

Earlier quoted context omitted.

OpenCL is a standards compliant compute API that is supported by Nvidia, AMD, Intel, IBM, Sony, Apple, and several other companies. Nvidia is in the slow process of eventually discontinuing further CUDA support, and it is recommended to write new code in OpenCL only.

How come, given that only CUDA has direct support for C++ and FORTRAN compilers that target the GPU?

Furthermore Python[1], Matlab[2], F#[3]. Furthermore parallel device debuggers (TotalView, Allinea), profilers (NVIDIA). There's a long way for OpenCL to catch up, if ever (because there might be a better standard coming further down the line).

[1] http://www.techpowerup.com/181585/NVIDIA-CUDA-Gets-Python-Su...

[2] http://www.mathworks.com/discovery/matlab-gpu.html

[3] https://www.quantalea.net/media/pdf/2012-11-29_Zurich_FSharp...

Re: Postgres on the GPU

#75

Post by qb45 »

hippich wrote: post #41
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

GPUs had been used for some kind of fuzzy string matching [1] and worked well thanks to their huge memory bandwidth.

[1] http://en.wikipedia.org/wiki/Smith%E2%80%93Waterman_algorith...

Re: Postgres on the GPU

#76

Post by jaakl »

The query sample is interesting: it seems to be find objects (locations) nearby given point. But there is CPU-only solution to index the data properly and have 1000x faster response times: PostGIS. So if before you threw more CPU/RAM if you did not know how to make things faster in smart way, then now you throw more GPU. Anyway, for sure there can be cases where GPU -based solution could be better alternative than using traditional existing solutions like specialized indexes.

Re: Postgres on the GPU

#77

Post by redtuesday »

robryan wrote: post #65
dljsjr wrote: post #39

Earlier quoted context omitted.

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…

Even if the long term goal is more portable GPU support it still makes some sense to get a CUDA implementation up first if it is easier to get to. It then allows real world testing faster, can always go to openCL later once they know more.

Just out of curiosity: how often did you see that happen (not only related to GPU's, but technologie decisions overall)? In my (little) experience the change at a later moment will not happen. Most of the time because the management has a new idea/project which you have to attend to.

Re: Postgres on the GPU

#78

Post by NuZZ »

oakwhiz wrote: post #31
jonknee wrote: post #21

Earlier quoted context omitted.

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.

On the flip side, if this is sufficiently adopted, it could present motivation to driver developers, thus improved drivers. Perhaps this and the linux gaming movement could mean some symbiosis for driver development.

Ignoring Windows as I guess I don't really take Windows servers too seriously.

Post reply on HN