21–30 of 88 posts
So, will they add Opus support for audio tag too?
Speaking of which, wasn't Microsoft supposed to add WebRTC/ORTC support in its new browser, too? I don't think I've heard anything about it in the recent official announcements other than last year's rumors.
Earlier quoted context omitted.
Why? Last I heard, Chrome is going long on their JIT and trying to get it to automatically squeeze the same performance out of asm.js code as the others, without special shortcuts. These "real" optimizations can then seamlessly be applied outside of asm.js code. Isn't that something that benefits us all? I'm happy they're trying, at least.
While you are correct that the actual runtime speed in theory should be able to be achieved with the JIT, there are other advantages to officially supporting asm.js. One of the main things is ahead-of-time (AOT) compilation which compiles the asm.js code directly to assembly immediately after it's parsed. This gives you predictability (you literally get warnings in the console if it couldn't compile), which is really…
Related, and you've sort of mentioned this: having your browser be able to validate asm.js is useful for web developers, because then they know if their code is broken (and so will run slower).
Earlier quoted context omitted.
While you are correct that the actual runtime speed in theory should be able to be achieved with the JIT, there are other advantages to officially supporting asm.js. One of the main things is ahead-of-time (AOT) compilation which compiles the asm.js code directly to assembly immediately after it's parsed. This gives you predictability (you literally get warnings in the console if it couldn't compile), which is really…
asm.js represents LLVM bytecode, which is already behind the compilation step. The programmer sees errors when generating the asm.js, not when executing it. Whether it is then executed by a JIT or not is, in this case, irrelevant. I absolutely agree there are advantages to taking the asm.js -> LLVM bytecode shortcut (cue every single benchmark showing FF on top). But compiler warnings are not one of them. EDIT: To cl…
You make a good point though; it's not like we are seeing helpful warnings when writing our frontend JS apps. But those warnings are still crucial when actually building & deploying stuff; with various tooling and browsers it's really nice to see a "successful asm.js compilation" message and you know it's working. If you upgrade a tool, you can be sure that it's still working, etc.
Also, it's not uncommon for people to write new languages or compilers and having that feedback that you are on the fast path is really nice.
I think your point has some merit though.
The other benefit to AOT is simply that, when the app starts running, it immediately starts running in the fast path.
Earlier quoted context omitted.
In the end there's not much difference between PNaCl and asm.js (see for yourself: http://floooh.github.io/oryol/ ). Both compile down to 'immutable' machine code, either via JIT or AOT compilation, both call into the same browser API backends, both are based on LLVM (actually PNaCl and emscripten use the same modified LLVM frontend) both have somewhat similar restrictions what APIs can be called in threads, the only…
There's a very big difference. NaCl and PNaCl don't use the standard, multi-vendor web APIs. They use a proprietary single-vendor (Google) API, Pepper. This not only makes implementation by competitors difficult, it's needless duplication of effort (why maintain multiple APIs for the same thing?). Also, both are based on single-vendor, single-implementation technology. NaCl used actual native code, so if you're not u…
Earlier quoted context omitted.
While you are correct that the actual runtime speed in theory should be able to be achieved with the JIT, there are other advantages to officially supporting asm.js. One of the main things is ahead-of-time (AOT) compilation which compiles the asm.js code directly to assembly immediately after it's parsed. This gives you predictability (you literally get warnings in the console if it couldn't compile), which is really…
asm.js represents LLVM bytecode, which is already behind the compilation step. The programmer sees errors when generating the asm.js, not when executing it. Whether it is then executed by a JIT or not is, in this case, irrelevant. I absolutely agree there are advantages to taking the asm.js -> LLVM bytecode shortcut (cue every single benchmark showing FF on top). But compiler warnings are not one of them. EDIT: To cl…
Earlier quoted context omitted.
There's a very big difference. NaCl and PNaCl don't use the standard, multi-vendor web APIs. They use a proprietary single-vendor (Google) API, Pepper. This not only makes implementation by competitors difficult, it's needless duplication of effort (why maintain multiple APIs for the same thing?). Also, both are based on single-vendor, single-implementation technology. NaCl used actual native code, so if you're not u…
Sure, but under the hood both the HTML5 APIs and Pepper APIs call into the same code, at least for WebGL, the performance behaviour on Chrome between WebGL and Pepper's GL wrapper is basically identical, and most other exposed API features are so similar to their HTML5 counterparts that it is almost certain that there's the same code underneath.
It's still wasted effort, though. Maybe they share some code, but Pepper is an unnecessary extra API. One that's non-standard and results in vendor lock-in.
Come on Google! Support asm.js in Chrome.... Give up on Native Client.... Even Microsoft is doing Asm.js now....
I want less things emulated via Javascript and more stuff done directly via native code. Everything that is built on top of HTML/JS/CSS is basically a hack that is trying to emulate much better native platforms and it sucks. Why advocate to stay there? Let's go in the other direction in my opinion.
Earlier quoted context omitted.
asm.js represents LLVM bytecode, which is already behind the compilation step. The programmer sees errors when generating the asm.js, not when executing it. Whether it is then executed by a JIT or not is, in this case, irrelevant. I absolutely agree there are advantages to taking the asm.js -> LLVM bytecode shortcut (cue every single benchmark showing FF on top). But compiler warnings are not one of them. EDIT: To cl…
I think I see what you are saying, but your statements aren't completely right which might be why you are being downvoted. "asm.js represents LLVM bytecode" is not right, just because you can compile one thing to another does not mean it represents it. You make a good point though; it's not like we are seeing helpful warnings when writing our frontend JS apps. But those warnings are still crucial when actually buildi…
And I didn't know it was just derived from it; I thought asm.js was idempotent with llvm ir!
Earlier quoted context omitted.
asm.js represents LLVM bytecode, which is already behind the compilation step. The programmer sees errors when generating the asm.js, not when executing it. Whether it is then executed by a JIT or not is, in this case, irrelevant. I absolutely agree there are advantages to taking the asm.js -> LLVM bytecode shortcut (cue every single benchmark showing FF on top). But compiler warnings are not one of them. EDIT: To cl…
It's likely because asm.js isn't at all related to LLVM. Emscripten and the like use LLVM IR to compile to asm.js but that doesn't mean that asm.js is LLVM IR. asm.js is actually just a restricted subset of javascript that avoids a lot of things that invoke the garbage collector, forces certain type constraints (variables have static types that can be inferred at parse/compile time), and emulation of pointers using a…
Come on Google! Support asm.js in Chrome.... Give up on Native Client.... Even Microsoft is doing Asm.js now....