pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
To: AJG <ayden@gera.co.nz>
Cc: pgsql-performance@postgresql.org
Subject: Re: FPGA optimization ...
Date: Wed, 6 Nov 2019 22:54:48 +0100
Message-ID: <20191106215448.dhjqeq2ihfkpxnbg@development> (raw)
In-Reply-To: <1573063297493-0.post@n3.nabble.com>
References: <e41deea2-9594-36dc-be76-47c39368911e@gusw.net>
	<20191105001915.w7js3knyfvlznu6m@development>
	<45be5a6f-aff0-9fd3-1f36-538eb06fdeee@gusw.net>
	<1573063297493-0.post@n3.nabble.com>

On Wed, Nov 06, 2019 at 11:01:37AM -0700, AJG wrote:
From what I have read and benchmarks seen..
>
>FPGA shines for writes (and up to 3x (as opposed to 10x claim) real world
>for queries from memory)
>
>GPU shines/outperforms FPGA for reads. There is a very recent and
>interesting academic paper[1] on High Performance GPU B-Tree (vs lsm) and
>the incredible performance it gets, but I 'think' it requires NVIDIA (so no
>easy/super epyc+gpu+hbm on-chip combo solution then ;) ).
>
>Doesn't both FPHGA and GPU going to require changes to executor from pull to
>push to get real benefits from them? Isnt that something Andres working on
>(pull to push)?
>

I think it very much depends on how the FPA/GPU/... is used.

If we're only talking about FPGA I/O acceleration, essentially FPGA
between the database and storage, it's likely possible to get that
working without any extensive executor changes. Essentially create an
FPGA-aware variant of SeqScan and you're done. Or an FPGA-aware
tuplesort, or something like that. Neither of this should require
significant planner/executor changes, except for costing.

>What really is exciting is UPMEM (little 500mhz processors on the memory),
>cost will be little more than memory cost itself, and shows up to 20x
>performance improvement on things like index search (from memory). C
>library, claim only needs few hundred lines of code to integrate from
>memory, but not clear to me what use cases it can also be used for than ones
>they show benchmarks for.
>

Interesting, and perhaps interesting for in-memory databases.

>
>[1] https://escholarship.org/content/qt1ph2x5td/qt1ph2x5td.pdf?t=pkvkdm

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services 





view thread (7+ messages)  latest in thread

Message-ID: <20191106215448.dhjqeq2ihfkpxnbg@development>
Permalink:  ../20191106215448.dhjqeq2ihfkpxnbg@development/
Also on:    postgresql.org/message-id/20191106215448.dhjqeq2ihfkpxnbg@development

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: tomas.vondra@2ndquadrant.com, ayden@gera.co.nz
  Subject: Re: FPGA optimization ...
  In-Reply-To: <20191106215448.dhjqeq2ihfkpxnbg@development>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox