Thread: Will PostgreSQL get ported to CUDA?

Will PostgreSQL get ported to CUDA?

From
"Dann Corbit"
Date:
<div class="Section1"><p class="MsoNormal"><font face="Arial" size="2"><span style="font-size:10.0pt;
font-family:Arial"><a
href="http://www.scientificcomputing.com/ShowPR~PUBCODE~030~ACCT~3000000100~ISSUE~0801~RELTYPE~HPCC~PRODCODE~00000000~PRODLETT~C.html">http://www.scientificcomputing.com/ShowPR~PUBCODE~030~ACCT~3000000100~ISSUE~0801~RELTYPE~HPCC~PRODCODE~00000000~PRODLETT~C.html</a></span></font><p
class="MsoNormal"><fontface="Arial" size="2"><span style="font-size:10.0pt; 
font-family:Arial"><a
href="http://www.nvidia.com/object/cuda_learn.html">http://www.nvidia.com/object/cuda_learn.html</a></span></font><p
class="MsoNormal"><fontface="Arial" size="2"><span style="font-size:10.0pt; 
font-family:Arial"><a
href="http://www.nvidia.com/object/cuda_get.html">http://www.nvidia.com/object/cuda_get.html</a></span></font><p
class="MsoNormal"><fontface="Arial" size="2"><span style="font-size:10.0pt; 
font-family:Arial"> </span></font><p class="MsoNormal"><font face="Arial" size="2"><span style="font-size:10.0pt;
font-family:Arial"> </span></font></div>

Re: Will PostgreSQL get ported to CUDA?

From
Simon Riggs
Date:
On Tue, 2008-01-29 at 22:12 -0800, Dann Corbit wrote:
>
http://www.scientificcomputing.com/ShowPR~PUBCODE~030~ACCT~3000000100~ISSUE~0801~RELTYPE~HPCC~PRODCODE~00000000~PRODLETT~C.html
> 
> http://www.nvidia.com/object/cuda_learn.html
> 
> http://www.nvidia.com/object/cuda_get.html
> 

I assume you mean to have interesting CPU-intensive tasks offloaded to
the GPU, rather than full-porting...

I looked into this and it seems like an innovative plan technically, but
most servers running PostgreSQL don't have a GPU. So it makes it more a
personal computer opportunity rather than a business server one, no?

Plus I wouldn't look at it ahead of a debugger being available.

If you wrote a CUDA function to perform a useful operation that might be
a good starting place to general understanding of how we might use this
in the future. PostgreSQL is extensible, so an add-in function might be
a useful module on pgfoundry. 

Maybe we could build in a hook to allow an external-function library to
provide sort capability... but I don't think anyone is going to take it
seriously for database core without a greater than normal amount of test
results and prototypes.

--  Simon Riggs 2ndQuadrant  http://www.2ndQuadrant.com 



Re: Will PostgreSQL get ported to CUDA?

From
Tom Lane
Date:
"Dann Corbit" <DCorbit@connx.com> writes:
> http://www.nvidia.com/object/cuda_get.html

The license terms here seem to be sufficient reason why not.
        regards, tom lane


Will PostgreSQL get ported to CUDA?

From
"Christopher Browne"
Date:
2008/1/30 Dann Corbit <DCorbit@connx.com>:

http://www.scientificcomputing.com/ShowPR~PUBCODE~030~ACCT~3000000100~ISSUE~0801~RELTYPE~HPCC~PRODCODE~00000000~PRODLETT~C.html
>
> http://www.nvidia.com/object/cuda_learn.html
>
> http://www.nvidia.com/object/cuda_get.html

Someone at CMU has tried this, somewhat fruitfully.

http://www.andrew.cmu.edu/user/ngm/15-823/project/Draft.pdf
http://www.andrew.cmu.edu/user/ngm/15-823/project/Final.pdf

This was based on GPUSort:
http://gamma.cs.unc.edu/GPUSORT/

Unfortunately, the licensing of GPUSort is, if anything, more awful
than that for CUDA.
http://gamma.cs.unc.edu/GPUSORT/terms.html

This would need to get pretty totally reimplemented to be useful with
PostgreSQL.  Happily, we actually have some evidence that the exercise
would be of some value.  Further, it looks to me like the
implementation that was done was done in a pretty naive way.
Something done more seriously would likely be radically better...
-- 
http://linuxfinances.info/info/linuxdistributions.html
"The definition of insanity is doing the same thing over and over and
expecting different results."  -- assortedly attributed to Albert
Einstein, Benjamin Franklin, Rita Mae Brown, and Rudyard Kipling


Re: Will PostgreSQL get ported to CUDA?

From
Gregory Stark
Date:
"Christopher Browne" <cbbrowne@gmail.com> writes:

> This was based on GPUSort:
> http://gamma.cs.unc.edu/GPUSORT/

I looked briefly at GPUSort a while back. I couldn't see how to shoehorn into
POstgres the assumption that you're always sorting floating point numbers. You
would have to add some property of some data types that mapped every value to
a floating point value. I suppose we could add that as a btree proc entry for
specific data types but it would be a pretty radical change.

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication
support!


Re: Will PostgreSQL get ported to CUDA?

From
"Dann Corbit"
Date:
> -----Original Message-----
> From: pgsql-hackers-owner@postgresql.org [mailto:pgsql-hackers-
> owner@postgresql.org] On Behalf Of Christopher Browne
> Sent: Wednesday, January 30, 2008 9:56 AM
> To: pgsql-hackers@postgresql.org
> Subject: [HACKERS] Will PostgreSQL get ported to CUDA?
>
> 2008/1/30 Dann Corbit <DCorbit@connx.com>:
>
http://www.scientificcomputing.com/ShowPR~PUBCODE~030~ACCT~3000000100~IS
SU
> E~0801~RELTYPE~HPCC~PRODCODE~00000000~PRODLETT~C.html
> >
> > http://www.nvidia.com/object/cuda_learn.html
> >
> > http://www.nvidia.com/object/cuda_get.html
>
> Someone at CMU has tried this, somewhat fruitfully.
>
> http://www.andrew.cmu.edu/user/ngm/15-823/project/Draft.pdf
> http://www.andrew.cmu.edu/user/ngm/15-823/project/Final.pdf
>
> This was based on GPUSort:
> http://gamma.cs.unc.edu/GPUSORT/
>
> Unfortunately, the licensing of GPUSort is, if anything, more awful
> than that for CUDA.
> http://gamma.cs.unc.edu/GPUSORT/terms.html
>
> This would need to get pretty totally reimplemented to be useful with
> PostgreSQL.  Happily, we actually have some evidence that the exercise
> would be of some value.  Further, it looks to me like the
> implementation that was done was done in a pretty naive way.
> Something done more seriously would likely be radically better...

It's too bad that they have a restrictive license.

Perhaps there is an opportunity to create an "information appliance"
that contains a special build of PostgreSQL, a nice heap of super-speedy
disk, and a big pile of GPUs for sort and merge type operations.  The
thing that seems nice to me about this idea is that you would have a
very stable test platform (all hardware and software combinations would
be known and thoroughly tested) and you might also get some extreme
performance.

I guess that a better sort than GPUSort could be written from scratch,
but legal entanglements with the use of the graphics cards may make the
whole concept DOA.



Re: Will PostgreSQL get ported to CUDA?

From
Simon Riggs
Date:
On Wed, 2008-01-30 at 17:55 +0000, Christopher Browne wrote:
> 2008/1/30 Dann Corbit <DCorbit@connx.com>:
>
http://www.scientificcomputing.com/ShowPR~PUBCODE~030~ACCT~3000000100~ISSUE~0801~RELTYPE~HPCC~PRODCODE~00000000~PRODLETT~C.html
> >
> > http://www.nvidia.com/object/cuda_learn.html
> >
> > http://www.nvidia.com/object/cuda_get.html
> 
> Someone at CMU has tried this, somewhat fruitfully.
> 
> http://www.andrew.cmu.edu/user/ngm/15-823/project/Draft.pdf
> http://www.andrew.cmu.edu/user/ngm/15-823/project/Final.pdf

Well done that man! Excellent piece of research.

Clearly GPUsort is cool; is it cool enough? Here's a few thoughts and
questions that we still need answers to:

The concept of CPU offload can be generalised to any specialised
hardware. Can we offload such tasks easily? If so, to what? Should it be
a GPU, or just another more general CPU? Is the cost and difficulty of
making the GPU work in generalised form better than spending that money
on more resources e.g. memory?

Can the sorting network really be reused in the general case, or must we
realistically recreate it for each new sort set?

Can we have multiple concurrent sorts of the GPU, or is it one user at a
time? Would we need multiple GPUs? Is such an architecture available?

I note that the comparison with HeapSort is worst case, since we sort 1
GB of memory without increasing work_mem beyond 1MB.

There doesn't seem to be a discussion of how GPUsort would handle sorts
too large to fit within the GPU, so we would need to have an external
sort mechanism. So if qsort is better for smaller inputs and external
sorts are needed for larger, then there seems to be a narrow-ish middle
band of benefit.

Another thought would be to replace external heap sort with an external
sort based around qsort or GPUsort, which we extend the range of
usefulness. But then we're back to redesigning external sorts.

--  Simon Riggs 2ndQuadrant  http://www.2ndQuadrant.com 



Re: Will PostgreSQL get ported to CUDA?

From
Hannu Krosing
Date:
On Wed, 2008-01-30 at 12:56 -0800, Dann Corbit wrote:

> It's too bad that they have a restrictive license.
> 
> Perhaps there is an opportunity to create an "information appliance"
> that contains a special build of PostgreSQL, a nice heap of super-speedy
> disk, and a big pile of GPUs for sort and merge type operations.  The
> thing that seems nice to me about this idea is that you would have a
> very stable test platform (all hardware and software combinations would
> be known and thoroughly tested) and you might also get some extreme
> performance.
> 
> I guess that a better sort than GPUSort could be written from scratch,
> but legal entanglements with the use of the graphics cards may make the
> whole concept DOA.

Maybe some physics engines are also wort a look.

Soemthing like:

http://www.reghardware.co.uk/2006/05/04/review_ageia_physx_board/

could suit some DB tasks better than GPU

-------------
Hannu




Re: Will PostgreSQL get ported to CUDA?

From
Martijn van Oosterhout
Date:
On Wed, Jan 30, 2008 at 08:27:47PM +0000, Gregory Stark wrote:
> "Christopher Browne" <cbbrowne@gmail.com> writes:
> > This was based on GPUSort:
> > http://gamma.cs.unc.edu/GPUSORT/
>
> I looked briefly at GPUSort a while back. I couldn't see how to shoehorn into
> POstgres the assumption that you're always sorting floating point numbers. You
> would have to add some property of some data types that mapped every value to
> a floating point value. I suppose we could add that as a btree proc entry for
> specific data types but it would be a pretty radical change.

Not new though. The idea has been floated to create such functions
(only mapping to integers) and have the postgres sort code first
compare the integers and only if they're equal to run the actual
comparison function. The idea being to avoid function call overhead.

It would mostly be a win for comparing strings since you then don't
need to lookup the collation tables as often.

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Those who make peaceful revolution impossible will make violent revolution inevitable.
>  -- John F Kennedy