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

71–80 of 131 posts

Re: Introducing the B3 JIT compiler

#71

Post by derefr »

geodel wrote: post #50
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.)

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

"Compiler optimization" in this thread is referring to speeding up compilation time†, not runtime of generated code. Go produces fast code, but the go compiler does not generate that code particularly quickly.

† Which can be seen as a runtime cost for interpreter+JIT languages, but that's a different issue. We're talking time-to-steady-state when the interpreter is fed a file (which is something Javascript engine devs worry about a lot), not benchmark-speed-at-steady-state.

Re: Introducing the B3 JIT compiler

#72

Post by eddyb »

killercup wrote: post #56
sklogic wrote: post #38

Earlier quoted context omitted.

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

You are probably right, assuming input programs are correct. Rust (and Haskell) is not easy to _type-check_ though.

You can't compile Rust without types and inside functions, most types come from inference and coercions, so "type checking" is really "type resolution".

Re: Introducing the B3 JIT compiler

#73

Post by Ono-Sendai »

chipsy wrote: post #59
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…

You're reading it too politically. It says right up in the first paragraph: > While LLVM is an excellent optimizer, it isn’t specifically designed for the optimization challenges of dynamic languages like JavaScript. LLVM was, more-or-less, designed around C++ semantics. B3 is not going to be a better C++ compiler than LLVM. LLVM is not going to be a better JS compiler than B3. They're taking different evolutionary p…

LLVM compiles fast code for things that aren't C++ as well. Maybe you could say it's biased towards static languages.

Also its compilation speed is supposed to be fast in terms of AOT compilation, but not necessarily fast enough for JITing javascript in web-pages.

Re: Introducing the B3 JIT compiler

#74

Post by pcwalton »

derefr wrote: post #71
geodel wrote: post #50

Earlier quoted context omitted.

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

"Compiler optimization" in this thread is referring to speeding up compilation time †, not runtime of generated code. Go produces fast code, but the go compiler does not generate that code particularly quickly. † Which can be seen as a runtime cost for interpreter+JIT languages, but that's a different issue. We're talking time-to-steady-state when the interpreter is fed a file (which is something Javascript engine de…

No, it's the opposite. The Go compiler generates medium quality code but compiles fast.

Re: Introducing the B3 JIT compiler

#75

Post by ksec »

ehsanu1 wrote: post #52
pizlonator wrote: post #40

Earlier quoted context omitted.

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?

Search around for "Substrate VM". I see it referenced in some slide decks, and it's designed to make JVM startup much faster. Here's an old slidedeck that talks about it: http://www.oracle.com/technetwork/java/jvmls2013wimmer-20140...

Wow thx for the reminder, I have forgotten about it already. I remember the promise of Truffle + Graal + Substrate VM.

My god can't believe it was 3 years ago i read about it on HN.

Re: Introducing the B3 JIT compiler

#76

Post by sklogic »

pizlonator wrote: post #58
sklogic wrote: post #43

Earlier quoted context omitted.

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

LOL! It is expressive though. It's got really powerful first-class functions. It's got classes. It's got prototypes. It's got generators. It's got other things that I don't even remember (but will probably have to learn, to implement them, make them fast, and then fix the bugs). I actually think that the reason why JS is so odd is that it is so expressive. That tends to happen with kitchen sink languages like C++. Re…

More expressive than a less imaginative subset of C. More expressive than assembler. Much less expressive than any decent high-level language.

Javascript is low level, primitive and clumsy. There is absolutely no excuse for it being so crappy.

If you still think it is "expressive", you never seen an expressive language.

Re: Introducing the B3 JIT compiler

#77

Post by ksec »

om2 wrote: post #44
MrBuddyCasino wrote: post #8

Earlier quoted context omitted.

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%!

Considering there are now 1Billion Active iOS devices, that 5% saving is huge!

I wonder if this will make in time for iOS10.

Re: Introducing the B3 JIT compiler

#78

Post by nickpsecurity »

pjmlp wrote: post #70
nickpsecurity wrote: post #65

Earlier quoted context omitted.

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

Oh i hear you. That makes sense. I wanted all of them to do incremental compilation or interactive development for build then AOT for deploy. We're on same page there.

Re: Introducing the B3 JIT compiler

#79

Post by nly »

ajross wrote: post #4
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.

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.

> optimized scalar code performance has moved, what, maybe 40% over the last two decades

I'm not convinced. Raw single-thread number crunching performance is somewhere around _two to three fold_, clock-for-clock, on Intel x86, over that of 10-15 years ago. What methodology do you use to attribute only a fraction of those gains to language optimizers? And even if you are correct, why is it meaningful? Who is going to have invested energy in optimising the shit out of mundane codegen when hardware performance will have just come and stolen your thunder a few months later?

The problem we have now is that CPUs are gaining ever more complex behaviour, peculiarities, and sensitivities. I'd say compiler engineering is far from a "solved problem", even for statically-typed languages.

Re: Introducing the B3 JIT compiler

#80

Post by jsnell »

panic wrote: post #68

Cool stuff! Does anyone know why the geometric mean is used for averaging benchmark scores rather than the usual arithmetic mean?

I would say that geometric mean is the usual way of averaging benchmark scores. It has the property that a given relative speedup on a component benchmark always has the same effect on the aggregate score. With an arithmetic mean the component benchmarks with a longer runtime will dominate the aggregate. Normalizing the results before applying the arithmetic mean doesn't really help either -- the first X% improvement to a component benchmark would still be valued more than the second X% speedup.
Post reply on HN