Thread: would hw acceleration help postgres (databases in general) ?
Hello hackers, I think i'm at the right place to ask this question. Based on your experience and the fact that you have written the Postgres code, can you tell what a rough break-down - in your opinion - is for the time the database spends time just "fetching and writing " stuff to memory and the actual computation. The reason i ask this is because off-late there has been a push to put reconfigurable hardware on processor cores. What this means is that database writers can possibly identify the compute-intensive portions of the code and write hardware accelerators and/or custom instructions and offload computation to these hardware accelerators which they would have programmed onto the FPGA. There is not much utility in doing this if there aren't considerable compute- intensive operations in the database (which i would be surprise if true ). I would suspect joins, complex queries etc may be very compute-intensive. Please correct me if i'm wrong. Moreover, if you were told that you have a reconfigurable hardware which can perform pretty complex computations 10x faster than the base, would you think about synthesizing it directly on an fpga and use it ? I'd be more than glad to hear your guesstimates. Thanks alot ! Hamza
> -----Original Message----- > From: pgsql-hackers-owner@postgresql.org [mailto:pgsql-hackers- > owner@postgresql.org] On Behalf Of Hamza Bin Sohail > Sent: Friday, December 10, 2010 3:10 PM > To: pgsql-hackers@postgresql.org > Subject: [HACKERS] would hw acceleration help postgres (databases in > general) ? > > > Hello hackers, > > I think i'm at the right place to ask this question. > > Based on your experience and the fact that you have written the > Postgres code, > can you tell what a rough break-down - in your opinion - is for the > time the > database spends time just "fetching and writing " stuff to memory and > the > actual computation. The reason i ask this is because off-late there has > been a > push to put reconfigurable hardware on processor cores. What this means > is that > database writers can possibly identify the compute-intensive portions > of the > code and write hardware accelerators and/or custom instructions and > offload > computation to these hardware accelerators which they would have > programmed > onto the FPGA. > > There is not much utility in doing this if there aren't considerable > compute- > intensive operations in the database (which i would be surprise if true > ). I > would suspect joins, complex queries etc may be very compute-intensive. > Please > correct me if i'm wrong. Moreover, if you were told that you have a > reconfigurable hardware which can perform pretty complex computations > 10x > faster than the base, would you think about synthesizing it directly on > an fpga > and use it ? > > I'd be more than glad to hear your guesstimates. Here is a sample project: http://www.cs.virginia.edu/~skadron/Papers/bakkum_sqlite_gpgpu10.pdf And another: http://www.cs.cmu.edu/afs/cs.cmu.edu/Web/People/ngm/15-823/project/Final.pdf
On 12/10/10 3:09 PM, Hamza Bin Sohail wrote:
> There is not much utility in doing this if there aren't considerable compute-
> intensive operations in the database (which i would be surprise if true ). I
> would suspect joins, complex queries etc may be very compute-intensive. Please
> correct me if i'm wrong. Moreover, if you were told that you have a
> reconfigurable hardware which can perform pretty complex computations 10x
> faster than the base, would you think about synthesizing it directly on an fpga
> and use it ?
Databases are, in general, CPU-bound. Most activities are
compute-intensive. Even things you might think would be I/O-bound ...
like COPY ... end up being dominated by parsing and building data
structures.
So, take your pick. COPY might be a good place to start, actually,
since the code is pretty isolated and it would be easy to do tests.
Or am I using a different definition of "compute-intensive" than you are?
-- -- Josh Berkus PostgreSQL Experts Inc.
http://www.pgexperts.com
On Fri, Dec 10, 2010 at 3:09 PM, Hamza Bin Sohail <hsohail@purdue.edu> wrote: > > Hello hackers, > > I think i'm at the right place to ask this question. > > Based on your experience and the fact that you have written the Postgres code, > can you tell what a rough break-down - in your opinion - is for the time the > database spends time just "fetching and writing " stuff to memory and the > actual computation. The database is a general purpose tool. Pick a bottleneck you wish to have, and probably someone uses it in a way that causes that bottleneck to occur. > The reason i ask this is because off-late there has been a > push to put reconfigurable hardware on processor cores. What this means is that > database writers can possibly identify the compute-intensive portions of the > code and write hardware accelerators and/or custom instructions and offload > computation to these hardware accelerators which they would have programmed > onto the FPGA. When people don't use prepared statements, parsing can become a bottleneck. If Bison's yyparse could be put on a FPGA in a transparent way, than anyone using Bison, including PG, might benefit. That's just one example, of course. Cheers, Jeff
Thanks alot for all the replies. Very helpful, really appreciate it. ----- Original Message ----- From: "Jeff Janes" <jeff.janes@gmail.com> To: "Hamza Bin Sohail" <hsohail@purdue.edu> Cc: <pgsql-hackers@postgresql.org> Sent: Friday, December 10, 2010 7:18 PM Subject: Re: [HACKERS] would hw acceleration help postgres (databases in general) ? > On Fri, Dec 10, 2010 at 3:09 PM, Hamza Bin Sohail <hsohail@purdue.edu> > wrote: >> >> Hello hackers, >> >> I think i'm at the right place to ask this question. >> >> Based on your experience and the fact that you have written the Postgres >> code, >> can you tell what a rough break-down - in your opinion - is for the time >> the >> database spends time just "fetching and writing " stuff to memory and the >> actual computation. > > The database is a general purpose tool. Pick a bottleneck you wish to > have, > and probably someone uses it in a way that causes that bottleneck to > occur. > >> The reason i ask this is because off-late there has been a >> push to put reconfigurable hardware on processor cores. What this means >> is that >> database writers can possibly identify the compute-intensive portions of >> the >> code and write hardware accelerators and/or custom instructions and >> offload >> computation to these hardware accelerators which they would have >> programmed >> onto the FPGA. > > When people don't use prepared statements, parsing can become a > bottleneck. > > If Bison's yyparse could be put on a FPGA in a transparent way, than > anyone using > Bison, including PG, might benefit. > > That's just one example, of course. > > Cheers, > > Jeff >
On Dec 10, 2010, at 6:18 PM, Jeff Janes wrote: > On Fri, Dec 10, 2010 at 3:09 PM, Hamza Bin Sohail <hsohail@purdue.edu> wrote: >> >> Hello hackers, >> >> I think i'm at the right place to ask this question. >> >> Based on your experience and the fact that you have written the Postgres code, >> can you tell what a rough break-down - in your opinion - is for the time the >> database spends time just "fetching and writing " stuff to memory and the >> actual computation. > > The database is a general purpose tool. Pick a bottleneck you wish to have, > and probably someone uses it in a way that causes that bottleneck to occur. A common bottleneck we run into is sorting of text data. Unfortunately, I doubt that a GPU would be able to help with that. -- Jim C. Nasby, Database Architect jim@nasby.net 512.569.9461 (cell) http://jim.nasby.net
jim@nasby.net (Jim Nasby) writes: > On Dec 10, 2010, at 6:18 PM, Jeff Janes wrote: >> On Fri, Dec 10, 2010 at 3:09 PM, Hamza Bin Sohail <hsohail@purdue.edu> wrote: >>> >>> Hello hackers, >>> >>> I think i'm at the right place to ask this question. >>> >>> Based on your experience and the fact that you have written the Postgres code, >>> can you tell what a rough break-down - in your opinion - is for the time the >>> database spends time just "fetching and writing " stuff to memory and the >>> actual computation. >> >> The database is a general purpose tool. Pick a bottleneck you wish >> to have, and probably someone uses it in a way that causes that >> bottleneck to occur. > > A common bottleneck we run into is sorting of text > data. Unfortunately, I doubt that a GPU would be able to help with > that. Actually, that is a case where some successful experimentation has been done. http://www.cs.cmu.edu/afs/cs.cmu.edu/Web/People/ngm/15-823/project/Final.pdf Making it reliable to the point of being generally usable when someone installs Postgres via a generic packaging tool in default fashion may be somewhat more challenging! But it appears that sorting is a plausible application for GPUs. -- output = ("cbbrowne" "@" "linuxdatabases.info") "The right honorable gentleman is reminiscent of a poker. The only difference is that a poker gives off the occasional signs of warmth." -- Benjamin Disraeli on Robert Peel
Yes! Probably very much so. There is good evidence that using multiple CPU's and GPU's will speed sorting and many other database operations too. See http://www.cs.cmu.edu/afs/cs.cmu.edu/Web/People/ngm/15-823/project/Final.pdf The question become how practical is it? There are numerous issues; Sorts often use multiplecolumns and character data as keys. Little research has been done on sorting multi-column, variable length character data types on GPUs. Most research papers have used a single numeric (int or real) key. Fixed length character encodings such as UCS-2 or UCS-4 and not UTF-8 or UTF-16 will work faster, at the expense of storage, for character data sorting, For PostgreSQL you also need to support many platforms. Most database GPGPU research has been done using Nvidia's CUDA programming environment. Several papers have been published on using CUDA with PostgreSQL.But do we want to be tied into a single vendors hw? No, Never! OpenCL, is C Language for programming GPU's and many-core CPUs.It addresses the platform problem; it runs on Windows,MAC, and Linux.It supports Nvidia, and AMD GPU's. It supports Intel, AMD, and ARM CPU's and IBM/Toshiba Cell processors too. Most GPU programming models are data array centric. They work great if your data type is anaturally array centric like vectors, matrices, or images. They also work better if the data is fixed length too. SQL is relational; row and column centric. SQL data types are not usually fixed length vectors, arrays or images. But most SQL data types can be handled with OpenCL on GPUs with some work. To leverage GPUs well, you need good parallel algorithms that effectively utilize the GPU'smemory model. These parallel algorithms will give good speed-ups, based on Amdahl's Law, only if they are very parallel. E.g. 99% or better. So there lots of work to do in algorithms and their practical implementation. There is great potential in hw accelerated databases. This is why I've started PgOpenCL language bindings project See http://www.scribd.com/doc/51484335/PostgreSQL-OpenCL-Procedural-Language-pgEast-March-2011 There a still more issues like multi-tasking, fixed memory size, data transfer speed to resolve. Using GPUs won't solve data I/O parallelism problems. But once the data is in RAM they can kick some serious ... We need to research and conquer the issues that hold us back from using hw acceleration like GPU's. Running OpenCL inside PostgreSQL is just a first step. And I can't believe I've made a post on this subject without bringing up the topic of multi-threading... It's price you have to pay to utilize the 1400+ Arithmetic Logic Units on high end GPU. Each ALU can evaluate a predicate, or sum 2 numbers, and do lots more in parallel. With OpenCL, MT is built into the language, you don't have to mess with P-threads, and such evils. OpenCL has some simple built-in synchronization techniques, that's a fundamental for parallel programming too. -Tim -- View this message in context: http://postgresql.1045698.n5.nabble.com/would-hw-acceleration-help-postgres-databases-in-general-tp3301110p4266108.html Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.