Re: New LLVM JIT Features

Поиск
Список
Период
Сортировка
От preejackie
Тема Re: New LLVM JIT Features
Дата
Msg-id 859aa673-8303-2a1b-cc23-0dadfd412ec1@gmail.com
обсуждение исходный текст
Ответ на Re: New LLVM JIT Features  (Andres Freund <andres@anarazel.de>)
Ответы Re: New LLVM JIT Features  (Andres Freund <andres@anarazel.de>)
Список pgsql-general

Hi Andres,

Thanks for the reply! Please see my comments inline.

On 03/04/19 3:20 AM, Andres Freund wrote:
Hi,

On 2019-04-02 00:51:51 +0530, preejackie wrote:
As LLVM ORC supports compiling in multiple backend threads, it would be
effective if we compile the functions speculatively before they are called
by the executing function. So when we request JIT to compile a function, JIT
will immediately returns the function address for raw executable bits. This
will greatly reduce the JIT latencies in modern multi-core machines.
I personally think this should be approached somewhat differently -
putting patchpoints into code reduces the efficiency of the generated
code, so I don't think that's the right approach. What I think we should
 What do you mean by patch points here? To my knowledge, LLVM symbols have arbitrary stub associated which resolve to function address at function address.
do is to, if we decide it's worthwhile at plan time, generate the LLVM
IR time at the beginning of execution, but continue to use interpreted
execution initially. The generated IR would then be handed over to a
background [process|thread|whatnot] for optimization of code
generation. Then, when finished, I'd switch over from interpreted to JIT
compiled execution.  That approach will, in my view, yield better
latency behaviour because we can actually evaluate quals etc for which
we've not yet finished code generation.


And also I'm working on designing a ORC in-place dynamic profiling support, by
this JIT will automatically able to identify the hot functions, and compile
it in higher optimization level to achieve good performance.
I think that's a nice concept, but at the moment the generated code is
so bad that it's much more likely to get big benefits by improving the
generated IR, compared to giving more hints to the optimizer.
By improving the generated IR, you mean by turning pgsql queries into LLVM IR? If it is the case, this design doesn't handles that, it works only when the given program representation is in LLVM IR. 

Greetings,

Andres Freund
-- 
Have a great day!
PreeJackie

В списке pgsql-general по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: template0 is having high age of datforzenxid
Следующее
От: Andres Freund
Дата:
Сообщение: Re: New LLVM JIT Features