Hacker News Reader

Comment by cromwellian | Hacker News Reader

Browsers already have a wide performance differential. What's the ratio between V8 and IE6? Or between desktop and mobile? As long as the performance isn't pathologically bad, it won't matter. Dart apps will start up quicker and run a percentage faster. Maybe perform much better on mobile. A decent win, but doesn't really change the fragmentation equation much from what it already is.

The keyword Brendan used was "decent", and frankly, I'll take a stab and say performance of Dart to JS will be beyond decent.

View on HN

I specifically referred to new number types. Dart has bignums (int). See https://twitter.com/#!/maccman/status/123400799756881920 for a clue.

Dart-to-JS can't be faster than hand-coded JS if it does not use bignums. If it does use bignums that do not fit in 32-bit ints, then Dart-to-JS will be slower than a native VM with built-in bignum support.

IE6 is irrelevant. The topic is modern browser with native Dart VM vs. without.

What do you mean Dart-to-JS can't be faster than hand-code JS? That's like saying C can't be faster than hand-coded assembly. Unless you write unmaintainable code or spend efforts counting cycles and scheduling and pipeline harzards, this usually isn't the case, and is not the way most people write large application (all in asm). If you take your average hand-written Javascript and run it through closure compiler, in many cases, it ends up executing faster (at least in V8). If you haven't already, I would recommend investigating the behavior of JS VMs with and without Closure Compiler, you might be surprised.

We're talking averages here, not pathological edge cases. Java has a 64-bit long type which JS doesn't support. GWT supports longs. In theory, GWT code should run slower, in practice, because GWT contains an optimizer, it runs as well, or faster, than hand written JS, simply because very few code bases have hot paths dependent on long arithmetic. For example, I've actually ported popular JS benchmarks to Java, ran them through GWT, and the result was faster.

Sure, would you be able to concoct applications for which Dart and Dart-to-JS have a large divergence? Yes. Will they be the common case? Probably not. I can concoct normal JS applications today which show high divergence between Chrome, Firefox, and IE, because of all of the JS VMs have different weaknesses, different optimizers, different garbage collectors. If you're writing applications that are so CPU bound and performance critical (e.g. games), chances are you're going to run into other portability problems too.

Most of this worry over runtime performance I think is a red herring. The real difference will probably be in startup time.

"That's like saying C can't be faster than hand-coded assembly"

Don't change the subject. The topic is not productivity as you seem to imply here. Also, JS engines are not hard to track super-scalar CPUs. A compiler can target one JS VM (e.g., V8) but then you're locked in. All the current JS VMs have peculiar optimization faults, some worse than others, many completely disjoint across VMs. No one has a compiler targeting each to best effect.

Hand-coders can do well in general against current JS trans-compilers, but that wasn't my point.

The point is that if you actually need bignums, a JS emulation will be slower than a native Dart VM built-in bignum implementation.

"Most of this worry over runtime performance I think is a red herring."

The "worry" (such as it is, or was) was over Google's politics, not its Dart-to-JS compiler's generated code performance in isolation. Pushing a native Dart VM into Chrome, rewriting major Google apps to use Dart, then seeing if that creates market pressure for native Dart support in other browsers, was all suggested or even explicitly called out in the leaked memo. That was the "worry".

But it sounds like a native Dart VM in Chrome won't be immediately released, and the Google web apps written in JS or Closure won't be rewritten quickly. I don't know. Maybe you do -- do you work for Google?

What percentage of apps do you think bignum performance will matter? Even in cases where it might matter (cryptography), you would be better suited using GPGPU code, or adding cryptographic APIs to the browser itself rather than insisting it be done in JS. Indeed, you could always fallback to that for browsers with poor bignum performance.

GWT has supported Java's BigInteger/BigDecember, and it's never been an issue.

(For the record, since it is no secret by searching my handle, I work for Google, but I do not work on Dart. I specifically work on the GWT compiler, and do not speak for the Dart team nor represent their views, nor am I really representing anything, but my own biases here given my experience with trying to develop high performance Javascript games both in the browser and mobile)

If bignum performance doesn't matter, then Dart-to-JS code is generally no faster than other JS code. Duh!

If, as the leaked memo asserted, JS's lack of more than one number type is "unfixable", and we now see that Dart's fix is to add bignum as well as double, then bignum must matter. Else why do bignums in Dart?

This ignores the live bignum strawman on the ecmascript.org wiki, which Googlers on tc39 failed to champion.

If your argument is that bignum literal and operator syntax, not bignum performance, are what matters, I am with you -- but then why did no Google rep on tc39 work to advance the bignum strawman?

You can't have it both ways. It looks like some Google heavy hitters focused only on Dart as if it has a native VM, and not on Dart as a source language for JS, which implies certain obvious extensions to the ES standard.

And in any case I seem to recall being assured by Mozilla that we don't need no Native Client because Javascript is going to be fast enough for everything. Even pre-existing non-JS code could just be compiled to mighty JavaScript, the Assembler of The Web™ and all would be well. But now Dart is unacceptable because Dart-to-JS won't be close enough to the performance of native Dart?

I don't think any browser manufacturer would have an issue with Dart if it were only a Dart-to-JS compiler. Nobody had issues with GWT or CoffeeScript, after all.

Go back to the other thread and re-read the argument there (or go back to school and learn how to argue). No one said Dart-to-JS by itself was bad for anything.

The leaked memo spoke of a native Dart VM in Chrome and Chrome-first Dart as primary source web app authoring by Google. The clear intent was to pressure other browsers to adopt the native VM.

Google can act like Microsoft (but with less market share) if it so chooses. Just spare us the open-washing hypocrisy, and don't expect productive multi-vendor standardization. Instead, expect a new browser cold war -- no one wins.

You appear to have misunderstood.

On one occasion Mozilla has argued that the speed difference between a) non-JS code running natively and b) the same code rewritten in, or even compiled to, JS is (or soon will be) too small to be important. Now on this occasion Mozilla is arguing that the speed difference between a) native-VM Dart and b) Dart-to-JS is (and will remain) large enough to be important. I pointed out that these two claims are hard to reconcile. About the only way they can both be mostly-true is if the performance gap only happens to be large and important enough on exactly those occasions when that gap happens to bite Mozilla in its platform strategy. Not very likely, unless one assumes that the performance needs of the poor sods who just want to use the web (as publishers or consumers) are never all that important.

So the fact that Mozilla's problems with the relatively poor performance of Dart-to-JS would be solved if native-VM Dart went away has little relevance, because most other people's problems with the speed of JS are not helped by making there be no alternative to JS.

> or go back to school and learn how to argue

http://www.youtube.com/watch?v=SKm5xQyD2vE

so let me get this right: you are arguing that a problem with Dart is that other browser makers won't get on board, and you happen to be CTO of one of those browser makers?

That seems a rather circular reason for dismissing it.

No browser vendor will give a free lunch to a competitor, at high opportunity cost, by locking themselves into a brand-new and 2nd scripting engine. No one. Steve Jobs' ghost will haunt anyone who tries.

It doesn't matter how "good" Dart is.

re: brand new: fine, wait until it isn't brand new

re: lock in: I'd think Mozilla isn't really locked in as long as there is a cross-compiler. If you decide the the code bloat isn't worth the speed improvement (for the sites that run dart code), yank the VM and no harm done

re: opportunity cost: well the code from Google can be dropped in, unless you really feel the need to rewrite your own version.

re: "free lunch to a competitor": it sounds like if there is is potential for another "browser war", it's coming from that sort of attitude. In fact, that sounds counter to the whole concept of open source.

re: "It doesn't matter how good Dart is.": well, that's a shame. I'd like to think merit counted for something.

Overall, maybe I don't know your world and the politics etc, but it just sounds like a lot of "not invented here" syndrome to me. And I say this as someone who genuinely admires your work and really likes Javascript (and am especially pleased that Dart looks enough like Javascript to be comfortable to me).

You seem new to software. Every addition costs. The 2nd scripting engine in particular. Mozilla went through this to no avail with CPython several years ago. I paid Mark Hammond to do the integration work. It was a constant source of bugs and overhead, and without CPython distribution on Windows, and sane versioning on Mac and Linux, no one used the non-JS code paths save ActiveState in Komodo.

WebKit is supporting Python bindings but that language is 3rd after Objective-C and Apple pays the big Obj-C costs.

My comment about Dart's merits was purely a businessman's evaluation, not NIH. Before you throw that accusation my way, consider Mozilla using Google WebM code, and lately implementing SPDY.

You expect other competing browsers to give Google a strategic free lunch, and to give up their share of influence in standards bodies? No way, not from us, or from Apple or Microsoft or Opera.

But it turns out Dart does not have obvious merit, such that I am moved to implement it (see SPDY for a counter-example). Dart is jejune, knee-jerk, and conservative in its design, from what I have now seen.

I've played with it today and the joy I admittedly feel was quite similar to what I felt when coding LISP. However, I only coded LISP in academia and would not feel comfortable at all using it in a live environment.

For now, I see DART as a proof of concept kind of thing and it definitely should /not/ gain widespread support any time soon. No matter how much money Google will throw at it.

I have no doubt that there would be a cost associated with hooking in Google's code. And I'll take you at your word that it's not NIH, even though a casual reader might guess that you might be a bit more personally invested in Javascript than you'd be in the various things that, say, WebM seeks to replace.

Regardless, I'll leave your words to speak for themselves without further debating. I'll admit I'm a tad disappointed at the level of defensiveness and name calling (of both your competition and of those you debate with), though.

You had better put up or shut up. I did not call anyone names. Cite my words if you can.

As for defensiveness, that looks like your department.

Well, uh, I guess if you put it that way, I sure better....

Whether you want to debate whether the term "name calling" is accurate or not, I would suggest that the following fall astray of Hacker New's guidelines of "the principle here is not to say anything you wouldn't say face to face". Then again, I don't know.....maybe you are that way in person too.

"Grow up!"

"Such ignorance. Willful? You seem new around here, and you are not using your real name"

"How old are you, to never learn or else to forget this?"

"So your trollish commentary notwithstanding"

"I despair of your reading comprehension"

"Am I promising you a pony? No, but then you are not a three-year old."

"(or go back to school and learn how to argue)"

"Dart is jejune, knee-jerk, "

and of course:

"You had better put up or shut up"

Really? It seems you're quite a prominent figure to need to resort to that sort of schoolyard talk, but do as you wish. I'm not going to be baited anymore.

Thanks for javascript, though.

Name-calling means calling a person a name. If I say "Joe is an idiot", I have called Joe a name.

If, on the other hand, I call someone's behavior or rhetoric out, then that person has room to back up. We all make mistakes -- definitely me included.

Your previous comment accused me of NIH without evidence. I talk back to that kind of crap. I'm not baiting you. Let us take each other at our word.

For what its worth, I felt really awkward reading many of your replies in this thread. You are our spokesperson for JavaScript and the CTO of Mozilla. It would be nice if you could talk to people without making disparaging and downright condescending remarks.

I look up to you to speak for the community and to use judgement and character. Anyways, maybe I'm just being too sensitive, but I figured I'd say something.

I take your comment to heart. Sometimes I bite back too hard.

To all those here to whom I've made "grow up!" and similar remarks, my sincere apologies.

Much appreciated. =)

Reply on news.ycombinator.com