3 ms·

"I truly thought" you would not raise a question to which V8/Dart people already know the answer. Range prop is not the only solution. Use JIT techniques to sp

"I truly thought" you would not raise a question to which V8/Dart people already know the answer. Range prop is not the only solution. Use JIT techniques to speculate profitably that most ints fit in JS doubles. This can be done in JS-hosted VMs, just as in machine-code-generating native VMs. Again, this is extremely old hat to the Dart/V8 folks. See, e.g. http://mraleph.tumblr.com/post/24351748336/explaining-js-vm-in-js http://mraleph.tumblr.com/post/24351748336/explaining-js-vm-... In SpiderMonkey, we augment JIT techniques with online type inference that distinguishes int from double. The same type inference could add bignum to the speculative tower. See http://rfrn.org/~shu/drafts/ti.pdf‎ http://rfrn.org/~shu/drafts/ti.pdf‎ This avoids most of those checks that you assume are too expensive (and by assuming, so casually fork Dart semantics). Here is a JS version of [Hackett&Shu, PLDI 2012], from @pcwalton: https://github.com/pcwalton/doctorjsmm/ https://github.com/pcwalton/doctorjsmm/ Can the full JIT+TI approach to bignum/double/int perform well enough for dart2js? Better find out, because forking semantics is just the wrong thing. Another road not taken: we hear "can't wait for JS to get better", but Dart started at least by 2010, possibly earlier. http://wiki.ecmascript.org/doku.php?id=strawman:bignums http://wiki.ecmascript.org/doku.php?id=strawman:bignums could have been proposed and actually worked into ES6 by now, but the Dart team was in stealth mode (Dash) for too long. Still, better late than never. There's time for ES7. Who from Google will actually do the work in V8 and with Ecma TC39? /be

spankalee 13y ago
This is sounding less and less like just plugging GWTs BigInteger implementation into Dart, which is exactly my point when I said you must know the difference.
- kevingadd 13y ago
  Using a GWT BigInteger for all dart2js integers would work just fine and provide correct semantics, but if it doesn't meet their performance bar, that's a failure of design - not an excuse for cutting corners and shipping a dart2js that produces wrong behavior. This could have been accounted for with a better language design, but it wasn't.
  - BrendanEich 13y ago
    Could have been accounted for in language design, dart2js effort, bignums-for-JS effort, or some combination of the last two. I don't want to assume a conclusion, but the lack of a fix for http://code.google.com/p/dart/issues/detail?id=1533 http://code.google.com/p/dart/issues/detail?id=1533 is a problem, even if there's no immediate fix. It is fixable. /be
- BrendanEich 13y ago
  No, you changed the argument from correctness to performance. Makes me wonder if the problem is not entitled sloth with a dash of anti-JS animus, rather: wholesale, '90s-Microsoft-style-lock-in, submarine-the-other-browsers dirty pool. Of course, if dart2js produced too-slow-JS, that might limit Dart adoption. Not a dilemma, given a good-faith effort to optimize per my comment above -- and much better than forking the language between DartVM and dart2js, leaving a trap for the unwary Dart programmer to fall into when using dart2js to run on all the non-DartVM browsers. "Make it correct, then make it fast." Is this no longer done where you work? (Which would be Google, amirite? :-P) /be

spankalee 13y ago

This is sounding less and less like just plugging GWTs BigInteger implementation into Dart, which is exactly my point when I said you must know the difference.

kevingadd 13y ago
Using a GWT BigInteger for all dart2js integers would work just fine and provide correct semantics, but if it doesn't meet their performance bar, that's a failure of design - not an excuse for cutting corners and shipping a dart2js that produces wrong behavior. This could have been accounted for with a better language design, but it wasn't.
- BrendanEich 13y ago
  Could have been accounted for in language design, dart2js effort, bignums-for-JS effort, or some combination of the last two. I don't want to assume a conclusion, but the lack of a fix for http://code.google.com/p/dart/issues/detail?id=1533 http://code.google.com/p/dart/issues/detail?id=1533 is a problem, even if there's no immediate fix. It is fixable. /be
BrendanEich 13y ago
No, you changed the argument from correctness to performance. Makes me wonder if the problem is not entitled sloth with a dash of anti-JS animus, rather: wholesale, '90s-Microsoft-style-lock-in, submarine-the-other-browsers dirty pool. Of course, if dart2js produced too-slow-JS, that might limit Dart adoption. Not a dilemma, given a good-faith effort to optimize per my comment above -- and much better than forking the language between DartVM and dart2js, leaving a trap for the unwary Dart programmer to fall into when using dart2js to run on all the non-DartVM browsers. "Make it correct, then make it fast." Is this no longer done where you work? (Which would be Google, amirite? :-P) /be