SoylentNews is people
SoylentNews
Mozilla's Project Electrolysis aims to allow tabs and user interfaces to run in separate processes. It has been activated by default in recent nightly builds:
In current versions of desktop Firefox, the entire browser runs in a single operating system process. In particular, the JavaScript that runs the browser UI (also known as "chrome code") runs in the same process as the code in web pages (also known as "content" or "web content"). Future versions of Firefox will run the browser UI in a separate process from web content. In the first iteration of this architecture all browser tabs will run in the same process, and the browser UI will run in a different process. In future iterations, we expect to have more than one content process.
Developer Will Bamberg says the change will bring stability and security improvements. "There are three main reasons for making Firefox run content in a separate process: performance, security, and stability, Bamberg says. "The goal is to reduce 'jank' -- those times when the browser seems to briefly freeze when loading a big page, typing in a form, or scrolling. "In multiprocess Firefox, content processes will be sandboxed. A well-behaved content process won't access the filesystem directly; it will have to ask the main process to perform the request." Bamberg says "well-behaved" content processes needs to access much of the network and file systems. This would be much more restricted under the changes.
Former CEO of Mozilla Brendan Eich has announced a project called WebAssembly that could replace asm.js:
It's by now a cliché that JS has become the assembly language of the Web. Rather, JS is one syntax for a portable and safe machine language, let's say. Today I'm pleased to announce that cross-browser work has begun on WebAssembly, a new intermediate representation for safe code on the Web.
What: WebAssembly, "wasm" for short, .wasm filename suffix, a new binary syntax for low-level safe code, initially co-expressive with asm.js, but in the long run able to diverge from JS's semantics, in order to best serve as common object-level format for multiple source-level programming languages.
Who: A W3C Community Group, the WebAssembly CG, open to all. As you can see from the github logs, WebAssembly has so far been a joint effort among Google, Microsoft, Mozilla, and a few other folks. I'm sorry the work was done via a private github account at first, but that was a temporary measure to help the several big companies reach consensus and buy into the long-term cooperative game that must be played to pull this off.
Original Submission
(Score: 5, Interesting) by VortexCortex on Saturday June 20 2015, @06:48AM
As someone who develops in "pure" ASM.js from time to time, I'd say, "WASM is like a Java VM for the web." Unfortunately, we actually need one (again).
It's too bad Sun dropped the ball and brought the whole kitchen sink of API glut (and attack surface) into Java Applets instead of tailoring Applets to have a lean mean web API for Java bytecode (similar to what they did for J2ME), because a Web VM is what we've needed. Javascript was just supposed to be the inefficient glue that let applets interact with the HTML elements, so it wasn't meant for efficiency since Java would do the heavy lifting, but now Java is all but banned from browsers. A standard VM bytecode is great because that means I can compile directly into a portable format from other languages -- You can compile C into Java VM or Perl Parrot VM bytecode, for example. It allows us to say, "Screw your 'expressiveness', damn starry eyed language devs! I'm compiling all my existing code for your VM's bytecode and saving time instead of reimplementing my wheels in your syntax."
An efficient compilable intermediary opcode for the web is needed because Javascript's "prototypical" orientation is practically designed to be antagonistic to performance. You never hear people announcing "We've sped up C by another 15%" like you keep hearing with new "Javascript engines". Efficient languages get marginal optimizations since they weren't designed to fight basic Von Neumann architectural realities in the first place. JS engine devs are not speeding up anything, software doesn't change the hardware speed. They're just working around existing inefficiencies, and they have enough go on for decades of "speed improvements" thanks to the inefficient design of JS.
I liked Google's NaCl offering, but it's clunky and not ARM compliant bytecode (it's a 'safe' subset of x86 machine code). JS engines are to the point now that if you write code in a procedural or functional way the JIT compiler will get the code going about as fast as on a VM's JIT (like Java's). My SHA256, 512, and SHA3 implementation in ASM.js performs as fast as my C implementations in FF, and only about 8% slower than C when running on Chrome(-ium) or Safari. IE... well, it runs my code, but at 300% slower. Last I checked they hadn't sped up the ArrayBuffers memory access yet, but I haven't tested IE for performance in a long while. Unreal devs said they got their engine code into ASM.js and running at about 2x slower than native, but that includes lots of calls outside the ASM.js which a hashing function doesn't do, so my comparisons are faster than theirs based on a much different use case.
I'll keep targeting ASM.js, though I have many a beef with it, because it's valid JS code. That means ASM.js (and initially WEBASM) will still run even on a browser that doesn't know how to compile it to machine code and cache it like Firefox does. Chrome's generic optimizations alone make ASM.js code run pretty fast, but usually not as fast as FF (Chrome's NaCL goes faster than ASM.js, but FF and IE can't run it). The biggest bottleneck is calling out of the ASM.js context to do things like process input or manipulate the DOM or do rendering calls (Can't access Canvas, WebGL, Ajax, or raw audio pipelines directly from pure ASM.js). It looks like WASM seeks to fix some of that boundary inefficiency by eventually allowing us to take that performance hogging Javascript out of the loop completely. I probably won't switch to WASM until its more mature and has a decent debugger. Currently my metalanguage can compile down to ASM.js and provide specially formatted line number directives via comments, which allows me to single step the code in the JS debugger by preventing its compilation to ASM.js.
If WebASM catches on then I guess I'll get to add yet another platform to my meta language and solution support list. Emscripten uses LLVM to target ASM.js so, for example, you can compile C code into WASM yourself and run it in a browser if you want. I don't use Emscripten or LLVM for my meta language because I utilize the target language paradigms where available instead of taking the convoluted trip to low level bytecode and back (unlike LLVM, my intermediary format is a high level bytecode which can also be interpreted to run directly in a VM). With a meta compiler I can say $LANG is the Assembly of $PLATFORM. Screw languages, they all suck. Best to make one you like and only write your code in it once, then compile it down to whatever newfangled language / platform they'll come out with next year.
It used to be that language devs would frown on us performance sticklers, but now that mobiles are on the scene with lower power CPUs the poor efficiency of certain crappy language designs is getting rubbed in frustrated users faces. If I was Google, I'd fuck all these "ASM fur da webz" people over by just sticking a Davlik VM in Chrome so you could run Android apps in the browser, oh, wait... [theverge.com] Why do we need WASM again? Firefox, IE, Safari, et. al. should just integrate the open source Android Davlik VM bytecode and be done (and leverage an existing pool of Android developers).