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

41–50 of 131 posts

Re: Introducing the B3 JIT compiler

#41

Post by sklogic »

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.

If Ruby, Python and PHP would suddenly disappear, even more effort and energy would have been saved.

Re: Introducing the B3 JIT compiler

#43

Post by sklogic »

yxhuvud wrote: post #14
ajross wrote: post #9

Earlier quoted context omitted.

Ruby has massive adoption, as do Python and Perl and PHP. Environments with objectively better performance like the JVM and .NET have not, in fact, done all that well comparatively in this environment (which is to say they've done fine too and achieved "massive" adoption, just not that much better than their slower competitors). In fact, looking at the market as it stands right now I'd say that performance concerns a…

Considering the massive speed improvements we have been seeing in Javascript, but also languages like Ruby, I'd say compilers is a solved problem for staticly compiled languages, but perhaps not as much for interpreted highly expressive languages.

Did you just call Javascript a "highly expressive" language? Really?!?

Re: Introducing the B3 JIT compiler

#44

Post by om2 »

MrBuddyCasino wrote: post #8
cpr wrote: post #3

Good to see the Webkit team (mostly Apple) continue putting serious energy into JS performance. Take a bit of guts to throw out the whole LLVM layer in order to get compilation performance... It's also encouraging to see them opening up about future directions rather than just popping full-blown features from the head of Zeus every so often. (Not that they owe us anything... ;-) (Edit: it's also damned impressive for…

Gutsy move indeed. Though I wonder, what was the development cost in real life cash for gaining those 5% of performance?

As Phil said, the development cost was not that high all things considered. But even if it was - think about the number of user-hours that 5% is leveraged across, and the resulting time savings and battery life savings for those users. It would be worth investing even more than we did for 5%!

Re: Introducing the B3 JIT compiler

#45

Post by alberth »

>> "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 (another dynamic language, and was created by the same person who created LLVM as well). [2]

Seems weird that the original creator of LLVM was able to make a dynamic language such as Swift - without any problems.

[1] https://news.ycombinator.com/item?id=11105231

[2] http://nondot.org/sabre/

Re: Introducing the B3 JIT compiler

#47

Post by nickpsecurity »

pjmlp wrote: post #33
pcwalton wrote: post #17

Earlier quoted context omitted.

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.

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 to have in a modern, app language. ;)

Re: Introducing the B3 JIT compiler

#48

Post by om2 »

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 generally ahead-of-time compiled, so compile speed doesn't matter as much. Many of the core parts of Swift also avoid highly dynamic semantics. The most dynamic parts are when interfacing with Objective-C classes, an area that has not been heavily optimized yet.

Re: Introducing the B3 JIT compiler

#49

Post by nickpsecurity »

sklogic wrote: post #38
geofft wrote: post #31

Earlier quoted context omitted.

> 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.

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.

Re: Introducing the B3 JIT compiler

#50

Post by geodel »

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.)

Are you claiming Go runs at the speed of Ruby/Python/PHP etc? Because from what I read, migration to Go from above mentioned language led to lot of hardware / memory saving. I'd think Java can certainly be considered having highly optimized compiler / runtime. But it has almost same performance as Go and much higher memory usage compared to Go.

http://benchmarksgame.alioth.debian.org/u64q/go.html

Post reply on HN