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

111–120 of 131 posts

Re: Introducing the B3 JIT compiler

#111

Post by nadav256 »

DannyBee wrote: post #109
Joky wrote: post #101

Earlier quoted context omitted.

LLVM instruction selection is slow , there is a "fast-path" which hasn't received much attention (it is only used for -O0 in clang). The new instruction selector work just started and will take a couple of years, considering the tradeoff between spending 3 months on it and waiting a few years for LLVM to be improved (without any guarantee of LLVM reaching the same speed as what they did). See also some thoughts from…

The problem with the path they've taken is it has a finite end. This is why, when they compare it to v8/etc, it's kind of funny. They all have the same curve. Basically all of these things, all of them, end up with roughly the same deficiencies once you cherry pick the low hanging fruit[1], and then they stall out, and get replaced a few years later when someone decides thing X can't do the job, and they need to writ…

Danny, you mentioned loop and SLP vectorization. One thing that bothered me while watching the development of the SLP and Loop vectorizers over the last two years was that developers who cared about SPEC added functionality that increased compile time. I remember one change that added a second phase that scans the entire IR in the SLP vectorizer to get a 1.4% win in one of the SPEC programs. I hoped the FTL project would be able to enable the vectorizers, but to my disappointment the vectorizers are too slow to justify the boost on javascript workloads.

Re: Introducing the B3 JIT compiler

#112

Post by pizlonator »

cosinusoidally wrote: post #103
pizlonator wrote: post #66

Earlier quoted context omitted.

I'm not a big fan of self-hosting. I like that you can build JavaScriptCore without using JavaScriptCore.

I wasn't really referring to self hosting. I was wondering whether it made sense to write tools like JavaScriptCore's offlineasm in JavaScript rather than Ruby (as LuaJIT does by using Lua for its dynasm tool). The LuaJIT build process actually builds a cut down copy for Lua for the purposes of running dynasm, which is then used to build parts of LuaJIT.

We spend time optimizing JavaScriptCore's build time. It's a hard problem and it's important when managing such a large project. People inevitably have to do clean builds and that sucks when you have >400k lines of C++ code.

So, naturally, we want to avoid building JSC twice. ;-)

Re: Introducing the B3 JIT compiler

#113

Post by [deleted] »

DannyBee wrote: post #89

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

[deleted]

Re: Introducing the B3 JIT compiler

#114

Post by jlebar »

It's worth noticing that most of the optimizations here are for "space" -- reducing the working set size or the number of memory accesses. CPUs have gotten much faster than memory blah blah. This is the sort of thing where microbenchmarks may mislead you, because you WSS is probably not realistic.

I think we don't have great tools for helping with this sort of optimization. One can use perf to find cache misses, but that doesn't necessarily tell the whole story, as you might blame some other piece of code for causing a miss. Maybe I should try cachegrind again...

Re: Introducing the B3 JIT compiler

#115

Post by gpderetta »

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…

Re: int, isn't it the reverse? I.e. don't compilers find loops using ints easier to optimise because they can assume the counter does not wrap?

Also, what do you mean by level of indirection in the STL? Pointer chasing or, I suspect, layers of layers of tiny functions that need to be inlined for reasonable performance?

Re: Introducing the B3 JIT compiler

#116

Post by gpderetta »

barkingcat wrote: post #98
derefr wrote: post #69

Earlier quoted context omitted.

What's a "dynamic language"?

Dynamic languages are (generally) not compiled ahead of time. It is possible to have static typing in a dynamic language in the sense that the code is interpreted at runtime (but the types are set statically in the code), and there is no "binary" that one runs. It used to be called interpreted language or "scripting" language - but I think the vocabulary shifted so the word "dynamic" more encompasses what the languag…

By that definition, AFAIK, Swift is neither a dynamic language nor dynamically typed.

Re: Introducing the B3 JIT compiler

#117

Post by chriswarbo »

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.

> Rust (and Haskell) is not easy to _type-check_ though.

Is that really the case? It seems to me that a Prolog-like resolution system, coupled with a constraint solver, would get most of the job done with little effort.

There are certainly many rules to keep track of, but in some cases the newer rules are strict generalisations of the older rules. For example, Haskell's original type classes are just a special-case of modern multi-parameter, flexible instances/contexts, etc. type classes. Likewise, we can implement constraint kinds, type class instance resolution and type equalities using one constraint solver.

Re: Introducing the B3 JIT compiler

#118

Post by eyan »

beagle3 wrote: post #34
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.

The Father, The Son, The Holy Ghost, and Mike Pall.

Re: Introducing the B3 JIT compiler

#119

Post by raattgift »

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…

Cool. "We took a dynamic language and made it fast(er again)".

And you're gonna apply that to the darkest corners of ES6? Whee, language theory nerd paradise!

I can't wait for the compilers targeting that using all sorts of really odd idioms that in effect work like fuzz testing.

https://www.destroyallsoftware.com/talks/the-birth-and-death...

Re: Introducing the B3 JIT compiler

#120

Post by raattgift »

pizlonator wrote: post #53
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.

On the typing front, maybe you'd find this recent paper entertaining: "Is Gradual Sound Typing Dead?" (link below)

The conclusion is that it's mostly dead or worse, because of the performance hit when typechecked code calls untyped code.

(And also because of the details of Typed Racket, which perfectly reasonably translates into ordinary untyped Racket, but then that is then mangled by GNU lightning (!).)

But...

"At the same time, we are also challenged to explore how our evaluation method can be adapted to the world of micro-level gradual typing, where programmers can equip even the smallest expression with a type annotation and leave the surrounding context untouched. We conjecture that annotating complete functions or classes is an appropriate starting point for such an adaptation experiment."

http://www.ccs.neu.edu/racket/pubs/popl16-tfgnvf.pdf

Post reply on HN