Live data from Hacker News

The V8 Myth: Why JavaScript is not a Worthy Competitor

blogs.adobe.com

81–90 of 100 posts

Re: The V8 Myth: Why JavaScript is not a Worthy Competitor

#81
While the benchmark is certainly valid, he general argument is weak and he comes to a mistaken conclusion.

The argument assumes that compiling a program is a fixed amount of work, hence a AOT compiler will always have an advantage.

This is wrong.

We can chose how much effort a compiler expends, and this choice has a complex relationship with the execution speed of our built program. Read Andreas Gal’s PhD thesis, then look through the source of LuaJIT for an example of how one can achieve peak execution speed while spending only a fraction of the time that’s typical inside the compilation machinery.

What this means is that AOT vs JIT vs Tracing is a complex topic with no simple winner. Real systems will increasingly be hybrids.

Lastly, wtf does Santa have to do with anything? If you’re making a claim, support it with a logical argument and evidence, not a lame rhetorical appeal.

Re: The V8 Myth: Why JavaScript is not a Worthy Competitor

#82
post #71
post #37

Earlier quoted context omitted.

Of course you can promise types to the JS engine. Ints in particular are easy. With modern type-inferring JITs like SpiderMonkey, an expression like "var x = 3;" will infer x to int, and there will be no type checks or unboxing. In more complex cases, you can add "|0". For example: function f(x) { x = x|0; ... } This has the effect of forcing an int interpretation for the argument, and there will be no type checks or…

> Of course you can promise types to the JS engine. Because a variable can always change types, it's actually trivially proven that in a dynamically-typed language, there will always be programs in which the type cannot be inferred.

Well, statically-typed languages have a "dynamic" type too. Consider void * in C and C++ and Object in Java and C#. You have to downcast to do anything with them. That's the equivalent of what JS is doing with its dynamic typing. The basic difference is that the "dynamic" type is the default in JS, and the static type is the default in statically-typed languages.

Re: The V8 Myth: Why JavaScript is not a Worthy Competitor

#83
post #82
post #71

Earlier quoted context omitted.

> Of course you can promise types to the JS engine. Because a variable can always change types, it's actually trivially proven that in a dynamically-typed language, there will always be programs in which the type cannot be inferred.

Well, statically-typed languages have a "dynamic" type too. Consider void * in C and C++ and Object in Java and C#. You have to downcast to do anything with them. That's the equivalent of what JS is doing with its dynamic typing. The basic difference is that the "dynamic" type is the default in JS, and the static type is the default in statically-typed languages.

The premise of this article is that Javascript's pure dynamic variables lead to slowness.

I'm not sure what your point with this post was because if you litter your C/C++ code with non-static casts, it is also going to be much slower than code without casts.

Re: The V8 Myth: Why JavaScript is not a Worthy Competitor

#84
post #60
post #21

Earlier quoted context omitted.

I work with Javascript everyday. And I hate it. It is broken as a language (var hoisting, this can mean pretty much whatever you want it to, no types, not even a good damm s32int). But it works on all platforms and so it will always beat Flash.

You might want to try out CoffeeScript with contracts: http://disnetdev.com/contracts.coffee/ Compiles to beautiful JavaScript and gives programmers the ability to check types at compile-type. If you've never used it, I'd compare CoffeeScript to an amalgam of Ruby and Python, with a little Haskell thrown in (take a look at how you specify contracts, for example). If you like functional programming, you'll love Coffee…

That one-liner is awesome! But it also has some evil type conversions in the form of + = hehe

Re: The V8 Myth: Why JavaScript is not a Worthy Competitor

#85
post #27
post #7

At best, this reeks of like 2000-era Microsoft, "Why does everybody get so excited about Javascript still? ActionScript is way better! Duh!" As far as actual points in the fine article -- a test using some sort of strongly typed data on an unreleased actionscript vm ran three times faster than v8 running similar code. I'm not shocked at all, and think Javascript could badly use at the least some type hinting, persona…

Out of interest, is there anything you can share about the particulars of your application? We did the same Flash vs. HTML5 analysis in the context of Facebook games, but in our experiments it looked like Flash still won handily in terms of performance.

It was a business intelligence app; the front end rendered graphs and charts based on data over Zend.

We staged out of that architecture by implementing a REST endpoint on top of Zend, and moved our graphing over to the (now-superceded) protovis library.

Our engineers weren't used to worrying about data transfer, so we had to do a little bit of engineering work on the JSON side once we switched out, but the graphs, charts and rendering are VASTLY faster.

That said, it could well be the Flex runtime that added all the badness; flash games definitely render faster than our app did.

Re: The V8 Myth: Why JavaScript is not a Worthy Competitor

#86
post #37

Earlier quoted context omitted.

Well, the problem (one problem) is that Javascript has no typing system. This makes running valid javascript code super, super slow at times. You can't promise to a javascript interpreter that you will always and only use the variable i_am_only_ever_an_integer as an 8 bit integer. This makes lots of things super slow.

Of course you can promise types to the JS engine. Ints in particular are easy. With modern type-inferring JITs like SpiderMonkey, an expression like "var x = 3;" will infer x to int, and there will be no type checks or unboxing. In more complex cases, you can add "|0". For example: function f(x) { x = x|0; ... } This has the effect of forcing an int interpretation for the argument, and there will be no type checks or…

Interesting. I didn't know this.

I understand that actually getting speed out of JS for binary data is still quite 'hacky' though, for instance Fabrice Bellard used Typed Arrays extensively implementing his Linux-on-Javascript project: http://bellard.org/jslinux/tech.html

Re: The V8 Myth: Why JavaScript is not a Worthy Competitor

#87
post #82

Earlier quoted context omitted.

Well, statically-typed languages have a "dynamic" type too. Consider void * in C and C++ and Object in Java and C#. You have to downcast to do anything with them. That's the equivalent of what JS is doing with its dynamic typing. The basic difference is that the "dynamic" type is the default in JS, and the static type is the default in statically-typed languages.

The premise of this article is that Javascript's pure dynamic variables lead to slowness. I'm not sure what your point with this post was because if you litter your C/C++ code with non-static casts, it is also going to be much slower than code without casts.

The parent comment was pointing out that there exist programs in JavaScript in which the types cannot be inferred. All I was saying was that this is not unique to JavaScript, or to dynamically typed languages generally.

Re: The V8 Myth: Why JavaScript is not a Worthy Competitor

#88
V8 is the catalyst, but it's only a small part of the bad news for Adobe.

There are many horses in the Javascript optimisation race. Chrome is the faraway leader, but all major browsers have delivered large improvements in Javascript performance over the past few years. Actionscript has hardly improved in five years.

http://iq12.com/blog/as3-benchmark/

Re: The V8 Myth: Why JavaScript is not a Worthy Competitor

#89

I have absolutely no idea how I would write Hello World in Flash. What compiler do I need. Do I need a compiler. Do I need to buy it? Is that all I need? Compared to: $ vim helo.html alert("hellooooo"); And if you can't write that from scratch, ViewSource on most web pages will give you a good clue. That looks like trump for mindshare, disputed performance questions aside.

You don't need to buy anything. Here is an excellent free open source AS3 (and other languages) editor/debugger (for Windows):

http://www.flashdevelop.org/

Download that and the free Flex SDK from Adobe, create a new Flex 4 project and stick this in the Application tag in the generated Main.mxml file and you are done:

    
Use an AIR Flex 4 project instead with the same label control and now your app runs on both Macs and PCs (and Linux but not as cleanly) in its own native window with full access to the native file system and the Internet without any AJAX proxy issues.

I admit its not as nice as instant browser compilation but for some class of applications Flash/Flex is very nice.

Post reply on HN