Обсуждение: Will PostgreSQL get ported to CUDA?
<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>
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
"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
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
"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!
> -----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.
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
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
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