Re: JIT compiling with LLVM v9.0
От | Andres Freund |
---|---|
Тема | Re: JIT compiling with LLVM v9.0 |
Дата | |
Msg-id | 20180128011542.7n5foa5vrsltmrft@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: JIT compiling with LLVM v9.0 (Jeff Davis <pgsql@j-davis.com>) |
Ответы |
Re: JIT compiling with LLVM v9.0
|
Список | pgsql-hackers |
Hi, On 2018-01-27 16:56:17 -0800, Jeff Davis wrote: > On another topic, I'm trying to find a way we could break this patch > into smaller pieces. For instance, if we concentrate on tuple > deforming, maybe it would be committable in time for v11? Yea, I'd planned and started to do so. I actually hope we can get more committed than just the tuple deforming code - for one it currently integrates directly with the expression evaluation code, and my experience with trying to do so outside of it have not gone well. > I see that you added some optimizations to the existing generic code. > Do those offer a measurable improvement, and if so, can you commit > those first to make the JIT stuff more readable? I think basically the later a patch currently is in the series the less important it is. I've already committed a lot of preparatory patches (like that aggs now use the expression engine), and I plan to continue doing so. > Also, I'm sure you considered this, but I'd like to ask if we can try > harder make the JIT itself happen in an extension. It has some pretty > huge benefits: I'm very strongly against this. To the point that I'll not pursue JITing further if that becomes a requirement. I could be persuaded to put it into a shared library instead of the main binary itself, but I think developing it outside of core is entirely infeasible because quite freuquently both non-JITed code and JITed code need adjustments. That'd solve your concern about > * Would mean postgres itself isn't dependent on a huge library like > llvm, which just seems like a good idea from a packaging standpoint. to some degree. I think it's a fools errand to try to keep in sync with core changes on the expression evaluation and struct definition side of things. There's planner integration, error handling integration and similar related things too, all of which require core changes. Therefore I don't think there's a reasonable chance of success of doing this outside of core postgres. > It appears reasonable to make the slot deforming and expression > evaluator parts an extension. execExpr.h only exports a couple new > functions; heaptuple.c has a lot of changes but they seem like they > could be separated (unless I'm missing something). The heaptuple.c stuff could largely be dropped, that was more an effort to level the plainfield a bit to make the comparison fairer. I kinda wondered about putting the JIT code in a heaptuple_jit.c file instead of heaptuple.c. > The biggest problem is that the inlining would be much harder to > separate out, because you are building the .bc files at build time. I > really like the idea of inlining, but it doesn't necessarily need to > be in the first commit. Well, but doing this outside of core would pretty much prohibit doing so forever, no? Getting the inlining design right has influenced several other parts of the code. I think it's right that the inlining doesn't necessarily have to be part of the initial set of commits (and I plan to separate it out in the next revision), but I do think it has to be written in a reasonably ready form at the time of commit. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления:
Следующее
От: Amit KapilaДата:
Сообщение: Re: [HACKERS] GSoC 2017: weekly progress reports (week 4) and patchfor hash index