The V8 Myth: Why JavaScript is not a Worthy Competitor • Hacker News Board

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

#31

Post by VikingCoder » Wed, Jan 18, 2012, 4:05 PM UTC

The bytecode myth: Why JavaScript and ActionScript are not Worthy Competitors

Use Native Client. You'll get as close to machine code as you'll ever get, while running in a sandbox. The only way to go faster is to fully trust the code on your machine.

Checkmate.

See, I can write the word checkmate, too. How many more times can we come up with a slightly better argument, using only one train of thought about what is actually a very complicated issue involving multiple vendors, multiple platforms, multiple standards committees, ease of use, ease of deployment, different memory, bandwidth, and cpu constraints, and then just say 'checkmate' as though everyone else is being completely ridiculous?

Several, I bet.

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

#32

Post by angelbob » Wed, Jan 18, 2012, 4:06 PM UTC

So... Adobe is arguing that nobody will ever figure out how to put a better compiler in front of JavaScript under any circumstances, so we have to pack it in now?

I realize current JIT sucks in many ways, but seriously... claiming that "we can put this compiler in front of our stuff and since the other guys can never, never figure out how to compile first, we will win forever" isn't just stupid. It seems willfully stupid.

Like, what about the second and successive times you run a given page's JavaScript, like if the page were in cache. Are they certain that open source's brain trust can never figure out how to compile that ahead of time?

Really?

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

#33

Post by vessenes » Wed, Jan 18, 2012, 4:08 PM UTC

astrodust wrote: post #25

vessenes wrote: 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…

This is what I'm having trouble believing. If ActionScript can be "compiled to death", where in this case "compiled" means "to bytecode" then presumably the same thing could happen to JavaScript. In the V8 environment it should be possible to aggressively optimize the code in question with various command line options. Where is -O5? The real problem is a lack of an open-standard for JavaScript bytecode. Being able to…

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.

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

#34

Post by lightblade » Wed, Jan 18, 2012, 4:12 PM UTC

I've been a Flash developer first before coming to JavaScript. In many ways, ActionScript just may be the superior language. A language's performance is really subjective to its implementation. So lets not argue that. But IMHO, a language's "usability" depends a large part on its community almost like a slippery slope. The larger and active the community, the more tools and libraries are available, the more popular the language get.

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

#35

Post by lightblade » Wed, Jan 18, 2012, 4:13 PM UTC

I've been a Flash developer first before coming to JavaScript. In many ways, ActionScript just may be the superior language. A language's performance is really subjective to its implementation. So lets not argue that. But IMHO, a language's "usability" depends a large part on its community almost like a slippery slope. The larger and active the community, the more tools and libraries are available, the more popular the language get.

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

#36

Post by roel_v » Wed, Jan 18, 2012, 4:14 PM UTC

kls wrote: post #26

pnathan wrote: post #15

Earlier quoted context omitted.

"building some of the largest code bases in the world with JavaScript" You have over 100 MLoc?

You are focusing on the wrong part of the conjecture, the point is, large code bases are being written in JavaScript everyday. Yet, People with the position like the author continue to argue that it can't happen, despite the evidence being readily available. I don't want to dodge your question thought, the answer is yes I have worked on some JavaScript code bases that are several MLoc. Which I would consider for conj…

For your argument to be believable, you shouldn't make unsubstantiated and prima facie bogus claims. Your post would've have the same message without that claim, but by putting it in it sticks out like a sore thumb and makes the rest of your argument moot for debating purposes.

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

#37

Post by ootachi » Wed, Jan 18, 2012, 4:19 PM UTC

vessenes wrote: post #33

astrodust wrote: post #25

Earlier quoted context omitted.

This is what I'm having trouble believing. If ActionScript can be "compiled to death", where in this case "compiled" means "to bytecode" then presumably the same thing could happen to JavaScript. In the V8 environment it should be possible to aggressively optimize the code in question with various command line options. Where is -O5? The real problem is a lack of an open-standard for JavaScript bytecode. Being able to…

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 unboxing performed thereafter.

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

#38

Post by gcp » Wed, Jan 18, 2012, 4:20 PM UTC

angelbob wrote: post #32

So... Adobe is arguing that nobody will ever figure out how to put a better compiler in front of JavaScript under any circumstances, so we have to pack it in now? I realize current JIT sucks in many ways, but seriously... claiming that "we can put this compiler in front of our stuff and since the other guys can never, never figure out how to compile first, we will win forever" isn't just stupid. It seems willfully st…

Not knowing ActionScript, the point seems to boil down to no more than "statically typed languages will always be faster than dynamic ones". This is true no matter what, "open source brain" can't fix that.

However, one could make the same argument for C++: Why Python is not a worthy competitor. Sounds silly? It is, just like the original post.

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

#39

Post by ootachi » Wed, Jan 18, 2012, 4:21 PM UTC

astrodust wrote: post #25

vessenes wrote: 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…

This is what I'm having trouble believing. If ActionScript can be "compiled to death", where in this case "compiled" means "to bytecode" then presumably the same thing could happen to JavaScript. In the V8 environment it should be possible to aggressively optimize the code in question with various command line options. Where is -O5? The real problem is a lack of an open-standard for JavaScript bytecode. Being able to…

Nonsense. JavaScript bytecode would still be dynamically typed. At best a JavaScript bytecode standard would be equivalent to a compressed AST. That still might be a useful thing to have, but it wouldn't improve runtime performance.

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

#40

Post by a_a_r_o_n » Wed, Jan 18, 2012, 4:24 PM UTC

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.