10 ms·
Gap between asm.js and native gets narrower with float32 optimizations
- gizmo 13y agoThe article doesn't have much depth, unfortunately. I like asm.js but I'm still hoping for Dart support in Firefox and other modern browsers.
- Torn 13y agoIt also tells us nothing really new about asm.js, which has historically been quite popular on HN
- azakai 13y agoThe new thing is that performance has improved, from 2x slower than native to 1.5x slower than native, and that a big chunk of that is due to float32 optimizations.
- eonil 13y agoAFAIK, Dart can run on bare JS without any extra support.
- gizmo 13y agoJavascript is Turing complete so of course you can compile anything down to JS. But for performance and convenient debugging native support would be a big help.
- kevingadd 13y agoDart2js does not currently implement the whole language. Integer/float semantics and support for large integers don't work (it seems like they didn't implement them manually, so it just falls back to doubles?), and there are probably other things I don't know about missing. I should point out that emscripten and many other JS-targeting compilers (like JSIL) emulate int64 semantics directly so that apps using them do work. It's kind of strange for the Dart team to have not gotten this right yet when Dart is at 1.0.
- WoodenChair 13y agoIs this is in the issues tracker at dartlang.org?
- pcwalton 13y ago> Integer/float semantics and support for large integers don't work (it seems like they didn't implement them manually, so it just falls back to doubles?), and there are probably other things I don't know about missing. That's going to be really unfortunate if pages start relying on the proper behavior and become Chrome-only as a result...
- kevingadd 13y agoThe comments on it in the dartlang issue tracker indicate that it has already been a problem; one commenter indicates that his contribution to a crypto library was rejected because he had only tested it against Dart and it didn't work correctly in Dart2js (due to 64-bit ints)
- floitsch 13y agoThat's not really the problem. Web developers have learned from the past and don't just build web-pages for one browser only. On the contrary... Developers now sometimes need to support outdated browsers with little market share (IE8 for example), instead of actively pushing the users to upgrade. The discrepancy between Dart and JS numbers is mostly an issue for the developers. When they deal with numbers in specific ranges, they need to run dart2js more frequently (to test if their code works) instead of relying on Dartium (and its F5 development cycle). After 2 years of Dart development, numbers have rarely been an issue in practice. Developers know when they deal with numbers > 32/53bits and work around it.
- belluchan 13y agoIt's zdnet. It leans toward accessibility for lay people while sacrificing details engineers might be interested in.
- azakai 13y agoLooks like the link was updated to the original source.
- AndrewDucker 13y agoThe original blog post is well worth reading: https://hacks.mozilla.org/2013/12/gap-between-asm-js-and-native-performance-gets-even-narrower-with-float32-optimizations/ https://hacks.mozilla.org/2013/12/gap-between-asm-js-and-nat...
- Herald_MJ 13y agoAre we calling asm.js a "spin-off" now?
- azakai 13y agoYes, "spin-off" is not a good description. But I guess the article wanted to make things less technical in the title.
- clavalle 13y ago*for very specific types of applications.
- daigoba66 13y agoI wouldn't say asm.js is a spin-off. In fact it's a strict subset of JavaScript, though designed to be used as a compiler target rather than directly coded. The web browser can then execute the code in a highly optimized (hopefully, eventually near native performance) fashion. Brendan Eich talks a lot about this in a recent presentation: http://www.infoq.com/presentations/web-evolution-trends http://www.infoq.com/presentations/web-evolution-trends
- johnbm 13y agoHow is it a strict subset when they already added Math.imul and now Math.fround?
- arturadib 13y agoOh look another JS vs native benchmark... I still think we're missing the point; we're focusing on the wrong benchmarks. We're putting too much emphasis on JS speed, when in reality most web apps are behind native because of lack of (perceived) graphics performance. The shortcut out of this requires a greater variety of GPU-accelerated CSS transitions/DOM changes, as well as easier computations and DOM manipulations off the main thread, which cause horribly noticeable UI hiccups. Web Workers are still too primitive (e.g. no DOM access whatsoever) and slow (e.g. no shared memory). Not saying it's unimportant to improve JS's CPU performance; just saying that we're focusing too much on the wrong battle in the war against native.
- belluchan 13y agoWeb workers will never have DOM access. They run in a separate process with a separate URL. That's not an issue. You use postMessage to communicate with the workers.
- goldenkey 13y agoI'm pretty sure OP knows about postMessage. That wasn't his point. The only way to pass data is through message passing - but the message passing takes only strings. Just object serialization and deserialization in JS is slow enough to make it infeasable to do large-scale transfer between the two without paying for transmuting the data. We need immutable object passing for performance. Or locked mutable object passing (like Rust.) And why not the ability to modify DOM elements with the repaints happening on the main thread?
- cpprototypes 13y agoSome thoughts/questions about asm.js 1) I understand the C/C++ -> LLVM -> Emscripten -> asm.js process. But I heard they're also working on supporting GC languages (like Java and Go). How would this work exactly? Wouldn't they first have to port the entire JVM or Go runtime into asm.js? And every time a Java/Go -> asm.js program is downloaded, it would basically also download the entire JVM/Go runtime as well? 2) Would it be possible to use GUI frameworks (like Qt for C++ and maybe Swing for Java in the future) to build GUIs and directly output to canvas?
- camus2 13y agoQt running in the browser : http://badassjs.com/post/43158184752/qt-gui-toolkit-ported-to-javascript-via-emscripten http://badassjs.com/post/43158184752/qt-gui-toolkit-ported-t... JVM running in the browser : http://plasma-umass.github.io/doppio/about.html http://plasma-umass.github.io/doppio/about.html Anything is possible in the browser.
- ilaksh 13y agoThrowing away all of the advantages of dynamic scripting is not the answer. We just need better webgl support in browsers.
- lmm 13y agoWhat advantages would those be? Do they still apply when compared to a modern strongly-typed language with type inference and typeclass-like functionality, like Scala?
- millstone 13y agoThe big advantage of dynamic typing is that your code only needs to be correct on the code paths that are actually taken. That's important for the web, which is full of browser specific hacks, polyfills, feature detection, etc. Consider the difficulty of doing static type checking for a property like window.localStorage. Its type depends on the runtime environment, and may not exist at all. So static type checking against one browser environment doesn't give you much assurance that your code will type check in other browsers. You really do need to do type checking at runtime.
- EpicEng 13y agoYeah that's what polymorphism is for. window.localStorage would just be the interface, the underlying concrete type is irrelevant.
- millstone 13y agowindow.localStorage doesn't exist in (for example) IE 7, and it may or may not exist in IE8 depending on the domain. So you can't rely on the interface being the same.
- EpicEng 13y agoPlenty of libraries written in statically typed languages add features which may not be supported on legacy platforms. There are ways to deal with this. In version X you provide a way to let the client know that function Y is not supported on the current platform. It's not like the web is some completely different animal, it's just an example of poor/little standardization and a design which has not evolved well over time.
- deleted 13y ago[deleted]
- deleted 13y ago[deleted]
- zurn 13y agoThe reason this improves performance is documented at https://blog.mozilla.org/javascript/2013/11/07/efficient-float32-arithmetic-in-javascript/ https://blog.mozilla.org/javascript/2013/11/07/efficient-flo... - float32 typed arrays and more efficient emulation of C++ float32 arithmetic seem to be the main things.
- alok-g 13y agoCould someone please explain me where mankind is going currently in software development: Here is my current understanding (approximated heavily to allow seeing the big picture) and presented in non-linear chronological order: == Note: I am genuinely trying to construct the big picture. Please help me understand and not offer just plain criticism that does not teach me. == 1. There were multiple processors and operating systems. Programming languages like C created with the idea of writing programs once and just compiling for different platforms. But alas, systems were still too different to handle with a common code base. Many languages like C++ came along, but do not provide cross-platform libraries for many things like GUI development. Third parties libraries did, but native UI/UX not achieved still? 2. Java created with the idea of writing programs once (and even compiling to the byte code once) and running everywhere, thus solving compatibility issues C and C++ had across platforms. But alas, writing once and running everywhere were still too different in a common code base (Is this true?), especially with mobile devices coming along that bring different UI/UX requirements. Also native UI/UX was not achievable (Is this true?). In the meanwhile: A. Installation of software on the local machine (aka caching it locally) and constantly updating it was a pain. Automatic updates popularly used but unpatched machines still exist. B. Browsers came along with static pages, then gradually added more and more interactivity. C. Machines and networks became fast enough to install the software live from a website when a user visits and remove it when the browser cache is cleared. So now: 3. Applications start getting developed in Javascript (and other technologies) inside a browser. Native UI/UX still performs better on mobile (and on desktops too in my experience). Browsers still struggle somewhat with standardization. 4. The legacy code from #1 above is now being connected to #3 above allowing even operating systems and VMs to run inside the browser. So now we may have C++ code (originally designed to compile natively) now converted to Javascript running inside a browser, that interprets/JIT's that Javascript to run natively on the machine/OS, where the browser itself is written in C++ or so, runs as a visible or hidden layer on the top of the OS or VM, which by itself is written on C++ or so, and finally runs on the processor on which the original C++ code was designed to run on. While I certainly appreciate the flexibility of flows this offers, I am still trying to make sense of all this from the progress made by mankind as a whole. What is the ultimate problem that we are trying to solve? Compatibility between platforms and uniformity of experience across them? Improvements made to the software development processes (better languages)? Loading programs securely into the local machine (caching) instead of installing? No matter which direction I think, it seems to me that if mankind were to think these through, and were not to have the purely historical elements in the picture, the problems we have should "technically" have been solvable more easily than the path mankind has taken. Again, I am seeking help and inputs to understand this better, not underestimating the value of efforts made by people around the world, or criticize any such effort including asm.js.
- jorgecastillo 13y agoIf you disagree with the following opinion please don't down vote me instead enlighten me. Frankly I don't see the point of compiling C/C++ to JavaScript. If you'r using C/C++ you might as well compile to machine code, it's not like you gain anything by compiling to JavaScript.
- tomdale 13y agoYou get the security model of the browser; you can run code at native speed without worrying about it accessing your private data.
- jamesjporter 13y agoWhat tom said; also typing a url in a browser is a lot easier than installing something. This might sound silly but for the typical computer user (and even many nerds!) it makes a big difference.
- zimbatm 13y agoYou don't have to rewrite it.
- alan_cx 13y agoFriendly tip: Ask a question rather than state a potentially incorrect opinion which sounds like you think you know what you are talking about, but suggests that you don't. With my limited knowledge, you point initially makes sense to me. But clearly you and I don't know enough. Yes, it does on the face of it seem odd to compile C to JS. In fact, it seems positively mental. But then now I have read the replies, I can now see why. Trick is to acknowledge one's knowledge limits.