Libgccjit.so: an embeddable JIT-compiler based on GCC • Hacker News Board

Re: Libgccjit.so: an embeddable JIT-compiler based on GCC

#11

Post by foobarbazqux » Thu, Oct 03, 2013, 2:23 PM UTC

DanWaterworth wrote: post #5

dmytrish wrote: post #3

Earlier quoted context omitted.

It looks like LLVM was designed for JIT compilation from the start.

LLVM doesn't make a great JIT compiler and I don't think gcc will either. The problem is that, most of the time, your JITed code won't be used very much and so the amount of time that it takes to generate it is a significant proportion of the total execution time. LLVM and gcc are optimized for producing the fastest possible code and will do so at the expense of spending more time doing it. That's not to say that the…

There are many optimizations in GCC and LLVM. If you turn them all off you will compile fast and execute slow, and if you turn them all on you will compile slow and execute fast. You can do this on a per function / trace / translation unit / whatever basis.

Production JIT compilers are the same way. For the hottest code paths, all the optimizations get turned on. The coldest ones are interpreted. The first level of jitted compilation has very few optimizations enabled.

The main thing that doesn't cooperate with JIT compilation yet is whole program analysis.

Re: Libgccjit.so: an embeddable JIT-compiler based on GCC

#12

Post by gsnedders » Thu, Oct 03, 2013, 2:44 PM UTC

DanWaterworth wrote: post #5

dmytrish wrote: post #3

Earlier quoted context omitted.

It looks like LLVM was designed for JIT compilation from the start.

LLVM doesn't make a great JIT compiler and I don't think gcc will either. The problem is that, most of the time, your JITed code won't be used very much and so the amount of time that it takes to generate it is a significant proportion of the total execution time. LLVM and gcc are optimized for producing the fastest possible code and will do so at the expense of spending more time doing it. That's not to say that the…

People at Apple working on JavaScriptCore (Safari's JS engine) have recently added a fourth-tier JIT using LLVM, so very much run for only very-very-very-hot code (of course, by waiting for it to become very-very-very-hot, you've already lost a time you could've gained). I can see LLVM making its way into more JITing compilers in such ways: as an ultimate solution where it is clear it's worthwhile spending a lot of time compiling code.

The node.js server case seems worthwhile to bring up here: node.js servers are typically run for days or weeks on end. An extra few milliseconds (or even a second or two) isn't significant if it makes a noticeable difference in performance.

Re: Libgccjit.so: an embeddable JIT-compiler based on GCC

#13

Post by rayiner » Thu, Oct 03, 2013, 2:49 PM UTC

foobarbazqux wrote: post #11

DanWaterworth wrote: post #5

Earlier quoted context omitted.

LLVM doesn't make a great JIT compiler and I don't think gcc will either. The problem is that, most of the time, your JITed code won't be used very much and so the amount of time that it takes to generate it is a significant proportion of the total execution time. LLVM and gcc are optimized for producing the fastest possible code and will do so at the expense of spending more time doing it. That's not to say that the…

There are many optimizations in GCC and LLVM. If you turn them all off you will compile fast and execute slow, and if you turn them all on you will compile slow and execute fast. You can do this on a per function / trace / translation unit / whatever basis. Production JIT compilers are the same way. For the hottest code paths, all the optimizations get turned on. The coldest ones are interpreted. The first level of j…

That's not actually true, at least with regards to LLVM. The vast majority of the time in LLVM is spent in instruction selection. LLVM spends a lot of time on instruction selection/legalization, which you can't just turn off.

Re: Libgccjit.so: an embeddable JIT-compiler based on GCC

#14

Post by dmytrish » Thu, Oct 03, 2013, 2:51 PM UTC

DanWaterworth wrote: post #5

dmytrish wrote: post #3

Earlier quoted context omitted.

It looks like LLVM was designed for JIT compilation from the start.

LLVM doesn't make a great JIT compiler and I don't think gcc will either. The problem is that, most of the time, your JITed code won't be used very much and so the amount of time that it takes to generate it is a significant proportion of the total execution time. LLVM and gcc are optimized for producing the fastest possible code and will do so at the expense of spending more time doing it. That's not to say that the…

AFAIK, you can manually specify all of the optimizations done by LLVM during JIT compilation. I think it's not hard to disable most of them for fast compilation, but yes, it still may be too heavy for an instant use.

Re: Libgccjit.so: an embeddable JIT-compiler based on GCC

#15

Post by foobarbazqux » Thu, Oct 03, 2013, 3:02 PM UTC

rayiner wrote: post #13

foobarbazqux wrote: post #11

Earlier quoted context omitted.

There are many optimizations in GCC and LLVM. If you turn them all off you will compile fast and execute slow, and if you turn them all on you will compile slow and execute fast. You can do this on a per function / trace / translation unit / whatever basis. Production JIT compilers are the same way. For the hottest code paths, all the optimizations get turned on. The coldest ones are interpreted. The first level of j…

That's not actually true, at least with regards to LLVM. The vast majority of the time in LLVM is spent in instruction selection. LLVM spends a lot of time on instruction selection/legalization, which you can't just turn off.

But you can't turn off codegen in a JIT compiler either, unless you're interpreting code, so that requirement doesn't fundamentally make GCC and LLVM impractical. It sounds like LLVM either doesn't have very many optimizations or their backend needs work.

Re: Libgccjit.so: an embeddable JIT-compiler based on GCC

#16

Post by rayiner » Thu, Oct 03, 2013, 3:05 PM UTC

foobarbazqux wrote: post #15

rayiner wrote: post #13

Earlier quoted context omitted.

That's not actually true, at least with regards to LLVM. The vast majority of the time in LLVM is spent in instruction selection. LLVM spends a lot of time on instruction selection/legalization, which you can't just turn off.

But you can't turn off codegen in a JIT compiler either, unless you're interpreting code, so that requirement doesn't fundamentally make GCC and LLVM impractical. It sounds like LLVM either doesn't have very many optimizations or their backend needs work.

LLVM's instruction selection/legalization infrastructure is very sophisticated, very generic, table-driven, etc. Most JIT compilers use more ad-hoc and quicker mechanisms to get machine code out of IR.

Re: Libgccjit.so: an embeddable JIT-compiler based on GCC

#17

Post by pcwalton » Thu, Oct 03, 2013, 3:24 PM UTC

rayiner wrote: post #13

foobarbazqux wrote: post #11

Earlier quoted context omitted.

There are many optimizations in GCC and LLVM. If you turn them all off you will compile fast and execute slow, and if you turn them all on you will compile slow and execute fast. You can do this on a per function / trace / translation unit / whatever basis. Production JIT compilers are the same way. For the hottest code paths, all the optimizations get turned on. The coldest ones are interpreted. The first level of j…

That's not actually true, at least with regards to LLVM. The vast majority of the time in LLVM is spent in instruction selection. LLVM spends a lot of time on instruction selection/legalization, which you can't just turn off.

Well, you can use FastISel, which is way way faster (it's a simple non-pattern-matching instruction emitter, like the Plan 9 compilers).

Re: Libgccjit.so: an embeddable JIT-compiler based on GCC

#18

Post by sanxiyn » Thu, Oct 03, 2013, 3:31 PM UTC

jevinskie wrote: post #9

DanWaterworth wrote: post #5

Earlier quoted context omitted.

LLVM doesn't make a great JIT compiler and I don't think gcc will either. The problem is that, most of the time, your JITed code won't be used very much and so the amount of time that it takes to generate it is a significant proportion of the total execution time. LLVM and gcc are optimized for producing the fastest possible code and will do so at the expense of spending more time doing it. That's not to say that the…

LLVM understands this issue. That is why they have "regular" instruction selection passes and "fast" instruction selection passes. The JIT uses FastISel. But you are definitely right, it is not anywhere near as lightweight compared to, say, Hotspot.

There is also an issue of FastISel not supporting the full LLVM IR, so if you depend on FastISel for fast JIT, you basically need to design LLVM IR generation around that, limiting yourself to undocumented, unspecified, and ever changing subset of LLVM IR. Which can be done, but not very pleasant.

Re: Libgccjit.so: an embeddable JIT-compiler based on GCC

#19

Post by foobarbazqux » Thu, Oct 03, 2013, 3:33 PM UTC

rayiner wrote: post #16

foobarbazqux wrote: post #15

Earlier quoted context omitted.

But you can't turn off codegen in a JIT compiler either, unless you're interpreting code, so that requirement doesn't fundamentally make GCC and LLVM impractical. It sounds like LLVM either doesn't have very many optimizations or their backend needs work.

LLVM's instruction selection/legalization infrastructure is very sophisticated, very generic, table-driven, etc. Most JIT compilers use more ad-hoc and quicker mechanisms to get machine code out of IR.

Yeah okay. Someone else pointed out FastISel.cpp. It's probably true that prettiness competes with performance.

Re: Libgccjit.so: an embeddable JIT-compiler based on GCC

#20

Post by rayiner » Thu, Oct 03, 2013, 4:46 PM UTC

foobarbazqux wrote: post #19

rayiner wrote: post #16

Earlier quoted context omitted.

LLVM's instruction selection/legalization infrastructure is very sophisticated, very generic, table-driven, etc. Most JIT compilers use more ad-hoc and quicker mechanisms to get machine code out of IR.

Yeah okay. Someone else pointed out FastISel.cpp. It's probably true that prettiness competes with performance.

FastISel will quite often kick out to the regular instruction selector because it can't handle particular IR constructs.