Re: WIP: Faster Expression Processing and Tuple Deforming (including JIT)

From: Andres Freund <andres(at)anarazel(dot)de>
To: Markus Nullmeier <dq124(at)uni-heidelberg(dot)de>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: WIP: Faster Expression Processing and Tuple Deforming (including JIT)
Date: 2017-02-10 18:01:03
Message-ID: 20170210180103.vbfb7edginhtjfv2@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2017-02-10 18:18:13 +0100, Markus Nullmeier wrote:
> Well, if this thread of thought about hand-crafted JIT should be taken
> up again by someone at some point in time, I guess it could be possible
> to reuse tools that are already out there, such as "DynASM"
> ( http://luajit.org/dynasm_features.html ) from the LuaJIT project
> (currently offers x86-64, x86-32, ARM-32, PPC-32, and MIPS-32).
> Maybe one could even recycle parts of the LuaJIT project itself
> ( http://luajit.org/luajit.html ,
> http://article.gmane.org/gmane.comp.lang.lua.general/58908 ).

FWIW, I'd looked at dynasm/luajit.

One big reason to go for LLVM is that it has nearly all the
infrastructure to make backend-functions/operators inlineable.
Especially for some of the arithmetic operations and such, that'd be
quite useful performance-wise. With LLVM you can just use clang on C to
generate the IR, do some work to boil down the IR modules to the
relevant functions (i.e. remove non sql-callable functions), for which
LLVM has infrastructure, and then inline the functions that way. That's
a lot harder to do with nearly everything else (save gcc's jit library,
but the licensing and stability situation makes that unattractive.

Greetings,

Andres Freund

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2017-02-10 18:14:14 Re: removing tsearch2
Previous Message Robert Haas 2017-02-10 17:57:40 Re: Parallel Index Scans