Skip site navigation (1) Skip section navigation (2)

Re: GPU Accelerated Sorting

From: Eliot Gable <egable+pgsql-performance(at)gmail(dot)com>
To: Gaël Le Mignot <gael(at)pilotsystems(dot)net>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: GPU Accelerated Sorting
Date: 2010-08-30 18:49:27
Message-ID: AANLkTikgDpexx9Gicj4ukmmYGN31a+B4bNfFo=M4Y6xG@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-performance
Well, from that perspective, it becomes a "chicken and egg" problem.
Without the software support to use a GPU in a server for
acceleration, nobody's going to build a server with a GPU.

However, as previously stated, I can understand the challenges with
determining whether the offloading would even be worthwhile (given
disk performance constraints and GPU memory loading constraints vs
payoff for acceleration), much less finding actual real-world queries
that would benefit from it. I am sure there are probably hundreds of
other performance improvements that could be made that would have much
more wide-spread appeal, but it's an interesting thing to consider.
This is not the first thing that's come up that a database could use a
GPU for in order to improve performance, and it won't be the last.
It's something to keep in mind, and if enough additional items come up
where GPUs can do better than CPUs, it might be worthwhile to start
implementing some of those things. Maybe if enough of them get
implemented, there will be enough overall performance increase to make
it worthwhile to put a GPU in a database server. Besides, if you can
sort data on a GPU faster than a CPU, you can probably also search for
data faster on the GPU than on the CPU under similar conditions. With
memory increasing like crazy in servers, it might be worthwhile to
keep indexes entirely in memory (but keep them sync'd to the disk,
obviously) and for extremely large tables, dump them to the GPU for a
massively parallel search. In fact, if you can get enough GPU memory
that you could keep them entirely in the GPU memory and keep them
updated there any time they change, you could see some real
performance pay-offs.

I'm not saying someone should just go out and do this right now, but
it might be worthwhile to keep it in mind as code is re-written or
updated in the future how it might be structured to more easily
implement something like this in the future.

On Mon, Aug 30, 2010 at 10:56 AM, Gaël Le Mignot <gael(at)pilotsystems(dot)net> wrote:
> Hello,
>
> In my humble opinion, while  it can sound interesting from a theorical
> point of view to outloads some  operations to the GPU, there is a huge
> pratical problem in current world  : databases which are big enough to
> require such heavy optimization are usually runned on server hardware,
> which very rarely have powerful GPU.
>
> There may  be a small  target of computers  having both GPU  and heavy
> database, but that sounds very  exceptional to me, so investing effort
> into it sounds a bit unjustified to me.
>
> Except  as a  matter of  scientific research,  which is  it  of course
> important for the future.
>
> Regards,
>
> --
> Gaël Le Mignot - gael(at)pilotsystems(dot)net
> Pilot Systems - 9, rue Desargues - 75011 Paris
> Tel : +33 1 44 53 05 55 - www.pilotsystems.net
> Gérez vos contacts et vos newsletters : www.cockpit-mailing.com
>



-- 
Eliot Gable

"We do not inherit the Earth from our ancestors: we borrow it from our
children." ~David Brower

"I decided the words were too conservative for me. We're not borrowing
from our children, we're stealing from them--and it's not even
considered to be a crime." ~David Brower

"Esse oportet ut vivas, non vivere ut edas." (Thou shouldst eat to
live; not live to eat.) ~Marcus Tullius Cicero

In response to

pgsql-performance by date

Next:From: Yeb HavingaDate: 2010-08-30 19:25:38
Subject: Re: GPU Accelerated Sorting
Previous:From: Ozer, PamDate: 2010-08-30 16:51:21
Subject: Re: Using Between

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group