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

51–60 of 131 posts

Re: Introducing the B3 JIT compiler

#51

Post by pcwalton »

sklogic wrote: post #36
pcwalton wrote: post #18

Earlier quoted context omitted.

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

> Web is different, there is no choice, no fallback to C.

asm.js and Web Assembly.

> Besides aliasing stupidity and byte-addressing there is nothing really bad to compensate for.

Aliasing issues, C++ heavy reliance on virtual methods, too many levels of indirection in the STL, overuse of signed integers due to "int" being easier to type interfering with loop analysis, const being useless for optimization, slow parsing of header files...

Re: Introducing the B3 JIT compiler

#52

Post by ehsanu1 »

pizlonator wrote: post #40
chrisseaton wrote: post #21

Earlier quoted context omitted.

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?

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

Re: Introducing the B3 JIT compiler

#53

Post by pizlonator »

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.

Re: Introducing the B3 JIT compiler

#54

Post by pizlonator »

pizlonator wrote: post #40
chrisseaton wrote: post #21

Earlier quoted context omitted.

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?

I know about it. I'm not concerned with future hypotheticals, but current actual measurements.

That's the currency I deal in.

Re: Introducing the B3 JIT compiler

#55

Post by pcwalton »

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

> Are you claiming Go runs at the speed of Ruby/Python/PHP etc?

No. I'm claiming it doesn't perform anywhere near the level of optimization of GCC and LLVM.

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

I disagree with what seems to be your implication that compiler optimizations don't matter (and almost everyone else who works on compilers would also disagree), but I don't really want to turn this thread into a critique of the benchmarks game, so let's just leave it at that.

Re: Introducing the B3 JIT compiler

#56

Post by killercup »

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.

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

Re: Introducing the B3 JIT compiler

#57

Post by pizlonator »

nickpsecurity wrote: post #49
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.

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.

Re: Introducing the B3 JIT compiler

#58

Post by pizlonator »

sklogic wrote: post #43
yxhuvud wrote: post #14

Earlier quoted context omitted.

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

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

Relevant: "There are only two kinds of programming languages: those people always bitch about and those nobody uses."

Re: Introducing the B3 JIT compiler

#59

Post by chipsy »

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

Re: Introducing the B3 JIT compiler

#60

Post by pjmlp »

nickpsecurity wrote: post #47
pjmlp wrote: post #33

Earlier quoted context omitted.

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

Post reply on HN