Amazon now supporting GPU focused EC2 instances
I keep wondering if there's a role for GPUs in Postgres and haven't
figure out how to integrate them yet but the day when we'll be
expected to exploit them seems to be getting nearer:
http://aws.typepad.com/aws/2010/11/new-ec2-instance-type-the-cluster-gpu-instance.html
--
greg
On 15 November 2010 11:26, Greg Stark <stark@mit.edu> wrote:
I keep wondering if there's a role for GPUs in Postgres and haven't
figure out how to integrate them yet but the day when we'll be
expected to exploit them seems to be getting nearer:http://aws.typepad.com/aws/2010/11/new-ec2-instance-type-the-cluster-gpu-instance.html
Is this somewhere OpenCL is an option?
--
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935
On Mon, Nov 15, 2010 at 11:37 AM, Thom Brown <thom@linux.com> wrote:
Is this somewhere OpenCL is an option?
Sure.
Personally I wonder whether the context switching is fast enough to
handle a multi-user system. In the past graphics cards have always
been targeted at the idea of a single-user workstation playing games
where the game wants to talk directly to the graphics card. But
increasingly that's not true, with things like opengl based window
managers and so on. Perhaps things have changed enough that it would
be conceivable to have dozens of separate processes all downloading
snippets of code and time-sharing the GPU now.
The other problem is that Postgres is really not architected in a way
to make this easy. Since our data types are all flexible pluggable
sets of functions it's unclear whether any of them match the data
types that GPUs know about. The obvious algorithm to toss to the GPU
would be sorting -- but that would only work for floats and even then
it's not clear to me that the float semantics on the GPU necessarily
match those of the host processor.
I've seen papers on doing relational joins using GPUs and I'm sure
there are other algorithms we wonderful stuff we could do. But if it
comes at the cost of being able to handle arbitrary join clauses it'll
be a tough sacrifice to make.
--
greg
On 2010-11-15 12:37, Thom Brown wrote:
On 15 November 2010 11:26, Greg Stark <stark@mit.edu
<mailto:stark@mit.edu>> wrote:I keep wondering if there's a role for GPUs in Postgres and haven't
figure out how to integrate them yet but the day when we'll be
expected to exploit them seems to be getting nearer:http://aws.typepad.com/aws/2010/11/new-ec2-instance-type-the-cluster-gpu-instance.html
Is this somewhere OpenCL is an option?
There is a talk about PgOpenCL upcoming -
http://www.postgresql.eu/events/schedule/pgday2010/session/56-introduction-to-pgopencl-a-new-procedural-language-for-postgresql-unlocking-the-power-of-the-gpgpu/
Maybe I've sent this link earlier, but the VLDB 2008 paper Parallelizing
Query Optimization (http://www.vldb.org/pvldb/1/1453882.pdf) might be
interesting: not much IO between CPU and GPU. (hmm how much catalog
access is necessary for cost estimization)). I suspect the biggest
challenge is rewriting essential parts into a SIMD algorithm.
regards,
Yeb Havinga
On 2010-11-15 18:49, Greg Stark wrote:
I've seen papers on doing relational joins using GPUs and I'm sure
there are other algorithms we wonderful stuff we could do. But if it
comes at the cost of being able to handle arbitrary join clauses it'll
be a tough sacrifice to make.
Perhaps the coolest use of all is as an intermediate filtering stage for
spatial joins, using collision detection. Draw your data and your
search region (slightly enlarged) as objects and ask the graphics card
if the search region collides with anything. Much like it might ask "is
this player character bumping into any walls?"
IIRC it's been prototyped in Oracle with impressive results. Using
OpenGL, so quite portable between GPUs.
Jeroen
Jeroen Vermeulen wrote:
On 2010-11-15 18:49, Greg Stark wrote:
I've seen papers on doing relational joins using GPUs and I'm sure
there are other algorithms we wonderful stuff we could do. But if it
comes at the cost of being able to handle arbitrary join clauses it'll
be a tough sacrifice to make.Perhaps the coolest use of all is as an intermediate filtering stage for
spatial joins, using collision detection. Draw your data and your
search region (slightly enlarged) as objects and ask the graphics card
if the search region collides with anything. Much like it might ask "is
this player character bumping into any walls?"
Netezza has FPGAs (Field-Programmable Gate Arrays) for each disk drive
that performs a similar function:
http://www.dbms2.com/2009/08/08/netezza-fpga/
The longer answer is:
* Projections
* Restrictions/selections
* Visibility, which for now seems to mean recognizing which rows are
and arent valid under Netezzas form of MVCC (MultiVersion Concurrency
Control).
* Compression and/or decompression (Im a little confused as to
which, but I imagine its both)
* Netezzas form of UDFs (User-Defined Functions)
More details:
http://www.theregister.co.uk/2006/10/03/netezza_annual_conference_roundup/
Another area in which Netezza has been hiding its light under a bushel
is in the matter of FPGAs (field programmable gate arrays). FPGAs are
used to process data as it is streamed off disk. Note that this is
important to understand. Most data warehouse appliances (and, indeed,
conventional products) use a caching architecture whereby data is read
from disk and then held in cache for processing. Netezza, on the other
hand, uses an approach that queries the data as it comes off disk before
passing the results on to memory. In other words it uses a streaming
architecture in which the data is streamed through the queries (whose
programs have been loaded into the FPGA) rather than being stored (even
if in memory) and then queried.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
Thom Brown-2 wrote:
On 15 November 2010 11:26, Greg Stark <stark@mit.edu> wrote:
I keep wondering if there's a role for GPUs in Postgres and haven't
figure out how to integrate them yet but the day when we'll be
expected to exploit them seems to be getting nearer:http://aws.typepad.com/aws/2010/11/new-ec2-instance-type-the-cluster-gpu-instance.html
Is this somewhere OpenCL is an option?
--
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935
OpenCL is a good option as its
1) Open - supported by many vendors Apple, AMD/ATI, Nvidia, IBM, Intel, ..
2) Runs on CPU's and GPU's. - There is definitely I/O overhead and other
challenges to running code on a GPU. See my Pg EU Day 2010 prezzy
http://www.scribd.com/doc/44661593/PostgreSQL-OpenCL-Procedural-Language.
3) Supports SIMD instructions and multi-threading on CPU's - No GPU
required! This can boost an app by executing 4 floating points ops
concurrently per FPU.
There is an interesting class of chip due from AMD, due in mid 2011, with
combined CPU & GPU. Hopefully these chips will reduce the GPU I/O
overhead and be more amenable to program concurrency. See
http://sites.amd.com/us/fusion/apu/Pages/fusion.aspx.
For some applications running SIMD instructions and using all the cores
will provide a boost. Intel are pushing this point staying running SSE4
instructions on 4 or 8 cores can get up to 16x increase. Of course you can
hand-roll all this SSE4 code, But why not let an OpenCL compiler get
you 80% of the increases?
My first phase was to implement some OpenCL code as User Defined
Functions. This comes with the overhead of creating OpenCL run-time context
and compiling OpenCL Kernels. Phase Two is the OpenCL as procedure language
and moving run-time context and program compiling to PG_init() and the SQL
create function statement.
For floating point numeric and image processing apps OpenCL and GPU's are
pretty much a no-brainer.
They are are easier to parallelize and and have been proven in many case to
benefit from GPU's
The big question is can OpenCL improve any existing apps with sorting and
searching in parallel? We can find out more in Jan 2011 when I'll make a
drop of the pGOpenCL code.
Regards
Tim
--
View this message in context: http://postgresql.1045698.n5.nabble.com/Amazon-now-supporting-GPU-focused-EC2-instances-tp3265420p3311407.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.