The difference between asm.js with and without special optimizations is not necessarily that big. See benchmarks here, showing it can be anywhere from 1x (almost no change) to 5x. It depends a lot on the benchmark. And in a demo like this, the GPU matters a lot too, which makes asm.js matter less.
So all modern browsers should already work on this demo. But this is a very large codebase (over 1M lines of C++ compiled to JS), and it pushes the limit of what browsers have tested on. Now that this demo is public, that should make it easier for other browsers to fix what they need so the demo can work on them.
This requieres Mozilla JS enhancements (asm.js) currently on nightly builds, It can work on other browsers but without the performance tuning made for the JS subset that is asm.js it will run slow. Chromium bug proposing to add support for asm.js http://code.google.com/p/v8/issues/detail?id=2599
It doesn't require special asm.js optimizations (asm.js is a subset of JavaScript, so it already runs properly in all modern browsers). The demo works fine in the stable release of Firefox for example, which has no special asm.js optimizations. It is faster in Firefox nightly though which does have those optimizations. But how much faster depends on the CPU and GPU, it might matter a lot or it might matter a little. In this demo a lot of time is spent in WebGL, so a fast GPU and good WebGL implementation matters a lot too.
The demo should work in any browser with WebGL and JavaScript support. For example the only reason it currently fails in Chrome is due to a bug related to memory use. Hopefully that will be fixed soon.
Linux, NVidia drivers. 3D games and WebGL work perfectly here, so it isn't a problem with the hardware or drivers, must be something with their support I guess as you said.
Even if this ran, it took 600MB. That's huge, if it's ported from an iOS game it must take much less memory there. So I am very unimpressed by the quality of this port.
Looks broken. Takes very long to load, then takes 600MB and something seems to happen, but no polygons are rendered. Looks like just one ugly repeating texture for the ground, and a few bushes. I can pan around though but there is nothing to actually see no matter how long I wait.
http://imagebin.org/206217
This port doesn't look very successful.
Do I need to remind you that Epic recently ported the latest version of Unreal Engine to Flash [unrealengine.com]? WebGL can't touch what is being done in Flash.
They ported it, but how well does it run? Until we see the demo in the wild, so we can test it ourselves, I am skeptical. Their demo machine is likely not a typical one.
The important bit is "eventual". Right now, NaCl is CPU specific, and it is indeed fast. But making it portable may diminish the speed, it is not clear how fast PNaCl will be when it is finished, there are numerous challenges - for example, the LLVM bitcode that is shipped is very large (bitcode is much larger than object code because it contains higher-level information), and it takes time to optimize before it is run.
Supporting NaCl now when it is CPU specific, in the hopes of it fixing its problems some time in the future, is a big leap of faith.
As for PPAPI, yes, it is BSD licensed. But open source doesn't mean it is an open standard, nor does it mean it is usable without an extreme amount of engineering; for practical purposes, it isn't in its current state - it's tied to Chrome internals, and cannot just be dropped in Firefox or Opera; worse, it is constantly changing to fit Google's needs (mainly driven by NaCl and Flash) - it's a moving target with no spec.
If it is, I'd like to see that pointed out on their Wiki pages. Right now, it simply mentions that they're not going to implement Pepper with no further explanation. When I go to the Pepper web site, I see all kinds of reasons why one would want to implement Pepper. If the Mozilla people just wrote a few words explaining the situation, it would make the situation much easier for confused users like me.
There has been a lot of talk about this in the past, the main issues that I recall are
Pepper's goal is to enable plugins to do more things. But all web browsers except for Chrome are moving away from plugins and towards HTML5, there are no plugins in iOS nor in Windows 8 Metro for example. Implementing Pepper would take a lot of effort, other browsers prefer to look to the future and optimize HTML5 technologies. Even WebKit doesn't want Pepper in it.
Pepper has a single implementation and no formal standardization documentation. Trying to implement it now means reproducing whatever behavior Pepper has in Chrome. Since Pepper has lots of methods and is quite complex, this would be a very hard and perhaps impossible task (since Chrome can keep changing Pepper when it needs/wants to).
Pepper has been driven by two main use cases: Flash and Native Client. Both are technologies that only Google supports, all other browsers prefer HTML5 over Flash and oppose Native Client because it is CPU arch specific. With those two use cases out of the way, it isn't clear there is a reason for other browsers to implement Pepper at all
Re:How does it compare to Chrome?
on
Firefox 10 Released
·
· Score: 4, Insightful
Well, if Firefox slimmed down enough
Actually if you download the Chrome and Firefox installers, you will see that Chrome is twice as large.
There are various definitions of "slimness", each browser wins on some, unsurprising because both of these are good browsers.
And FF10 also makes addons compatible by default
on
Firefox 10 Released
·
· Score: 5, Informative
Firefox has launched a new version release system, creating an ESR for enterprises, organizations, etc. which is released once in 7 Firefox usual releases (Firefox 10, 17, 24, etc.), so that they don't have so much trouble (it must be horrible to find that two new versions have appeared as you are updating...). See a submission which didn't get to the front page for more details.
In addition to the ESR Firefox (which is basically like an Ubuntu LTS in how it works), Firefox 10 also marks addons as compatible by default. These two things solve much of the update annoyances.
FF11 will remove the UAC prompt on Windows, which will be a further improvement in 6 weeks from now.
So what's the difference between a tag labeled "end" and a null?
A null pointer, if you dereference it, leads to a crash or possibly to a security vulnerability (imagine if you access a structure element, so it is an offset from 0). Whereas an actual, complete object who is treated as "the end" will not cause such problems.
Without null pointers, you avoid a lot of security risks and runtime failures, which are why null pointers are called "the billion $ mistake".
It's not a plugin. It's integrated in chrome. It's called NaCl aka native client.
NaCl works through the Pepper plugin interface, which is a plugin API just like NPAPI is. So NaCl is most definitely a plugin, even if it is bundled in Chrome. For comparison, Flash is also bundled in Chrome, but it is of course still a plugin (it works through NPAPI).
Finally please note that you can't currently run NaCl properly on tablet devices.
You can't run them on anything that isn't x86 or x86_64, and it isn't clear whether we ever will.
NaCl is designed to be portable to different browsers and OSes
But it is *not* designed to be portable to different CPUs. Try running NaCl MAME on your ARM or MIPS phone or on your PowerPC game console's browser - it won't work. This by itself makes NaCl unsuitable for the web. Not only can't we run it on non-x86 hardware now, it would make life harder for new CPU archs in the future.
(Yes, there is a research project trying to make NaCl portable to different CPUs. It is too early to tell if it will succeed, and what tradeoffs it will have in terms of speed, portability, code size, etc.)
There is a fat nexe for x64 and x64_64, but nothing else. That still isn't portable.
Portability is important on the web. People expect to visit websites from their web browser, and for them to work regardless of their OS and CPU. NaCl doesn't work like that.
To me [NaCl] seems like a reasonable way to move the web forward without subverting it (or even altering it much).
There are a few big problems with that:
NaCl is not portable. NaCl apps only run on x86 and x86_64, not ARM or PowerPC or anything else.
NaCl is not a standard or even a proposed standard, and all other browser vendors are opposed to it (because of the previous issue, and because it is controlled by Google). As a consequence, NaCl apps only run on Chrome (and on x86 and x86_64).
The web is all about open standards, viewing the same web from any browser or any OS, and so forth. So NaCl, that only runs on two archs and on one browser, is a step backwards.
How difficult is it to set a stable extensions API, make extension developers aware of it, and then making the browser get out of the way?
It's very difficult, with certain types of extension APIs.
We could just drop the current extension API entirely and replace it with one like Chrome has. That would make things much simpler, it could be stable, there would be no way for extensions to leak memory or slow down the browser, and the browser could auto-update very easily. However, that means throwing out all the current extensions that Firefox has. Worse, that new extension API would not allow recreating all the current extensions either - stable, safe extension APIs are necessarily more limiting: They are stable and safe because they don't let extensions do everything. The upside is safety and stability, the downside is the addons are less powerful, that is they can do less. As one example, Firefox addons can radically change how the browser looks, Chrome addons cannot. There is a tradeoff here, I am not saying one approach is better than the other, but just that you can't have everything.
Firefox is taking two paths here: First, we are adding a new, safe&stable extension API (Jetpack addons). But we are also keeping the existing one, and making a lot of complex changes to the browser to allow those addons to be updated automatically etc., so the current downsides are less troublesome. That takes time, but each release is an improvement (in the number of addons that can auto-update, for example).
What happened? My guess is they either stopped caring about anybody actually using firefox for anything reliable and began toying with the source
Hi, I'm a developer at Mozilla. That part is certainly not true - but it is an amusing thought;) All of our meeting notes are open (for example), you can see our discussions on IRC, etc., so you don't need to speculate on this or to just take my word for it. You can read everything we say as we build Firefox.
or senior developers left the project
Also definitely not true.
and were replaced by monkeys.
I'm pretty sure that one is not true either;)
I actually had a chat on slashdot with a developer of ff. The guy was so disillusioned towards why would people ever have expectations of an open source project and he can do wtf he wants cause he's not getting paid to do it. Well he's right, but what will he do when nobody is using firefox anymore?
There are a lot of people that do get paid to work on Firefox. The Firefox dev community is an interesting mix between paid people and volunteers. It's different from say WebKit, which is almost all paid (Google and Apple, mainly), or at the other extreme a typical community open source project that is 100% volunteer.
As to "what happened to Firefox" - two parts. Regarding market share, Firefox is not gaining and perhaps losing a little. That isn't surprising - the browser market is extremely competitive now. Firefox has also made a mistake with addons and the rapid release schedule, we are working to fix it (and have been for a while - it's a complex problem), and the top people at Mozilla admitted the problem. Aside from that, we are constantly improving performance and responsiveness, and latest benchmarks and reviews are quite positive, so I think we are doing a good job. But again, the market is now (thankfully!) very competitive. I don't expect Firefox, which has far fewer resources than Google, Apple and Microsoft, to easily gain market share like before when IE was a monopoly. Even competing on the same level with those companies (the biggest in the tech industry), when Mozilla is a nonprofit, is a nice achievement in my opinion.
I agree that would be very bad. But I don't think IE has any chance of dominating the market at this point. It's losing market share to Chrome at a very fast pace. In fact the biggest risk of a browser monopoly at this point is Chrome (it'll soon be #2 on desktop, and eventually #1, and when it launches on Android it will be #1 on mobile).
Not sure why you are sad IE is a good browser. I work for Mozilla, but I'm very happy Microsoft is finally getting its act together. IE9 is decent, and IE10 will be a great browser, competitive with the latest Firefox, Chrome and Opera. Healthy competition is a good thing!
it certainly seems like it from recent increased version numbers pace
Both Chrome and Firefox release a new major version every 6 weeks. Are we going to make the same jokes every 3 weeks (once for each Chrome and Firefox release)? It's getting old...
Chrome (and later Firefox) bumps the major version number because these rapid updates do change functionality and potentially break things. So this is technically the right change to make, even if it seems odd due to the speed of these releases. If only the minor version number were updated, the complaints would be "things broke with a minor update!" - and those complaints would be justified.
Breaking stuff often isn't something to be proud of. It's something to be ashamed of. That's why Firefox is losing ground again now.
Firefox isn't losing market share - it's been flat for a while. (So, growing in absolute numbers, but not in percent of the market as it grows.)
Chrome is also doing these fast updates that break websites, but is growing in market share. So the issues are more complicated here I think. I do agree though that breaking stuff is bad! Both Firefox and Chrome are doing their best to avoid that, but with rapid updates, it's impossible to avoid entirely.
Slashdot Mirror
The difference between asm.js with and without special optimizations is not necessarily that big. See benchmarks here, showing it can be anywhere from 1x (almost no change) to 5x. It depends a lot on the benchmark. And in a demo like this, the GPU matters a lot too, which makes asm.js matter less.
So all modern browsers should already work on this demo. But this is a very large codebase (over 1M lines of C++ compiled to JS), and it pushes the limit of what browsers have tested on. Now that this demo is public, that should make it easier for other browsers to fix what they need so the demo can work on them.
This requieres Mozilla JS enhancements (asm.js) currently on nightly builds, It can work on other browsers but without the performance tuning made for the JS subset that is asm.js it will run slow. Chromium bug proposing to add support for asm.js http://code.google.com/p/v8/issues/detail?id=2599
It doesn't require special asm.js optimizations (asm.js is a subset of JavaScript, so it already runs properly in all modern browsers). The demo works fine in the stable release of Firefox for example, which has no special asm.js optimizations. It is faster in Firefox nightly though which does have those optimizations. But how much faster depends on the CPU and GPU, it might matter a lot or it might matter a little. In this demo a lot of time is spent in WebGL, so a fast GPU and good WebGL implementation matters a lot too.
The demo should work in any browser with WebGL and JavaScript support. For example the only reason it currently fails in Chrome is due to a bug related to memory use. Hopefully that will be fixed soon.
You can compile C++ to JS and run it on the web, using Emscripten. It supports SDL.
Here is an example 2D game ported that way: http://www.syntensity.com/static/mams/mams.html
Linux, NVidia drivers. 3D games and WebGL work perfectly here, so it isn't a problem with the hardware or drivers, must be something with their support I guess as you said.
Even if this ran, it took 600MB. That's huge, if it's ported from an iOS game it must take much less memory there. So I am very unimpressed by the quality of this port.
Looks broken. Takes very long to load, then takes 600MB and something seems to happen, but no polygons are rendered. Looks like just one ugly repeating texture for the ground, and a few bushes. I can pan around though but there is nothing to actually see no matter how long I wait. http://imagebin.org/206217 This port doesn't look very successful.
Do I need to remind you that Epic recently ported the latest version of Unreal Engine to Flash [unrealengine.com]? WebGL can't touch what is being done in Flash.
They ported it, but how well does it run? Until we see the demo in the wild, so we can test it ourselves, I am skeptical. Their demo machine is likely not a typical one.
The important bit is "eventual". Right now, NaCl is CPU specific, and it is indeed fast. But making it portable may diminish the speed, it is not clear how fast PNaCl will be when it is finished, there are numerous challenges - for example, the LLVM bitcode that is shipped is very large (bitcode is much larger than object code because it contains higher-level information), and it takes time to optimize before it is run.
Supporting NaCl now when it is CPU specific, in the hopes of it fixing its problems some time in the future, is a big leap of faith.
As for PPAPI, yes, it is BSD licensed. But open source doesn't mean it is an open standard, nor does it mean it is usable without an extreme amount of engineering; for practical purposes, it isn't in its current state - it's tied to Chrome internals, and cannot just be dropped in Firefox or Opera; worse, it is constantly changing to fit Google's needs (mainly driven by NaCl and Flash) - it's a moving target with no spec.
If it is, I'd like to see that pointed out on their Wiki pages. Right now, it simply mentions that they're not going to implement Pepper with no further explanation. When I go to the Pepper web site, I see all kinds of reasons why one would want to implement Pepper. If the Mozilla people just wrote a few words explaining the situation, it would make the situation much easier for confused users like me.
There has been a lot of talk about this in the past, the main issues that I recall are
Well, if Firefox slimmed down enough
Actually if you download the Chrome and Firefox installers, you will see that Chrome is twice as large.
There are various definitions of "slimness", each browser wins on some, unsurprising because both of these are good browsers.
Firefox has launched a new version release system, creating an ESR for enterprises, organizations, etc. which is released once in 7 Firefox usual releases (Firefox 10, 17, 24, etc.), so that they don't have so much trouble (it must be horrible to find that two new versions have appeared as you are updating...). See a submission which didn't get to the front page for more details.
In addition to the ESR Firefox (which is basically like an Ubuntu LTS in how it works), Firefox 10 also marks addons as compatible by default. These two things solve much of the update annoyances.
FF11 will remove the UAC prompt on Windows, which will be a further improvement in 6 weeks from now.
So what's the difference between a tag labeled "end" and a null?
A null pointer, if you dereference it, leads to a crash or possibly to a security vulnerability (imagine if you access a structure element, so it is an offset from 0). Whereas an actual, complete object who is treated as "the end" will not cause such problems.
Without null pointers, you avoid a lot of security risks and runtime failures, which are why null pointers are called "the billion $ mistake".
It's not a plugin. It's integrated in chrome. It's called NaCl aka native client.
NaCl works through the Pepper plugin interface, which is a plugin API just like NPAPI is. So NaCl is most definitely a plugin, even if it is bundled in Chrome. For comparison, Flash is also bundled in Chrome, but it is of course still a plugin (it works through NPAPI).
Finally please note that you can't currently run NaCl properly on tablet devices.
You can't run them on anything that isn't x86 or x86_64, and it isn't clear whether we ever will.
NaCl is designed to be portable to different browsers and OSes
But it is *not* designed to be portable to different CPUs. Try running NaCl MAME on your ARM or MIPS phone or on your PowerPC game console's browser - it won't work. This by itself makes NaCl unsuitable for the web. Not only can't we run it on non-x86 hardware now, it would make life harder for new CPU archs in the future.
(Yes, there is a research project trying to make NaCl portable to different CPUs. It is too early to tell if it will succeed, and what tradeoffs it will have in terms of speed, portability, code size, etc.)
PNaCl is portable because they'll use llvm.
LLVM is not portable, see for example http://thread.gmane.org/gmane.comp.compilers.llvm.devel/43769/focus=43770
It is very hard to try to make LLVM portable, which is what PNaCl is attempting. Maybe they will succeed, we will see in time.
NaCl is not portable. NaCl apps only run on x86 and x86_64, not ARM or PowerPC or anything else.
Which is why there is PNaCl
Which is an interesting research project, but it's too early to say if it will achieve the goals of complete portability and full performance.
There is a fat nexe for x64 and x64_64, but nothing else. That still isn't portable.
Portability is important on the web. People expect to visit websites from their web browser, and for them to work regardless of their OS and CPU. NaCl doesn't work like that.
It's open source, but it still is not portable not standardized.
To me [NaCl] seems like a reasonable way to move the web forward without subverting it (or even altering it much).
There are a few big problems with that:
The web is all about open standards, viewing the same web from any browser or any OS, and so forth. So NaCl, that only runs on two archs and on one browser, is a step backwards.
How difficult is it to set a stable extensions API, make extension developers aware of it, and then making the browser get out of the way?
It's very difficult, with certain types of extension APIs.
We could just drop the current extension API entirely and replace it with one like Chrome has. That would make things much simpler, it could be stable, there would be no way for extensions to leak memory or slow down the browser, and the browser could auto-update very easily. However, that means throwing out all the current extensions that Firefox has. Worse, that new extension API would not allow recreating all the current extensions either - stable, safe extension APIs are necessarily more limiting: They are stable and safe because they don't let extensions do everything. The upside is safety and stability, the downside is the addons are less powerful, that is they can do less. As one example, Firefox addons can radically change how the browser looks, Chrome addons cannot. There is a tradeoff here, I am not saying one approach is better than the other, but just that you can't have everything.
Firefox is taking two paths here: First, we are adding a new, safe&stable extension API (Jetpack addons). But we are also keeping the existing one, and making a lot of complex changes to the browser to allow those addons to be updated automatically etc., so the current downsides are less troublesome. That takes time, but each release is an improvement (in the number of addons that can auto-update, for example).
What happened? My guess is they either stopped caring about anybody actually using firefox for anything reliable and began toying with the source
Hi, I'm a developer at Mozilla. That part is certainly not true - but it is an amusing thought ;) All of our meeting notes are open (for example), you can see our discussions on IRC, etc., so you don't need to speculate on this or to just take my word for it. You can read everything we say as we build Firefox.
or senior developers left the project
Also definitely not true.
and were replaced by monkeys.
I'm pretty sure that one is not true either ;)
I actually had a chat on slashdot with a developer of ff. The guy was so disillusioned towards why would people ever have expectations of an open source project and he can do wtf he wants cause he's not getting paid to do it. Well he's right, but what will he do when nobody is using firefox anymore?
There are a lot of people that do get paid to work on Firefox. The Firefox dev community is an interesting mix between paid people and volunteers. It's different from say WebKit, which is almost all paid (Google and Apple, mainly), or at the other extreme a typical community open source project that is 100% volunteer.
As to "what happened to Firefox" - two parts. Regarding market share, Firefox is not gaining and perhaps losing a little. That isn't surprising - the browser market is extremely competitive now. Firefox has also made a mistake with addons and the rapid release schedule, we are working to fix it (and have been for a while - it's a complex problem), and the top people at Mozilla admitted the problem. Aside from that, we are constantly improving performance and responsiveness, and latest benchmarks and reviews are quite positive, so I think we are doing a good job. But again, the market is now (thankfully!) very competitive. I don't expect Firefox, which has far fewer resources than Google, Apple and Microsoft, to easily gain market share like before when IE was a monopoly. Even competing on the same level with those companies (the biggest in the tech industry), when Mozilla is a nonprofit, is a nice achievement in my opinion.
I agree that would be very bad. But I don't think IE has any chance of dominating the market at this point. It's losing market share to Chrome at a very fast pace. In fact the biggest risk of a browser monopoly at this point is Chrome (it'll soon be #2 on desktop, and eventually #1, and when it launches on Android it will be #1 on mobile).
Not sure why you are sad IE is a good browser. I work for Mozilla, but I'm very happy Microsoft is finally getting its act together. IE9 is decent, and IE10 will be a great browser, competitive with the latest Firefox, Chrome and Opera. Healthy competition is a good thing!
it certainly seems like it from recent increased version numbers pace
Both Chrome and Firefox release a new major version every 6 weeks. Are we going to make the same jokes every 3 weeks (once for each Chrome and Firefox release)? It's getting old...
Chrome (and later Firefox) bumps the major version number because these rapid updates do change functionality and potentially break things. So this is technically the right change to make, even if it seems odd due to the speed of these releases. If only the minor version number were updated, the complaints would be "things broke with a minor update!" - and those complaints would be justified.
Breaking stuff often isn't something to be proud of. It's something to be ashamed of. That's why Firefox is losing ground again now.
Firefox isn't losing market share - it's been flat for a while. (So, growing in absolute numbers, but not in percent of the market as it grows.)
Chrome is also doing these fast updates that break websites, but is growing in market share. So the issues are more complicated here I think. I do agree though that breaking stuff is bad! Both Firefox and Chrome are doing their best to avoid that, but with rapid updates, it's impossible to avoid entirely.