4 ms·

Of course single-threaded code will lose to SIMD or threaded code. That's not saying anything surprising. The important thing is to realize that until just rec

by azakai 13y ago

Of course single-threaded code will lose to SIMD or threaded code. That's not saying anything surprising. The important thing is to realize that until just recently - a few months or so - people did not believe that SINGLE-threaded JS code on the web could be close to native speed. The Ars article here even has "surprise" in the title when it concludes that in fact that is possible :) So that is a crucial milestone. Is the job done? No, as you say, SIMD and threads are important. But we had to first get single-threaded performance to the right area. Next, browser vendors need to work together to standardize stuff that will allow SIMD and more threading. This is definitely possible if everyone is interested in making the web faster, which I certainly believe is the case.

npalli 13y ago
Ok thanks. I guess I'm confused about the gains with asm.js. Looks like it is in the same ballpark performance wise as regular JS (and slower in some cases). So, why would anyone write in a crippled C-like subset of javascript and get normal javascript like performance. In the future if threading and SIMD is standardized, won't regular JS gain performance as well?
- azakai 13y ago
  No, look again at the numbers - asm.js gets much closer to native speed than normal JS, in many cases, especially large apps. In addition to the numbers in the article, you can see for example, http://kripken.github.io/mloc_emscripten_talk/#/28 http://kripken.github.io/mloc_emscripten_talk/#/28 asm.js code makes it easier to get within reach of native performance.
- bad_user 13y ago
  > why would anyone write in a crippled C-like subset of javascript Because asm.js is not meant for people, but for compilers. For example the Unreal Engine has been recently compiled from C/C++ to asm.js and is running in the browser: http://www.unrealengine.com/html5/ http://www.unrealengine.com/html5/
  - camus 13y ago
    ... best viewed in ... netscape ?
    - cristiantincu 13y ago
      “Best viewed in Netscape” still wins over “Download for Windows (x86)”.
- riffraff 13y ago
  you are not expected to write asm.js, it's to be considered a compiler target (for e.g. emscripten etc)
anon1385 13y ago
>The important thing is to realize that until just recently - a few months or so - people did not believe that SINGLE-threaded JS code on the web could be close to native speed. Single threaded Javascript was already 'fast enough' for the CRUD interfaces that makes up most web apps. Web apps are horrible to use because the network is unreliable for many people, latency is terrible for just about everybody, browsers provide a very poor and limited set of APIs for many of the tasks people actually want to do (interacting with hardware, file systems, audio, inter-app interoperability etc) and apps are forced to run inside a sandbox that can't be escaped. Cloud services nearly always mean that users lose control of their data. Web apps are rarely open source (and if they are you still can't change the version of the app that you actually use because it runs on a server you don't control). A faster Facebook with 3D effects is still a terrible platform. Homer Simpson: Kids: there's three ways to do things; the right way, the wrong way and the Max Power way! Bart: Isn't that the wrong way? Homer Simpson: Yeah, but faster! I think a lot of this obsession over Javascript speed is a distraction (support for more languages is nice for developers of course). Making slightly faster VMs is just an engineering problem: throw more resources at it and things will improve. The hard problems are political and also related to the basic network infrastructure (constrained by the laws of physics). Trying to recreate the entire operating system inside the browser, for all possible uses (even performance sensitive things), is a huge overreach when we don't seem to have a clue how to make the basic web app experience good. Why is it hard? Because the founding idea of a single sandboxed standard for all platforms is unworkable in the real world. Not only does it mean all developers surrendering complete control to the people defining the standard (who also happen to be big players in many other related markets), it relies on the big players actually agreeing, which is often not in their interest. If the world had moved to Gopher based OSs in the early 90s the web as we know it would not have come into existence. What future possible technologies are we destroying by locking ourselves into the web sandbox?
- hughw 13y ago
  Your premise is demonstrably wrong > Why is it hard? Because the founding idea of a single sandboxed standard for all platforms is unworkable in the real world. Not only does it mean all developers surrendering complete control to the people defining the standard (who also happen to be big players in many other related markets), it relies on the big players actually agreeing, which is often not in their interest. The innovation in browsers and webapps is coming from the vendors each acting individually, and puling standards bodies along with them. If you as a developer, are waiting around for them all to agree on any technology, before leveraging it, then you are just paralyzed. Develop against WebGL and asm.js now to get early mover advantages. If you wait for universal uptake, you'll never get anything done.

by azakai 13y ago

npalli 13y ago

Ok thanks. I guess I'm confused about the gains with asm.js. Looks like it is in the same ballpark performance wise as regular JS (and slower in some cases). So, why would anyone write in a crippled C-like subset of javascript and get normal javascript like performance. In the future if threading and SIMD is standardized, won't regular JS gain performance as well?

azakai 13y ago
No, look again at the numbers - asm.js gets much closer to native speed than normal JS, in many cases, especially large apps. In addition to the numbers in the article, you can see for example, http://kripken.github.io/mloc_emscripten_talk/#/28 http://kripken.github.io/mloc_emscripten_talk/#/28 asm.js code makes it easier to get within reach of native performance.
bad_user 13y ago
> why would anyone write in a crippled C-like subset of javascript Because asm.js is not meant for people, but for compilers. For example the Unreal Engine has been recently compiled from C/C++ to asm.js and is running in the browser: http://www.unrealengine.com/html5/ http://www.unrealengine.com/html5/
- camus 13y ago
  ... best viewed in ... netscape ?
  - cristiantincu 13y ago
    “Best viewed in Netscape” still wins over “Download for Windows (x86)”.
riffraff 13y ago
you are not expected to write asm.js, it's to be considered a compiler target (for e.g. emscripten etc)

anon1385 13y ago

>The important thing is to realize that until just recently - a few months or so - people did not believe that SINGLE-threaded JS code on the web could be close to native speed. Single threaded Javascript was already 'fast enough' for the CRUD interfaces that makes up most web apps. Web apps are horrible to use because the network is unreliable for many people, latency is terrible for just about everybody, browsers provide a very poor and limited set of APIs for many of the tasks people actually want to do (interacting with hardware, file systems, audio, inter-app interoperability etc) and apps are forced to run inside a sandbox that can't be escaped. Cloud services nearly always mean that users lose control of their data. Web apps are rarely open source (and if they are you still can't change the version of the app that you actually use because it runs on a server you don't control). A faster Facebook with 3D effects is still a terrible platform. Homer Simpson: Kids: there's three ways to do things; the right way, the wrong way and the Max Power way! Bart: Isn't that the wrong way? Homer Simpson: Yeah, but faster! I think a lot of this obsession over Javascript speed is a distraction (support for more languages is nice for developers of course). Making slightly faster VMs is just an engineering problem: throw more resources at it and things will improve. The hard problems are political and also related to the basic network infrastructure (constrained by the laws of physics). Trying to recreate the entire operating system inside the browser, for all possible uses (even performance sensitive things), is a huge overreach when we don't seem to have a clue how to make the basic web app experience good. Why is it hard? Because the founding idea of a single sandboxed standard for all platforms is unworkable in the real world. Not only does it mean all developers surrendering complete control to the people defining the standard (who also happen to be big players in many other related markets), it relies on the big players actually agreeing, which is often not in their interest. If the world had moved to Gopher based OSs in the early 90s the web as we know it would not have come into existence. What future possible technologies are we destroying by locking ourselves into the web sandbox?

hughw 13y ago
Your premise is demonstrably wrong > Why is it hard? Because the founding idea of a single sandboxed standard for all platforms is unworkable in the real world. Not only does it mean all developers surrendering complete control to the people defining the standard (who also happen to be big players in many other related markets), it relies on the big players actually agreeing, which is often not in their interest. The innovation in browsers and webapps is coming from the vendors each acting individually, and puling standards bodies along with them. If you as a developer, are waiting around for them all to agree on any technology, before leveraging it, then you are just paralyzed. Develop against WebGL and asm.js now to get early mover advantages. If you wait for universal uptake, you'll never get anything done.