Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The V8 Myth: Why JavaScript is not a Worthy Competitor

blogs.adobe.com

Post reply on HN
Print view View original

91–100 of 100 posts

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

#91

Post by comex »

VikingCoder wrote: post #31

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 ac…

"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."

Nitpick: The only way to go faster is to use the hardware privilege separation that Chrome is always already running under, which is considered insufficient to sandbox untrusted code for historical reasons and organizational reasons (Chrome doesn't have much control over the kernels it's running under), but no technical reasons.

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

#92

Post by [deleted] »

ootachi wrote: post #39
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…

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.

[deleted]

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

#93

Post by justncase80 »

VikingCoder wrote: post #31

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 ac…

Do you have to compile different binaries for different platforms on native client? Would you need to compile x86, x64, and ARM binaries separately?

Also, I think the question is how to get performance for dynamic runtimes. Native client isn't inherently dynamic. I guess you could compile Lua into native client and build your app ontop of Lua but then you still have the issue of how to get a performant dynamic runtime.

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

#94

Post by justncase80 »

drblast wrote: post #58

"Best performance" is irrelevant if the performance of javascript is good enough. Maybe this illustrates the dichotemy between traditional engineering and computer science, but in most other forms of engineering you want just-good-enough-to-fulfill-the-requirements because any better means you are spending extra money or doing extra work uneccessarily. If javascript lets you write a game that runs at a solid 30 frame…

I'm sorry but tetris isn't exactly state of the art in game design these days. We already have tons of games that javascript/html simply cannot even come close to handling. Naturally people are starting to think about how we can get there, while maintaining all the benefits of a dynamic runtime. So the point is that what javascript is today is not good enough, thus the exploration into how to make it faster.

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

#95

Post by kaushiks »

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.

That is not true. I'm not entirely sure what you mean by "no typing system" so I'll go ahead and assume what you likely meant - no static type system.

Optimizing code written in a dynamically typed language is a pretty well understood problem (now) thanks to the SELF research at SUN and more recently the V8 Javascript engine. Both VMs employ type profiling at runtime to figure out what the compiler should assume the type of a dynamically typed variable should be. It can then emit code that treats a variable like it always has the profiled type - like a C++ compiler would. When such an assumption is broken at runtime, implementations typically fallback to an unoptimized version of the code (V8) to execute the rest of the continuation. Well written code is expected to achieve type stability pretty fast making the fallback overhead insignificant.

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

#96

Post by tomjen3 »

michaelmior wrote: post #52
tomjen3 wrote: 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.

Agreed that var hoisting can be tricky before you encounter a situation where it break something. (I suspect this happens to most JS devs at some point. Certainly has to me!) However, what's wrong with not having types? Sounds like you're just not a fan of dynamic languages since this isn't a JS-specific issue.

I am a fan of typeless languages for small project and build files. But js takes the cake because it doesn't even distinguish between ints and floats.

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

#97

Post by tomjen3 »

michaelmior wrote: post #52
tomjen3 wrote: 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.

Agreed that var hoisting can be tricky before you encounter a situation where it break something. (I suspect this happens to most JS devs at some point. Certainly has to me!) However, what's wrong with not having types? Sounds like you're just not a fan of dynamic languages since this isn't a JS-specific issue.

Also no types means no type completion and no refactoring.

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

#98

Post by jiggy2011 »

pnathan wrote: post #53
kls wrote: post #26

Earlier quoted context omitted.

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…

Project complexity tends to scale exponentially-ish, so I was wondering what you considered "Largest codebases"... according to Googling, Windows is 50M, Android 12M. So a couple million LoC is pretty awesome. Static typing evangelists seem to have a blind spot: they persistently tend to assert that you can't write good and large dynamic codebases.

You can , if you have good communication or a small team.

I have a PHP Project that is about ~200Kloc , ok that's not enormous (and it's about 60% boilerplate) and I can maintain it happily enough but I wouldn't want to let a large team loose on that.

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

#99

Post by jiggy2011 »

talmand wrote: post #77
drblast wrote: post #58

"Best performance" is irrelevant if the performance of javascript is good enough. Maybe this illustrates the dichotemy between traditional engineering and computer science, but in most other forms of engineering you want just-good-enough-to-fulfill-the-requirements because any better means you are spending extra money or doing extra work uneccessarily. If javascript lets you write a game that runs at a solid 30 frame…

Just to expand, in most cases 30fps is considered the minimum while 60fps is your target. Most people cannot see the benefit above 60fps. As browsers start using the GPU available on the device in hand then 60fps should be easily attainable; unless you're doing something crazy complicated.

I think the problem comes as soon as you need to do any floating point work within the Javascript VM , not sure what javascript FP performance is like but I guess it's not pretty.

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

#100

Post by angelbob »

gcp wrote: post #38
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.

They actually have various ways to compile Python. So that's an especially apt comparison :-)
Post reply on HN