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

31–40 of 131 posts

Re: Introducing the B3 JIT compiler

#31

Post by geofft »

sklogic wrote: post #15
munificent wrote: post #2

Really cool article. Posts like this always make me wonder what the state of the programming would be if browsers hadn't sucked up almost all of the world's compiler optimizers.

They're solving a non-issue. The rest of the world is perfectly fine with the statically typed, well designed languages that are easy to compile. And only the web world is so obssessed with smart compilers compensating (impressively, but still far from being sufficient) for multiple deficiencies in the language design.

> statically typed, well designed languages that are easy to compile

Which ones are these? All of the statically-typed and well-designed languages I can think of are, at the least, hard to compile well, if not hard to compile in the first place. (Haskell and Rust both come to mind; there are few Haskell compilers other than GHC, and no Rust compilers other than rustc.) The languages that are easier to compile are either not statically-typed in a useful way, or not well-designed, or both.

Re: Introducing the B3 JIT compiler

#32

Post by gsg »

Ecco wrote: post #25

I'm really wondering about the politics behind all this. I mean both LLVM and WebKit are Apple projects (even though they're Open Source). So it would have been reasonable to expect an improvement of LLVM instead of ditching it altogether.

Specialising LLVM for dynamic compilation might well come at the expense of LLVM's strengths as an AoT compiler, and it would probably not be easy in any case.

In addition to that, dedicated implementations can take various shortcuts to make their job easier - there are some nice examples given in the link. LuaJIT is example of a compiler project that benefits from being heavily specialised to a particular job, to remarkable effect.

Re: Introducing the B3 JIT compiler

#33

Post by pjmlp »

pcwalton wrote: post #17
geodel wrote: post #7

Earlier quoted context omitted.

Lately quite a few apps are saving energy by moving from Ruby/Python/PHP to Go.

And Go proves munificent's point: it doesn't have many compiler optimizations either. (This may change with the WIP SSA backend, but the point remains that Go gained huge popularity in spite of having a non-optimizing compiler.)

Yeah, more interesting is having them rediscovering Turbo Pascal compile speeds.

EDIT: I wonder why the positive effect to re-discovering that not all compilers need to be like C and C++ compile speeds and that it was once upon a time mainstream, is worthy of downvotes.

Re: Introducing the B3 JIT compiler

#34

Post by beagle3 »

munificent wrote: post #2

Really cool article. Posts like this always make me wonder what the state of the programming would be if browsers hadn't sucked up almost all of the world's compiler optimizers.

Look at what Mike Pall did with LuaJIT2 - I assume if the world wasn't so focused on the web, we would see more of it in other languages. But really, things aren't that bad. Microsoft has enough good people working on RyuJIT, PyPy has some of the best people advancing metatracing JITs, and Mike Pall is a god among men.

Re: Introducing the B3 JIT compiler

#35

Post by gsg »

geofft wrote: post #31
sklogic wrote: post #15

Earlier quoted context omitted.

They're solving a non-issue. The rest of the world is perfectly fine with the statically typed, well designed languages that are easy to compile. And only the web world is so obssessed with smart compilers compensating (impressively, but still far from being sufficient) for multiple deficiencies in the language design.

> statically typed, well designed languages that are easy to compile Which ones are these? All of the statically-typed and well-designed languages I can think of are, at the least, hard to compile well , if not hard to compile in the first place. (Haskell and Rust both come to mind; there are few Haskell compilers other than GHC, and no Rust compilers other than rustc.) The languages that are easier to compile are ei…

SML? Pascal?

Edit: I was really referring to language families, so including things like OCaml, Modula, etc.

Re: Introducing the B3 JIT compiler

#36

Post by sklogic »

pcwalton wrote: post #18
sklogic wrote: post #15

Earlier quoted context omitted.

They're solving a non-issue. The rest of the world is perfectly fine with the statically typed, well designed languages that are easy to compile. And only the web world is so obssessed with smart compilers compensating (impressively, but still far from being sufficient) for multiple deficiencies in the language design.

> The rest of the world is perfectly fine with the statically typed, well designed languages that are easy to compile. Python, Ruby, PHP, and Perl aren't "the rest of the world"? As far as compilers are concerned, all of those languages have more troublesome semantics than JavaScript does. > And only the web world is so obssessed with smart compilers compensating (impressively, but still far from being sufficient) fo…

Nobody really cares about their performance. They're just fine with their simple interpreters. Web is different, there is no choice, no fallback to C.

And no, thank you kind sir, but I've got a very good idea of what compilers are doing wrt. C deficiencies, I was writing OpenCL compilers for 6 years at least. Besides aliasing stupidity and byte-addressing there is nothing really bad to compensate for.

Re: Introducing the B3 JIT compiler

#37

Post by pizlonator »

zepto wrote: post #29
legulere wrote: post #28

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.

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 new compiler for the kinds of things that we always wished LLVM could do - like very lightweight patchpoints and some opcodes that are an obvious nod for what dynamic languages want (ChillDiv, ChillMod, CheckAdd, CheckSub, CheckMul, etc).

Re: Introducing the B3 JIT compiler

#38

Post by sklogic »

geofft wrote: post #31
sklogic wrote: post #15

Earlier quoted context omitted.

They're solving a non-issue. The rest of the world is perfectly fine with the statically typed, well designed languages that are easy to compile. And only the web world is so obssessed with smart compilers compensating (impressively, but still far from being sufficient) for multiple deficiencies in the language design.

> statically typed, well designed languages that are easy to compile Which ones are these? All of the statically-typed and well-designed languages I can think of are, at the least, hard to compile well , if not hard to compile in the first place. (Haskell and Rust both come to mind; there are few Haskell compilers other than GHC, and no Rust compilers other than rustc.) The languages that are easier to compile are ei…

Rust is actually quite easy to compile. Ada is easy to compile. ML-like languages are easy to compile. Oberon is trivial to compile.

Re: Introducing the B3 JIT compiler

#39

Post by seanwilson »

munificent wrote: post #5
ajross wrote: post #4

Earlier quoted context omitted.

To be fair, GPU vendors sucked up a ton too. But considering that optimized scalar code performance has moved, what, maybe 40% over the last two decades, I'm going to say "not much". Compilers are sexy, but they're very much a solved problem. If we were all forced to get by with the optimized performance we saw from GCC 2.7.2, I think we'd all survive. Most of us wouldn't even notice the change.

> Compilers are sexy, but they're very much a solved problem. Not for all of the other widely-used languages that still have incredibly simple interpreters. Think how much energy could have been saved if Ruby, Python, and PHP were all as fast as your average JS engine.

> Think how much energy could have been saved if Ruby, Python, and PHP

I would think we'd see even better improvements if developers would move towards statically typed languages as well.

Re: Introducing the B3 JIT compiler

#40

Post by pizlonator »

chrisseaton wrote: post #21
VeejayRampay wrote: post #6

Earlier quoted context omitted.

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

My implementation of Ruby, JRuby+Truffle, is as fast as V8 http://stefan-marr.de/downloads/crystal.html

Note that usually being "as fast as" a production JSVM means also proving that you can start up as fast as JSVMs do. Have you done this?
Post reply on HN