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

91–100 of 131 posts

Re: Introducing the B3 JIT compiler

#91

Post by igouy »

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

> … and much higher memory usage compared to Go.

Please don't jump to the conclusion that huge differences in the default memory allocation of tiny 100 line programs means there will be similar huge differences between ordinary large programs.

Notice that even for those tiny 100 line programs, the difference can be more like 2x when memory actually needs to allocated for the task.

Re: Introducing the B3 JIT compiler

#92

Post by iso-8859-1 »

cosinusoidally wrote: post #62
pizlonator wrote: post #11

Earlier quoted context omitted.

ajross is right. People choose the languages they like regardless of performance. JS perf is important to users though. Faster execution means fewer watts spent rendering and interacting with your favorite web page. (Fun fact: B3's backend contains a machine description language that gets compiled to C++ code by a ruby script, opcode_generator.rb. We use Ruby a lot.)

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

Suppose that you are developing not to push this platform, but to simple do better on this platform. What does self-hosting gain you in that case?

Re: Introducing the B3 JIT compiler

#93

Post by nickpsecurity »

sklogic wrote: post #86
nickpsecurity wrote: post #49

Earlier quoted context omitted.

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.

That makes more sense. Did you ever work on any Ada compiler I might have heard of?

Re: Introducing the B3 JIT compiler

#94

Post by [deleted] »

pcwalton wrote: post #88
rayiner wrote: post #83

Earlier quoted context omitted.

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

[deleted]

Re: Introducing the B3 JIT compiler

#95

Post by pcwalton »

sklogic wrote: post #90
pcwalton wrote: post #87

Earlier quoted context omitted.

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

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 dynamic and expressive.

Re: Introducing the B3 JIT compiler

#96

Post by barkingcat »

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…

Not a knock on LLVM. The conditions are just different. There is no software that is 100% great at every single thing - that's why Windows embedded CE failed while iOS and Android thrived on phone and mobile devices.

VxWorks is great at driving martian rovers, but would be horrible at running Adobe Photoshop or Maya.

Why does everything either need to be a snub or a boon?

LLVM is great at generating compiled binaries - it just takes resources (time + memory) to do so - in practical terms, the compilation time only affects the programmers and developers running multiple compiles over a work day, working on the codebase itself. For consumers who are running the programs, LLVM makes great optimized binaries.

In a JS engine, the compiler doesn't have access to the source code until a user loads up the page, so it's in essence doing "compilation" on the spot. And in this case compilation memory and time usage matters.

Swift itself is a "compiled" lanugage - meaning that in development, a developer needs to hit that "compile" button in XCode to generate a binary file which is then distributed and run. In this case, LLVM can use all cores on that big honking Mac Pro or shiny MacBook Pro 15" retina all it wants - take all 16 cpus and 32 gigs of ram and crank it and make a nice binary that comes out optimized to run on a iPad Air.

Of course things like Java conflates the two styles (source code compiled to bytecode and then to run on the JVM) - but in the Java ecosystem there are significant optimizations in both the compile phase (ie javac helloworld.java) as well as ahead of time compilation in the JVM itself.

Re: Introducing the B3 JIT compiler

#97

Post by pcwalton »

sklogic wrote: post #85
pcwalton wrote: post #51

Earlier quoted context omitted.

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

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

That's because (a) page performance is frequently gated on things other than JavaScript, so people don't go through a lot of trouble to write C++; (b) many modules that would be written in C in Python are provided by the browser itself; (c) JS itself is usually fast enough, since the gap between JS and C++ is much less than the gap between Python and C++.

> As for virtual methods, it is a problem of a bad C++, devirtualisation may help, but nobody cares in general.

Huh? Tons of people care about devirtualization! Much of the reason Firefox builds go to the trouble of PGO (and it is a huge amount of trouble) is to get devirtualization.

> As for virtual methods, it is a problem of a bad C++

So I could say the same thing about JavaScript: if it's slow, you're writing "bad JS". But you would rightly reject that as invalid: if the code people write in practice is slow, then the problem is with the language encouraging people to write slow code. The point is that the same thing applies to C++.

Re: Introducing the B3 JIT compiler

#98

Post by barkingcat »

derefr wrote: post #69
klodolph wrote: post #61

Earlier quoted context omitted.

This comment, and the parent comment, seem to be conflating "dynamic language" with "dynamically-typed language".

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 languages are about.

Re: Introducing the B3 JIT compiler

#99

Post by Alphasite_ »

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.

Re: Introducing the B3 JIT compiler

#100

Post by Joky »

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.

> Compilers are sexy, but they're very much a solved problem

No they're not, and won't be for long (ever?). However it does not matter because they are "good enough".

Compilers are driven by heuristics which provide "reasonable" results in most cases for common architectures. But they still leave a lot on the table. Compiler writers have to trade compile-time with execution-time. Now we're not talking about an order of magnitude, but rather ~20%-30% in some workloads. When it matters (I guess for people like Google/Facebook/Amazon/... it translates in electricity bill and a number of racks to add to the datacenter) people may have to get down to the assembly level for a very small (and hot) part of the program.

Post reply on HN