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

81–90 of 131 posts

Re: Introducing the B3 JIT compiler

#81

Post by nteon »

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…

what is memory usage like in terms of number of allocations and peak RSS with B3 vs. LLVM?

Re: Introducing the B3 JIT compiler

#82

Post by DasIch »

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…

LLVM is designed for languages that are compiled ahead of time like C and C++. In these cases it's not that important how much time and memory it takes to compile something.

If you're working on a JIT, this matters. A lot. Webkit isn't the first project has has used or worked with LLVM in this manner and abandoned it. PyPy has also investigated using LLVM and stopped doing that.

LLVM isn't bad, it just isn't good at solving this problem it wasn't designed for. If anything, I think it's remarkable LLVM has worked out as well for Webkit as it did.

Re: Introducing the B3 JIT compiler

#83

Post by rayiner »

nly wrote: post #79
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.

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

> The problem we have now is that CPUs are gaining ever more complex behaviour, peculiarities, and sensitivities.

With mainstream CPUs, exactly the opposite is happening. CPUs are getting more complex under the hood, but less sensitive to code quality. For example, a lot of the scheduling hazards in the P6 microarchitecture have been eliminated in subsequent iterations. Branch delay slots are a thing of the distant past, so are pipeline bubbles for taken branches, indirect branch prediction is extremely capable, even the penalty on unaligned accesses is minimal.

Re: Introducing the B3 JIT compiler

#84

Post by pizlonator »

pcwalton wrote: post #51
sklogic wrote: post #36

Earlier quoted context omitted.

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 parsin…

All of this!

For example in JS, once you prove that "o.f = v" is not going to hit a setter (or you put a speculative check to that effect), then you know that this effect does not interfere with "v = o.g" (provided you check that it's not a getter). JS VMs are really good at speculating about getters and setters. The result is that alias analysis, and its clients like common subexpression elimination, are super effective. It's only a matter of time before we're creating function summaries that list all of the abstract heaps that a procedure can clobber so even a function call has bounded interference.

This is totally different from C. There, making sure that accesses to o->f and o->g don't interfere is like pulling teeth. And the user can force you to assume that they always interfere by using -fno-strict-aliasing, which is hugely popular.

The fallback-to-C paths on the web aren't that great, though. At least not yet. Once you fall back to C, you're sandboxed into a linear heap with limited access to the DOM and JS heap. But we'll fix that eventually. :-)

Re: Introducing the B3 JIT compiler

#85

Post by sklogic »

pcwalton wrote: post #51
sklogic wrote: post #36

Earlier quoted context omitted.

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 parsin…

Web Assembly is not even there yet, asm.js up until recent was more a toy and a standalone runtime, I have not seen it being routinely used for a fallback, nothing like, say, python with C modules.

As for virtual methods, it is a problem of a bad C++, devirtualisation may help, but nobody cares in general. We have a cool curiously recurring template pattern instead.

But for the integers you're right. And signedness is still the most annoying source of bugs in the infamous LLVM instcombine.

Headers are a frontend issue, nothing to do with the optimisations.

Re: Introducing the B3 JIT compiler

#86

Post by sklogic »

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 am talking about the backend optimisations, not the frontend parts. Ada frontend got tons of sweet static information for the backend to consume.

Re: Introducing the B3 JIT compiler

#87

Post by pcwalton »

sklogic wrote: post #76
pizlonator wrote: post #58

Earlier quoted context omitted.

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.

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

Are you aware who Filip Pizlo is?

Re: Introducing the B3 JIT compiler

#88

Post by pcwalton »

rayiner wrote: post #83
nly wrote: post #79

Earlier quoted context omitted.

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

> The problem we have now is that CPUs are gaining ever more complex behaviour, peculiarities, and sensitivities. With mainstream CPUs, exactly the opposite is happening. CPUs are getting more complex under the hood, but less sensitive to code quality. For example, a lot of the scheduling hazards in the P6 microarchitecture have been eliminated in subsequent iterations. Branch delay slots are a thing of the distant p…

Well, sure, but SIMD more than compensates for all of that, given how hard autovectorization is. In fact, I think with things like AVX and NEON becoming ubiquitous, you can get more benefit out of writing in assembly (or intrinsics) than any time I can think of in the past 10 years.

Re: Introducing the B3 JIT compiler

#89

Post by DannyBee »

Interestingly, much of their complaints around pointer chasing, etc, are things LLVM plans on solving in the next 6-8 months. i'm a bit surprised they never bothered to email the mailing list and say "hey guys, any plans to resolve this" before going and doing all of this work. But building new JITs is fun and shiny, so ...

Re: Introducing the B3 JIT compiler

#90

Post by sklogic »

pcwalton wrote: post #87
sklogic wrote: post #76

Earlier quoted context omitted.

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.

> If you still think it is "expressive", you never seen an expressive language. Are you aware who Filip Pizlo is?

Of course - a low level guy. It is quite likely that he is either not exposed at all to any expressive languages or reject them out of ideological reasons (JikesRVM is quite a strong symptom of the latter case).
Post reply on HN