Date: Wed, 6 Nov 2019 22:54:48 +0100
From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
To: AJG <ayden@gera.co.nz>
Cc: pgsql-performance@postgresql.org
Subject: Re: FPGA optimization ...
Message-ID: <20191106215448.dhjqeq2ihfkpxnbg@development>
References: <e41deea2-9594-36dc-be76-47c39368911e@gusw.net>
 <20191105001915.w7js3knyfvlznu6m@development>
 <45be5a6f-aff0-9fd3-1f36-538eb06fdeee@gusw.net>
 <1573063297493-0.post@n3.nabble.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <1573063297493-0.post@n3.nabble.com>
User-Agent: NeoMutt/20180716
Precedence: bulk

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