IDE support?

[Brendan Eich]

On Sep 15, 2011, at 11:57 AM, Andreas Rossberg wrote:

> On 13 September 2011 16:48, Brendan Eich <brendan at mozilla.com> wrote:
>> On Sep 13, 2011, at 5:33 AM, Andreas Rossberg wrote:
>>> 
>>> * There are extra costs in space and time to doing the runtime analysis.
>>> * Compile time is runtime, so there are severe limits to how smart you
>>> can afford to get in a compiler.
>> 
>> These are bearable apples to trade against the moldy oranges you'd make the world eat by introducing type annotations to JS. Millions of programmers would start annotating "for performance", i.e., gratuitously, making a brittle world at high aggregate cost.
>> 
>> The costs born in browsers by implementors and (this can hit users, but it's marginal) at runtime when evaluating code are less, I claim.
> 
> Depends on how good you want to optimize. Aggressive compilers can be
> really slow. There are limits to what you can bear at runtime.

You the user, yes -- good point. It's not just an implementor's burden.


>>> * The massive complexity that comes with implementing all this affects
>>> stability.
>> 
>> This one I'm less sympathetic to, since we won't get rid of untyped JS up front. A sunk cost fallacy? If we could make a "clean break" (ahem), sure. Otherwise this cost must be paid.
> 
> Well, the counter-argument would be that you wouldn't need to care
> about optimising untyped code as much, if the user had the option to
> switch to a typed sublanguage for performance.

I was really turned off by how AS3 users over-annotate. If we added "guards" and users turned to them "for performance", I'm afraid we'd see the same contamination.

Annotating might not even help performance -- in AS3, evaluation of arithmetic operators must widen from int to double, not wrap around 32 bits, so annotating int on storage types that annotate slots fetched and used via +, *, etc. can actually lose performance when storing back, since you have to use the FPU, or analyze and guard on overflow (as JS engines do today to avoid the FPU).

More analysis can help to stick to the ALUs but that works for untyped JS too.

Still, I agree that for performance-critical storage, annotations help. This is obviously so with typed arrays, which the fast VMs target with dedicated type inference and instruction selection machinery.

Is there a way to avoid the contamination problem we saw with AS3 during the ES4 days?


>>> * Wrt limits, even in the ideal case, you can only approximate the
>>> performance of typed code -- e.g. for property access you have at
>>> least two memory accesses (type and slot) plus a comparison and
>>> branch, where a typed language would only do 1 memory access.
>> 
>> That's *not* the ideal case. Brian Hackett's type inference work in SpiderMonkey can eliminate the overhead here. Check it out.
> 
> I'm actually pretty excited about that, and hope to see more on that
> front. Cool stuff.
> 
> However, that ideal case is achieved in a relatively small percentage
> of cases only. Otherwise we should probably not see a (already
> impressive) 20-40% speed-up (IIRC), but rather something closer to
> 200-400%.

Oh, we're not done! The current work does not analyze the heap as aggressively as it might. We want objects that can be, say, four int32 machine types in a row, to be inferred that way and represented that way. Currently such a type would take four "any" values in a row, plus the usual header for metadata.


> So the inferencer has to work with approximations and fallbacks. For a
> language like JS, where a lot of conceptual polymorphism, potential
> mutation, and "untypable" operations are going on, those
> approximations will remain omnipresent, except, mostly, in
> sufficiently local contexts.

Yes, and a key element of TI in SpiderMonkey is to put the "monster in the box" -- to avoid the untyped abstractions in one's JS polluting the whole inference. We try to fall back on runtime PICs and the other dynamic optimizations where we can. This means some guarding, or to avoid guards, some invalidation protocol overhead instead of guards. And low-level barriers to monitor all writes.


> Not to say that it is not worth extending the boundaries -- it
> definitely is. But it will only get you that far.

Farther enough than without, that it seems worth it. Again for me the big cosmic god-mode tradeoff is implementors working harder on these approaches, vs. throwing users to the wolves of type (over-)annotation.


>> Type annotations or (let's say) "guards" as for-all-time monotonic bounds on mutation are useful to programmers too, for more robust programming-in-the-large. That's a separate (and better IMHO) argument than performance. It's why they are on the Harmony agenda.
> 
> Of course I'd never object to the statement that there are far better
> reasons to have typy features than performance. :) I just didn't
> mention it because it wasn't the topic of the discussion.

It's useful to be reminded of the performance wins that are possible with judicious use of type annotations, though. I expect we'll feel some "darts" (lol) in our backside on this point (heh).


>>> So despite all the cool technology we use these days, it is safe to
>>> assume that we will never play in the performance league of typed
>>> languages. Unless we introduce real types into JS, of course. :)
>> 
>> Does JS need to be as fast as Java? Would half as fast be enough?
> 
> No, it doesn't have to be as fast. Not yet, at least... I estimate we
> have another 3 years. ;)

Agreed!

/be