Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Introducing the B3 JIT compiler

webkit.org

Post reply on HN
Print view View original

61–70 of 131 posts

Re: Introducing the B3 JIT compiler

#61

Post by klodolph »

pizlonator wrote: post #53
alberth wrote: post #45

>> "tl;dr: B3 will replace LLVM in the FTL JIT of webkit. LLVM isn't performing fast enough for JIT mainly because it's so memory hungry and misses optimisations that depend on javascript semantics. They got an around 5x compile time reduction and from 0% up to around 10% performance boost in general." [1] Is this a knock on LLVM then? I wonder then specifically if this brings to light any concerns over Swift (anothe…

Swift is not a dynamic language. It's statically typed.

This comment, and the parent comment, seem to be conflating "dynamic language" with "dynamically-typed language".

Re: Introducing the B3 JIT compiler

#62

Post by cosinusoidally »

pizlonator wrote: post #11
VeejayRampay wrote: post #6

Earlier quoted context omitted.

Exactly. Ruby would probably have massive adoption with JS-like speed.

ajross is right. People choose the languages they like regardless of performance. JS perf is important to users though. Faster execution means fewer watts spent rendering and interacting with your favorite web page. (Fun fact: B3's backend contains a machine description language that gets compiled to C++ code by a ruby script, opcode_generator.rb. We use Ruby a lot.)

Why didn't you use JavaScript for that purpose (in a similar vein to how LuaJIT uses Lua for dynasm)?

Re: Introducing the B3 JIT compiler

#63

Post by dochtman »

pizlonator wrote: post #37
zepto wrote: post #29

Earlier quoted context omitted.

Actually the bigger reason is compile time - better optimizations based on JavaScript semantics are a secondary advantage.

I think that's mostly accurate, in the sense that we wouldn't have done this if it was only motivated by specializing for JavaScript semantics. We had gotten pretty good at having our high-level compiler (DFG) burn away the JavaScript crazy and leave behind fairly tight code for LLVM to optimize. But as soon as we realized that we had such a huge compile time opportunity, of course we optimized the heck out of the ne…

But isn't it true that some of the things you ended up doing would make sense for LLVM, or would most of them be invalidated by the kinds of optimization passes that are common in LLVM?

E.g. stuff like making the in-memory IR representation better cacheable certainly sounds like it's all-upside, and LLVM should just learn from your project.

Re: Introducing the B3 JIT compiler

#64

Post by nickpsecurity »

pizlonator wrote: post #57
nickpsecurity wrote: post #49

Earlier quoted context omitted.

I've never heard anyone say Ada was easy to compile. Also, I heard its uptake was slowed by how hard it was to get the early compilers working. So, where did you see an easy one? Seriously, because Ada still needs a CompCert (or at least FLINT) style certified compiler. An easy Ada compiler would be a nice start on that.

I always thought that Ada was easy to compile in the backend (i.e. the moral equivalent of what B3 does) but challenging on the frontend because of how large the language is. Could be wrong though. The frontend is usually the hard part IMO. In WebKit, we have 100,000 lines of code for our "frontend" (i.e. the DFG compiler) and 50,000 lines of code for our "backend" (i.e. B3). That split is really interesting.

It's what I thought, too. The split may come from the fact that the front-end is more complex, richer in information, harder to analyze, and harder to transform. The more you can do with it the more code it takes to represent. That's my hypothesis.

Far as Ada, I figured it would be difficult due to the large number of language features and complexities of analyzing a program for safety w/ all its rules. And any interactions that might emerge in that between features and rules. Could be easier than I think but my default belief is that it's not easy.

Re: Introducing the B3 JIT compiler

#65

Post by nickpsecurity »

pjmlp wrote: post #60
nickpsecurity wrote: post #47

Earlier quoted context omitted.

Can't critique this one: Go was an attempt to re-create the Oberon experience in modern setting with some additions from other languages. Rather than accidental re-discovery, getting Oberon (not Pascal) speed out of the compiler was an explicit design goal. One of few examples of modern IT really learning from the past. Unfortunately, they didn't learn about the stuff between Oberon and 2007 that would've been nice t…

It is not a critic, apparently it was understood as such. The remark is tailored to those that think compiled languages can only be slow as C and C++ compilers, since they never used anything else, and then jump of joy when they use Go. Yet if it wasn't for the VM detour of the last 20 years, that experience would probably be a current one, instead of being re-discovered.

"The remark is tailored to those..."

Ahh. Ok.

"Yet if it wasn't for the VM detour of the last 20 years"

You mean the C++ and VM detours? ;)

Re: Introducing the B3 JIT compiler

#66

Post by pizlonator »

cosinusoidally wrote: post #62
pizlonator wrote: post #11

Earlier quoted context omitted.

ajross is right. People choose the languages they like regardless of performance. JS perf is important to users though. Faster execution means fewer watts spent rendering and interacting with your favorite web page. (Fun fact: B3's backend contains a machine description language that gets compiled to C++ code by a ruby script, opcode_generator.rb. We use Ruby a lot.)

Why didn't you use JavaScript for that purpose (in a similar vein to how LuaJIT uses Lua for dynasm)?

I'm not a big fan of self-hosting. I like that you can build JavaScriptCore without using JavaScriptCore.

Re: Introducing the B3 JIT compiler

#67

Post by pizlonator »

dochtman wrote: post #63
pizlonator wrote: post #37

Earlier quoted context omitted.

I think that's mostly accurate, in the sense that we wouldn't have done this if it was only motivated by specializing for JavaScript semantics. We had gotten pretty good at having our high-level compiler (DFG) burn away the JavaScript crazy and leave behind fairly tight code for LLVM to optimize. But as soon as we realized that we had such a huge compile time opportunity, of course we optimized the heck out of the ne…

But isn't it true that some of the things you ended up doing would make sense for LLVM, or would most of them be invalidated by the kinds of optimization passes that are common in LLVM? E.g. stuff like making the in-memory IR representation better cacheable certainly sounds like it's all-upside, and LLVM should just learn from your project.

LLVM's use of a very rich (and hence not as memory efficient) IR is deeply rooted. Phases assume that given any value, you can trace your way to its uses, users, and owners. The LLVM code I've played with assumes this all over the place, so removing the use lists and owner links as B3 does would be super hard. B3 can do it because we started off that way.

Re: Introducing the B3 JIT compiler

#70

Post by pjmlp »

nickpsecurity wrote: post #65
pjmlp wrote: post #60

Earlier quoted context omitted.

It is not a critic, apparently it was understood as such. The remark is tailored to those that think compiled languages can only be slow as C and C++ compilers, since they never used anything else, and then jump of joy when they use Go. Yet if it wasn't for the VM detour of the last 20 years, that experience would probably be a current one, instead of being re-discovered.

"The remark is tailored to those..." Ahh. Ok. "Yet if it wasn't for the VM detour of the last 20 years" You mean the C++ and VM detours? ;)

I mean having the JVM not adopt the tooling model of Eiffel, OCaml and others where you get to choose bytecode/JIT for developing and AOT compilation for release builds.
Post reply on HN