The best way to avoid the "over-annotation" of codes is probably to teach
users about WHEN or WHY they should add types guards. If you add the feature
and don't explain what's her purpose and what specific scenarii it can
solve, you'll get in trouble.
However, if you can coordinate with the whole community and publish a bunch
of blog posts explaining how to "type efficiently", you'll get great
results. But, in order to achieve that, all the implementations must be
optimized for the same specific cases.
JavaScripters are acustomated to a untyped language. They will not type
everthing because we know how handy it's to rely on compiler optimization.
The most critical part will be to teach cross-compiler makers and people
learning JavaScript after beeing used to, let's say, Java.
Anyway, another usage of type will be "automatic class instanciation from
json data". For exemple, let's say I've a type defined like this :
class A {
var myFirstField : B;
var mySecondField : B;
function areEqual() : bool {
if(myFirstField==null) { return mySecondField==null; }
if(mySecondField==null) { return false; }
return myFirstField.x == mySecondField.y;
}
};
class B { int x; int y; }
You can do things like that :
var myA = { myFirstField: {x:5, y:6}, mySecondField: {x:5, y:7} } as A;
console.log(myA.areEqual());
François
-----Message d'origine-----
From: Brendan Eich
Sent: Saturday, September 17, 2011 7:15 PM
To: Andreas Rossberg
Cc: [email protected]
Subject: Re: IDE support?
On Sep 15, 2011, at 11:57 AM, Andreas Rossberg wrote:
On 13 September 2011 16:48, Brendan Eich <[email protected]> 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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
