151–160 of 202 posts
Why dont they just insert regular C/C++ source code inside HTML and be done with it? Eventually the browser is just going to be a download manager that downloads executable code and runs it locally :P
Finally, I can write all my web apps in C/C++. Dream come true!
BTW, C/C++ code that is compared has multithreading and SIMD capability disabled. In the third page they benchmark asm.js and native with multithreading and SSE enabled. It shows upto 50x slowdown! Not exactly sure what the point of a benchmark without multithreading is. I mean anyone writing performance sensitive apps will use MT right? (given JS is single threaded, it seems this is a dealbreaker). http://cdn.arstec…
It seems Mozilla and Google are moving more and more toward their own browser specifications and mechanisms. Microsoft and Netscape did this in the 90s, and it ended up causing nothing but pain. Optimizing JS is interesting, but creating browser-specific applications of code meant for a web audience disturbs me. I don't want a repeat of the first browser wars. Hopefully Mozilla will work toward w3 standards in this e…
I think this is actually is a very good thing. Before the next big thing can be standardized, it should be created. Google tried to create a next big thing, by moving in several directions, among them are both Dart and PNaCl (which IMO, is the way to go, it provides good browser integration and 95% of the native code with both multithreading and other stuff). Mozilla, IMO, is more interest in keeping the status quo a…
Mozilla aren't resisting innovation. They've chosen to keep Javascript (the platform) and innovate on top of it, e.g. with pdf.js. Google is aiming to develop alternative platforms. They're both valuable activities.
Earlier quoted context omitted.
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.…
>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 p…
> 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.
Earlier quoted context omitted.
With some optimizations unrealized: it's not like everything can use SIMD or that all problems which could theoretically use SIMD actually benefit. Comparing scalar code is still useful for the vast majority of programs executed.
Furthermore, explicit SIMD code (for example, using SSE functions) is not portable. The comparison here was portable C/C++ to portable asm.js.
Second, compilers also do auto vectorization (automatically vectorizing code that is not explicitly written to use vector types / SIMD intrinsics) and in addition SSE is used even for scalar floating point operations these days. It doesn't look like asm.js even lets you operate on single precision (32 bit) floating point values which can be a performance issue in some cases.
Last, web workers are less flexible than native multithreading with shared memory between threads and atomic instructions / mutexes etc.
These and other issues mean it will not be possible to squeeze as much performance (and as a result power savings) out of asm.js as from native code or PNaCL.
Earlier quoted context omitted.
Furthermore, explicit SIMD code (for example, using SSE functions) is not portable. The comparison here was portable C/C++ to portable asm.js.
First of all clang and LLVM support the GCC vector extensions which means you can write portable SIMD code: http://clang.llvm.org/docs/LanguageExtensions.html#vectors-a... Second, compilers also do auto vectorization (automatically vectorizing code that is not explicitly written to use vector types / SIMD intrinsics) and in addition SSE is used even for scalar floating point operations these days. It doesn't look lik…
It's portable in one sense, but not another - it doesn't work in other compilers like MSVC, which was used in this article.
> Second, compilers also do auto vectorization (automatically vectorizing code that is not explicitly written to use vector types / SIMD intrinsics)
Yes, if the native compiler did auto vectorization here, it helped it. asm.js still did very well though, so I suspect auto vectorization could not be achieved.
> and in addition SSE is used even for scalar floating point operations these days.
Yes, in both native compilers and JS engines. Likely SSE was used in both sides of the comparison here.
> It doesn't look like asm.js even lets you operate on single precision (32 bit) floating point values which can be a performance issue in some cases.
True, we are investigating that. Note that you can in some cases optimize double precision operations into single precision ones, even without explicit syntax.
> These and other issues mean it will not be possible to squeeze as much performance (and as a result power savings) out of asm.js as from native code or PNaCL.
If we are talking about the current state now, then PNaCl does not support SIMD either. If we are talking about eventually, then eventually JS might gain those things too.
Earlier quoted context omitted.
The browser vendors definitely do micro-optimize these. DOM binding performance is measured in nanoseconds these days.
Then what is it?
1) Interleaving changes to style and requests for layout information: this causes lots of relayouts instead of just one.
2) Using libraries that under the hood helpfully end up doing item #1 for you.
3) Using complex graphical effects (blurred shadows are a common one, as are certain gradients) that are actually very expensive to implement and may not be amenable to being GPU-accelerated.
Earlier quoted context omitted.
> 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/
... best viewed in ... netscape ?
Earlier quoted context omitted.
They are fast, indeed. But by targeting NaCl, you are producing code that: - will only run on Chrome; - will only run on the hardware platforms for which you have developed. This kind of kills all the fun in the web. By contrast, asm.js code will run just about everywhere, today. And will get blazingly fast in ~12 weeks for Firefox (a little later for Chrome and Opera).
> - will only run on the hardware platforms for which you have developed. What fast browser JITs are actively developed for platforms other than ARM, AMD64 and IA32? V8 does not support anything else, and while Firefox enables SpiderMonkey for MIPS and SPARC [1], "unsupported" is not a very hearty endorsement. https://developer.mozilla.org/en-US/docs/SpiderMonkey/1.8.8#...
But the real issue with NaCl is this thought experiment. Assume NaCl were developed in 1998 and everyone had jumped on that bandwagon and the web in 2003 were full of NaCl blobs targeting the hardware architectures that mattered in 2000-2001. Then ask yourself the following questions:
1) Would this have affected the choice of hardware for phones and tablets and whatnot?
2) Would it be viable today to ship a web browser on an ARM system?
3) What makes us think that the currently-relevant set of hardware architectures will still be the set we want to be using in 10-15 years? In 30 years?
The nice thing about asm.js or PNaCl compared to NaCl is that even if we ship it right now and only run it right now on ARM/AMD64/IA32, if someone comes up with a new hardware architecture they want to ship in consumer devices they can simply implement a JS JIT for it (in the case of asm.js) or an LLVM backend (for PNaCl), which is something they would need to do _anyway_ for that "consumer devices" bit. On the other hand, if they have to deal with legacy NaCl content they suddenly have to do hardware emulation or something insane.