http://cdn.arstechnica.net/wp-content/uploads/2013/05/classi...
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.
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?
> 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.
>The innovation in browsers and webapps is coming from the vendors
Yes, which does not contradict what I said at all: "the people defining the standard (who also happen to be big players in many other related markets)". The vendors are big industry players who have their own agendas that rarely coincide with my interests (yes even Mozilla). They also get to veto any proposal they don't like.
The Kinect has been available for years now, which is an age in the consumer tech space. Where is the open standard web API? Do you see how it might be difficult to get Mozilla, Google and Apple to agree to standardise, implement and support an API for proprietary Microsoft technology? Creating a specific API for every type of device (photo cameras, video cameras, accelerometer, touch screens etc) and not providing a low level interface to hardware is the wrong route to take. High level APIs are fine, but it is important to also provide the ability for people to extend platform support in new and unforeseeable ways, and that requires lower level access.
WebRTC is another excellent example of conflicts of interest with Microsoft opposed to it because it challenges Skype (or because it is technically deficient, depending upon which side you are on). The difference between the web as a platform and real open operating systems is stark. If Windows had been like the web -- locked down with only a limited set of approved APIs -- then Skype could not have been created unless Microsoft decided to allow it. Substitute Microsoft for Apple/Google/Mozilla/Microsoft and you have the situation we have with the web.
Perhaps some people don't see the this because of the tribal nature of technology discussions. People don't see the web as being restrictive because their 'team' (be that Apple or Google or Microsoft or Mozilla) has a say in it. So most arguments devolve into discussion about how X is blocking a proposal by Y and the proposal is either good for the web or bad for the web depending on whether you favour X or Y. Few people seem to stop and wonder why we are creating a system where X can veto technologies, even for people who don't use a single product created by X.
>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.
How does developing against asm.js and WebGL help me interface with new input devices? It doesn't help me one bit. All it does is let me create a faster shinier version of current webapps (that only runs in certain browsers). This is a reoccurring argument though: the web will be a decent platform once we finally get $NEW_API_PROPOSAL that fill fix everything 'once and for all'.
http://kripken.github.io/mloc_emscripten_talk/#/28
asm.js code makes it easier to get within reach of native performance.
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/
[EDIT: it looks like I may have misinterpreted the article; see replies]
To clarify, I believe they ran the benchmarks with SSE disabled. SSE is more than just SIMD; these days SSE is used for most (all?) floating-point calculations, even non-SIMD. If you disable SSE, you force floating-point ops to use the old x87 FPU, which has been discouraged by the CPU manufacturers for over 10 years.
In other words, disabling SSE is significantly crippling all floating-point performance.
http://www.realworldtech.com/physx87/4/
http://stackoverflow.com/questions/3206101/extended-80-bit-d...
(nothing against asm.js, which I think is very cool)
What was disabled was C/C++ code that explicitly used SIMD intrinsics or explicitly used SSE function calls in C/C++.
> In general, I took the highest-ranked pure C++ routines for each test. Versions that used, for example, SSE functions were excluded, as were those with explicit multithreading.
For "functions" I interpreted "functionality," but I think now it must mean SSE intrinsics?
Sorry for the confusion.
That assumes the performance sensitive app is amenable to multithreading. Many aren't.
I should know, that's my dayjob :)
I had a look at your profile and it looks like you're doing some very valuable work. I was rather hoping for some examples which didn't involve JavaScript, though.
The term of art is "inherently sequential" problems (vs "embarrassingly parallel").
In addition, the programming effort gets untenable quickly due to Amdahl's law when the amount of parallelism increases. Eg. if you have 100 cores, even if only 1% of work in your program is sequential, your performance goes down the drain. Currently we're in the comfy phase of the curve with few cores...
We've been making good progress with parallel-minded reimaginings of programming languages and computer architectures on one front: GPUs. On the CPU we are saddled with the inertia and backwards compatibiltiy lock-in of tools and culture (witness lasting use of C++ as a tool to write parallel software)
Related: Why does it seem like web workers don't exist? I can hardly think of any popular libraries or web apps that make use of them, despite the seemingly obvious utility.
All modern web browsers (I'll try not to troll about IE) support web workers. However, the semantics of web workers is message-passing (by copy, most of the time), which is the semantics generally associated to multi-process rather than multi-threading. Most developers using threads expect some kind of memory sharing, which is impossible with web workers at the moment.
Shared workers (not implemented in any browser atm, I believe) will take care of some usage scenarios. Other alternatives are being explored (e.g. [Parallel JS](http://smallcultfollowing.com/babysteps/blog/2012/01/09/para...). However, for the time being, don't expect any support from JS to do shared memory concurrency.
Note: I'm a Firefox dev.
Of course this was in the early days, and it'd be good to retest it to see if it's better now.
I think that there are a lot of interesting use cases for WebWorkers, but you also have to be aware that for some things they will actually slow down your application.
Eg. check out the ParallelArray() from the River Trail project by Intel: http://wiki.ecmascript.org/doku.php?id=strawman:data_paralle... & http://en.m.wikipedia.org/wiki/River_Trail_(JavaScript_engin... At least Firefox has an initial implementation: https://developer.mozilla.org/en-US/docs/JavaScript/Referenc...
The benefit if asm.js being based on ordinary javascript is that they can use these improvements to javascript itself right away more or less.
No, multithreading not that simple - usually it's the last trick you should try to pull and even then only if the stars align just right.
You need to have expert programmers on hand (of the rare breed who can pull this off), the good luck to succeed and the time budget to spend on the big code reachitecting and experimentation.
If you're running on something else than modern consoles, you don't know how many cores your users will have, the average might be 2 so your average returns on the effort will suck (vs spending equivalent effort elsewhere).
Witness modern Web browsers, for example, where Google, Mozilla, Apple and Microsoft employ some of the best C++ programmers in the world, routinely of pulling off heroic feats, and they haven't seen it worth the effort yet despite Core 2 and Athlon X2 hitting mainstream desktop at about 2005-2006, 8 years ago.
I'm betting the minority is less than 0.5%. Half way decent C++ programmers aren't many % of programmers, and people who can make a reliably working parallelized do-over for a nontrivial code base are maybe 1% of that. I'll say 0.05% max.
Your estimate only 0.05% of programmers could write reliable multithreaded code is extremely pessimistic, cynical even. I almost feel flattered, having written a fair amount of multithreaded code that works perfectly myself, but I most definitely would dare count me with the 0.05% top programmers or whatever. My estimate is that with proper preparation, at least 50% of all programmers could learn to write reliable multithreaded code, and the remaining 50% probably wouldn't have a use for it anyway.