Re: [HACKERS] WIP: Faster Expression Processing and Tuple Deforming(including JIT)
От | Andres Freund |
---|---|
Тема | Re: [HACKERS] WIP: Faster Expression Processing and Tuple Deforming(including JIT) |
Дата | |
Msg-id | 20170210180103.vbfb7edginhtjfv2@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: [HACKERS] WIP: Faster Expression Processing and Tuple Deforming(including JIT) (Markus Nullmeier <dq124@uni-heidelberg.de>) |
Список | 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
В списке pgsql-hackers по дате отправления: