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

101–110 of 131 posts

Re: Introducing the B3 JIT compiler

#101

Post by Joky »

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

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 a LLVM developer on optimizing for high-level languages: http://lists.llvm.org/pipermail/llvm-dev/2016-February/09546...

Re: Introducing the B3 JIT compiler

#102

Post by Joky »

dochtman wrote: post #63
pizlonator wrote: post #37

Earlier quoted context omitted.

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…

But isn't it true that some of the things you ended up doing would make sense for LLVM, or would most of them be invalidated by the kinds of optimization passes that are common in LLVM? E.g. stuff like making the in-memory IR representation better cacheable certainly sounds like it's all-upside, and LLVM should just learn from your project.

There is a tradeoff between having a dense and compact IR and being able to modify it very easily. LLVM tends to focus on the second. Even if there are plan to balance a bit more, this will take a lot of time (and benchmarking).

Re: Introducing the B3 JIT compiler

#103

Post by cosinusoidally »

pizlonator wrote: post #66
cosinusoidally wrote: post #62

Earlier quoted context omitted.

Why didn't you use JavaScript for that purpose (in a similar vein to how LuaJIT uses Lua for dynasm)?

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.

Re: Introducing the B3 JIT compiler

#104

Post by bluejekyll »

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.

I don't understand this perspective. Is the point that JavaScript just works such that you don't have to worry about it compiling at runtime?

To me this is the difference between knowing that your program will probably work after it compiles, vs not knowing until after its deployed.

What I think people really enjoy in dynamic languages like JavaScript is the instant feedback, just reloading the browser. This can be accomplished with decent IDEs for most statically typed languages.

Re: Introducing the B3 JIT compiler

#105

Post by ehsanu1 »

pizlonator wrote: post #54
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?

I know about it. I'm not concerned with future hypotheticals, but current actual measurements. That's the currency I deal in.

There seem to be measurements in the slides I reference, so it wasn't exactly "future work". But of course it sucks that this work is not yet publicly available (AFAIK), probably due to not being 100% production ready yet. But I'm sure it's getting there.

Re: Introducing the B3 JIT compiler

#106

Post by bluejekyll »

pizlonator wrote: post #10
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?

3 months. Two people working on it (me and @awfulben).

Out of curiousity, did you look at improving LLVM compile times? I didn't get that out of the article.

Awesome write up btw.

Re: Introducing the B3 JIT compiler

#107

Post by geofft »

bluejekyll wrote: post #104
killercup wrote: post #56

Earlier quoted context omitted.

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

I don't understand this perspective. Is the point that JavaScript just works such that you don't have to worry about it compiling at runtime? To me this is the difference between knowing that your program will probably work after it compiles, vs not knowing until after its deployed. What I think people really enjoy in dynamic languages like JavaScript is the instant feedback, just reloading the browser. This can be a…

I don't believe anyone's arguing that the overhead of static checking is not worthwhile, merely that it involves serious work on the part of the compiler developers that should not be dismissed.

Re: Introducing the B3 JIT compiler

#108

Post by DannyBee »

Alphasite_ wrote: post #99
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 ...

I imagine they did, considering the head of LLVM is a (probably distant) coworker of theirs.

"The head of LLVM" - no such thing exists, but okay. (People have such weird ideas about how these projects work in practice).

Re: Introducing the B3 JIT compiler

#109

Post by DannyBee »

Joky wrote: post #101
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 ...

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 write a new one. None of them ever get to a truly good state.

Rinse, wash, repeat.

The only thing these things make real progress, is by doing what LLVM did - someone works on it for years.

Let me quote a former colleague at IBM - "there is no secret silver bullet to really good compilers, it's just a lot of long hard work". If you keep resetting that hard work every couple years, that seems ... silly.

TL;DR If you really believe they've totally gotten everywhere they need to be in 3 months, i've got a bridge to sell you

[1] For example, good loop vectorization and SLP vectorization is hard.

Re: Introducing the B3 JIT compiler

#110

Post by sklogic »

pcwalton wrote: post #95
sklogic wrote: post #90

Earlier quoted context omitted.

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

I have no idea what the Jikes RVM has to do with "ideology". The point is that you're trying to tell someone who has a significant academic and industrial PL pedigree that they don't know what an expressive language is. You seem to have an intense dislike of JavaScript. I'll the first one to admit that JavaScript has a lot of problems. But not being expressive enough is not one of them. JS is, if anything, too dynami…

Yes, if he thinks that JS is expressive he does not know what is expressive. And his track record clearly lacks anything related to any expressive language. I can only explain it with an ideology, because ignorance is not an option here.

And, no, JS is not expressive. It got strict limits on an available level of abstraction (unless you go into eval, of course).

Post reply on HN