We've looked into this, but the potential for incompatibilities between the CRT headers and the implementation is worrisome. It also hasn't been a real priority to this point because it wasn't a big deal to ship the VC8 CRT alongside Firefox. (And, in fact, until recently, it was pretty necessary because we were building a custom CRT from source so we could patch it to replace the default malloc.)
Do you have a source to back that up? I've never been able to find any information saying that Microsoft compiles their OS libraries with PGO. In fact, in their "Debugging in the (Very) Large" paper, they state that they even turned off frame-pointer omission, since it caused more headaches and didn't give them a noticeable speedup. http://research.microsoft.com/apps/pubs/default.aspx?id=81176
I really wanted this to work, but it doesn't actually work in combination with PGO:
(with the VC2008 32-bit compiler) $ cl -GL -Fotest.obj -c test.cpp Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.30729.01 for 80x86 Copyright (C) Microsoft Corporation. All rights reserved.
test.cpp
(with the VC2008 64-bit linker) $ link -MACHINE:X86 -LTCG -OUT:test.exe test.obj Microsoft (R) Incremental Linker Version 9.00.30729.01 Copyright (C) Microsoft Corporation. All rights reserved.
fatal error C1905: Front end and back end not compatible (must target same proce ssor). LINK : fatal error LNK1257: code generation failed
Except what BZ just said is that you pretty much need all of those core pieces to start the browser anyway, so splitting them out into separate modules just makes the browser start more slowly.
Also, cross-module optimization does help quite a bit. Microsoft's PGO optimizer is able to do crazy stuff like speculative virtual call inlining, which is a big deal on a large C++ codebase like Mozilla.
Uh, what? Visual C++ produces better optimized code than GCC in almost all cases, especially when you toss PGO into the mix. Firefox runs just fine on most people's systems. There are plenty of pathological cases on people's systems that make it perform poorly: poorly-written extensions, poorly-written antivirus software that hooks into our process, horrible disk fragmentation, etc. The list goes on and on, we've seen all of these things in bug reports from users experiencing poor performance. If you're experiencing poor performance, I'd encourage you to file a bug (you can even link the bug here, and we can take a look). Unless you're running on some ancient hardware it's possible there's a reasonable explanation for your situation that has nothing to do with the compiler we're using.
Your last statement reads like a non-sequitur. What other large open-source project that's comparable to Firefox is producing Windows binaries with GCC that you can compare performance? Unless it's a web browser, comparing performance is like comparing apples and moon rocks.
Yes, but you can get a 32->64 cross-GCC toolchain easily. You can't get one of those from Microsoft, so you're stuck with a maximum of 4GB of address space if you run the 32-bit toolchain on a 64-bit Windows system.
Nope, the issue is still present in Visual C++ 2010. We're planning on switching to that soon, but we either have to work around its lack of support for Windows 2000 / Windows XP pre-SP2, or declare those platforms (and a few million users) unsupported.
This is an advanced setting that we don't expect users to tweak. The default value should work for most people. Here's a decent test: if you have to go to about:config to change a setting, it's not something we want normal users to touch, so talking about usability at that point is a bit silly. The most usable software just does the right thing and doesn't require users to change setttings.
Conveniently Mike is also the Debian Firefox package maintainer, so I'd expect him to apply as much of his work as possible to those packages. That's not to say that Debian's Firefox builds will be as fast as the official Mozilla builds, since Debian has other priorities that may conflict.
Intel does have ICC, but it's kind of expensive, and it's picky in different ways than GCC/VC++, so it means fixing up things across the entire codebase to even get it to work. I was able to build our JavaScript library on OS X with ICC at one point without a huge amount of hassle, and it was a decent speedup back then (but Apple's GCC is ancient). Using it on Windows would probably be a PITA in terms of amount of work to even compare performance.
There were actually several GCC bugs that had to be fixed in order for us to use PGO. Thankfully Mike has a good working relationship with GCC maintainers, and he upstreamed all necessary patches, so everybody wins.
Not really true, we actually built our Linux builds with -Os (optimize for space) up until this change, where we switched to -O3 (optimize for speed) + changed from GCC 4.3 to GCC 4.5 and also enabled profile-guided optimization at the same time. The end result is a pretty nice performance win and not much disk space change.
Windows builds of Firefox didn't get profile-guided optimization until Firefox 3 (2008), so it's only about 3 years behind. Actually I think Firefox 1.0 might have been shipped with PGO on Linux, but I wasn't directly involved in that release so I can't recall. Mike had to chase down a number of bugs in GCC in order to make it work again, which is nice because it benefits all GCC users. GCC developers are using Firefox as a testcase for further optimizations in GCC 4.6 (like LTO), so we should hopefully be able to use those when it's released.
Firefox codenames are always park names nowadays. This park happens to be in Indonesia, which (AFAIK) is the first country to pass 50% Firefox marketshare.
It's certainly possible, but we do have an extensive set of unit tests and performance tests these days, and we don't land new features without a test suite. Combined with our crash reporting infrastructure, I have pretty high confidence that the quality of the software is improving.
That's great, but there are lots of extensions that do in fact break. If users update to a new version of Firefox and their extensions don't work, or cause their browser to crash or otherwise malfunction (not a theoretical problem), they are not happy users.
The Jetpack project is working to create a stable (but admittedly more limited) API for extensions to use to make it possible to sidestep this problem.
Uh, the primary goal of the Lorentz branch is to merge the out-of-process plugins architecture back to the stable 1.9.2 branch that Firefox 3.6 was released from.
Uh, you can disable the blacklist, if you really want to. It's just enabled by default because we think it's the right thing to do. The vast majority of people do not know they even have these things installed, nevertheless how they would update them or otherwise mitigate their risk.
Also, if you read the original blog post, Mike Shaver spoke to Microsoft before making this decision. Mozilla does not employ the blacklist without consulting with the vendor in question first.
As for Firefox, you are basically running a series of stovepipes where it makes sense for each tab to have a separate process... why it has taken so freakin' long for this I don't know, but it's not a new idea
Because it's a large existing codebase and will require invasive changes to work in this model. Also, multi-core processors are a fairly new development, having been around for only a few years. Do you think that back in 2000 anyone would have predicted consumer-grade quad-core CPUs? Would anyone have thought that building a multi-process architecture (ala Chrome) was the right course of action at that time? Software is hard, and retrofitting large codebases to do things they weren't designed for takes a lot of time and engineering effort.
I know there has been interest in a Symbian port, but I don't know if anyone is looking into it. As opposed to something like the N810 (Linux) or Windows Mobile, porting to an entirely new platform is a bit more work, so it can take a significant effort. The iPhone port wouldn't be a huge amount of work, but the distribution would be a non-starter, so it hardly seems worth the effort.
Given Nokia's existing work with Gecko, the N810 platform was an easy place to start. Most of the work so far has focused on the Fennec UI and mobile performance. Ports will happen, the Gecko code is very portable, it just takes some time to finish a port to a new platform. (Or, for WinCE, a platform whose port hasn't worked in a while.)
Slashdot Mirror
This doesn't work with WPO/PGO, which makes it useless for the purposes of this post.
We've looked into this, but the potential for incompatibilities between the CRT headers and the implementation is worrisome. It also hasn't been a real priority to this point because it wasn't a big deal to ship the VC8 CRT alongside Firefox. (And, in fact, until recently, it was pretty necessary because we were building a custom CRT from source so we could patch it to replace the default malloc.)
Do you have a source to back that up? I've never been able to find any information saying that Microsoft compiles their OS libraries with PGO. In fact, in their "Debugging in the (Very) Large" paper, they state that they even turned off frame-pointer omission, since it caused more headaches and didn't give them a noticeable speedup.
http://research.microsoft.com/apps/pubs/default.aspx?id=81176
Raymond Chen disagrees with you:
http://blogs.msdn.com/b/oldnewthing/archive/2005/06/01/423817.aspx
citing:
http://support.microsoft.com/default.aspx?scid=889654
I really wanted this to work, but it doesn't actually work in combination with PGO:
(with the VC2008 32-bit compiler)
$ cl -GL -Fotest.obj -c test.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.30729.01 for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.
test.cpp
(with the VC2008 64-bit linker)
$ link -MACHINE:X86 -LTCG -OUT:test.exe test.obj
Microsoft (R) Incremental Linker Version 9.00.30729.01
Copyright (C) Microsoft Corporation. All rights reserved.
fatal error C1905: Front end and back end not compatible (must target same proce
ssor).
LINK : fatal error LNK1257: code generation failed
Except what BZ just said is that you pretty much need all of those core pieces to start the browser anyway, so splitting them out into separate modules just makes the browser start more slowly.
Also, cross-module optimization does help quite a bit. Microsoft's PGO optimizer is able to do crazy stuff like speculative virtual call inlining, which is a big deal on a large C++ codebase like Mozilla.
Uh, what? Visual C++ produces better optimized code than GCC in almost all cases, especially when you toss PGO into the mix. Firefox runs just fine on most people's systems. There are plenty of pathological cases on people's systems that make it perform poorly: poorly-written extensions, poorly-written antivirus software that hooks into our process, horrible disk fragmentation, etc. The list goes on and on, we've seen all of these things in bug reports from users experiencing poor performance. If you're experiencing poor performance, I'd encourage you to file a bug (you can even link the bug here, and we can take a look). Unless you're running on some ancient hardware it's possible there's a reasonable explanation for your situation that has nothing to do with the compiler we're using.
Your last statement reads like a non-sequitur. What other large open-source project that's comparable to Firefox is producing Windows binaries with GCC that you can compare performance? Unless it's a web browser, comparing performance is like comparing apples and moon rocks.
Yes, but you can get a 32->64 cross-GCC toolchain easily. You can't get one of those from Microsoft, so you're stuck with a maximum of 4GB of address space if you run the 32-bit toolchain on a 64-bit Windows system.
Nope, the issue is still present in Visual C++ 2010. We're planning on switching to that soon, but we either have to work around its lack of support for Windows 2000 / Windows XP pre-SP2, or declare those platforms (and a few million users) unsupported.
This is an advanced setting that we don't expect users to tweak. The default value should work for most people. Here's a decent test: if you have to go to about:config to change a setting, it's not something we want normal users to touch, so talking about usability at that point is a bit silly. The most usable software just does the right thing and doesn't require users to change setttings.
Conveniently Mike is also the Debian Firefox package maintainer, so I'd expect him to apply as much of his work as possible to those packages. That's not to say that Debian's Firefox builds will be as fast as the official Mozilla builds, since Debian has other priorities that may conflict.
Intel does have ICC, but it's kind of expensive, and it's picky in different ways than GCC/VC++, so it means fixing up things across the entire codebase to even get it to work. I was able to build our JavaScript library on OS X with ICC at one point without a huge amount of hassle, and it was a decent speedup back then (but Apple's GCC is ancient). Using it on Windows would probably be a PITA in terms of amount of work to even compare performance.
There were actually several GCC bugs that had to be fixed in order for us to use PGO. Thankfully Mike has a good working relationship with GCC maintainers, and he upstreamed all necessary patches, so everybody wins.
Not really true, we actually built our Linux builds with -Os (optimize for space) up until this change, where we switched to -O3 (optimize for speed) + changed from GCC 4.3 to GCC 4.5 and also enabled profile-guided optimization at the same time. The end result is a pretty nice performance win and not much disk space change.
Windows builds of Firefox didn't get profile-guided optimization until Firefox 3 (2008), so it's only about 3 years behind. Actually I think Firefox 1.0 might have been shipped with PGO on Linux, but I wasn't directly involved in that release so I can't recall. Mike had to chase down a number of bugs in GCC in order to make it work again, which is nice because it benefits all GCC users. GCC developers are using Firefox as a testcase for further optimizations in GCC 4.6 (like LTO), so we should hopefully be able to use those when it's released.
Please feel free to use a competing browser, all of which already include this root cert, to my knowledge.
http://en.wikipedia.org/wiki/Lorentz_National_Park
Firefox codenames are always park names nowadays. This park happens to be in Indonesia, which (AFAIK) is the first country to pass 50% Firefox marketshare.
It's certainly possible, but we do have an extensive set of unit tests and performance tests these days, and we don't land new features without a test suite. Combined with our crash reporting infrastructure, I have pretty high confidence that the quality of the software is improving.
That's great, but there are lots of extensions that do in fact break. If users update to a new version of Firefox and their extensions don't work, or cause their browser to crash or otherwise malfunction (not a theoretical problem), they are not happy users.
The Jetpack project is working to create a stable (but admittedly more limited) API for extensions to use to make it possible to sidestep this problem.
Uh, the primary goal of the Lorentz branch is to merge the out-of-process plugins architecture back to the stable 1.9.2 branch that Firefox 3.6 was released from.
Uh, you can disable the blacklist, if you really want to. It's just enabled by default because we think it's the right thing to do. The vast majority of people do not know they even have these things installed, nevertheless how they would update them or otherwise mitigate their risk.
Also, if you read the original blog post, Mike Shaver spoke to Microsoft before making this decision. Mozilla does not employ the blacklist without consulting with the vendor in question first.
Because it's a large existing codebase and will require invasive changes to work in this model. Also, multi-core processors are a fairly new development, having been around for only a few years. Do you think that back in 2000 anyone would have predicted consumer-grade quad-core CPUs? Would anyone have thought that building a multi-process architecture (ala Chrome) was the right course of action at that time? Software is hard, and retrofitting large codebases to do things they weren't designed for takes a lot of time and engineering effort.
I would question whether "execute the JavaScript in this HTML page your server provided to me" really constitutes "decrypt without authorization".
Windows Mobile builds are fairly close:
http://blog.mozilla.com/blassey/2008/10/11/windows-mobile-update-3-fonts/
I know there has been interest in a Symbian port, but I don't know if anyone is looking into it. As opposed to something like the N810 (Linux) or Windows Mobile, porting to an entirely new platform is a bit more work, so it can take a significant effort. The iPhone port wouldn't be a huge amount of work, but the distribution would be a non-starter, so it hardly seems worth the effort.
Windows Mobile builds are being worked on:
http://blog.mozilla.com/blassey/2008/10/11/windows-mobile-update-3-fonts/
Given Nokia's existing work with Gecko, the N810 platform was an easy place to start. Most of the work so far has focused on the Fennec UI and mobile performance. Ports will happen, the Gecko code is very portable, it just takes some time to finish a port to a new platform. (Or, for WinCE, a platform whose port hasn't worked in a while.)