Yeah. It's complicated for us because we do binary hacks on the CRT in order to install our custom allocator, jemalloc, and because MS stopped distributing the build system for the new CRT. But we're working on exactly the suggestions in that SO post.
Well, on the bright side your frustration is a worthy price to pay for the community to hear from someone who actually works on the project and knows what's happening from the inside.
Thanks.:)
But you really don't need to provide maximum PGO optimization of a binary to to achieve acceptable performance.
That's a fair point! But right now, 32-bit Windows builds are all we have. 64-bit Windows builds have been coming Real Soon Now for a while, but I wouldn't hold my breath.
We (try to) focus our efforts where our users are. The vast majority of our users are on 32-bit Windows, so improving their experience -- however we can do that -- is in general a priority above making Firefox run fast on bleeding-edge hardware. (That's not to say that we won't optimize for new hardware now, under the assumption it will become mainstream in the future.)
Yes, we did that (omnijar). But in addition, we merged a number of previously-separate libraries into one giant library, libxul.
I have to admit, it's pretty frustrating to be on a discussion board with someone who insists that I don't understand the project I've worked on for the past few years...
Someone tried this (where test.obj is compiled with 32-bit cl.exe, since there's no 64 --> 32 cl.exe). Here's what we got:
$ 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
I have no idea what happens if I pass/MACHINE:X86, but I imagine it just invokes the 32-bit binary. If you can show that's not true, I know a large number of people who would give you a hug.
There's an official 64-bit version for Linux. We've been shipping that since before I can remember. There are also nightly builds for 64-bit Windows, but we're not shipping these even as Aurora at the moment.
64-bit Linux isn't listed on most of our download pages. I'd argue it should be there, but I'm not in charge.:)
Anyway, here are links to get all the builds we produce:
I think what he was trying to say -- in the meanest possible way -- is that the setting you chose tells VS to use the old compiler and linker. It doesn't switch out the CRT -- it switches out the whole toolchain. So using that setting is no different from where we are now, afaik.
One project I've worked on has single files which cause GCC to take over 6 GB to compile when you compile with -O2. Who's bloated now?
I believe it, but at least you can run GCC as a 64-bit binary and compile 32-bit binaries. That's a heckuva lot better than the situation here with MSVC.
It might seem a bit strange now, but back in the good 'ol days we used to have to break up a project into separate components, just in order to compile it!
Yep, we used to do this. Then we merged them together, because it greatly improves the startup speed of Firefox.
We have a lot of smart people working on this stuff, believe it or not.
That's all very nice, but if you run an obsolete and out of support OS, why would you want to run the latest browser? Those users should be more than happy with Firefox 3.6.
There's talk about switching to VS2010 (and I'm sure that'll be presented as a fait accompli on./ before it's actually decided, just like all our internal discussions are).
But 3.6 won't be supported with security updates forever, so we'd really be abandoning those users. Just because your OS is insecure doesn't mean we should give up on providing you with a secure browser. Maybe we should abandon them, but it doesn't necessarily follow.
Then, there's what appears to be the blatantly incorrect statement of 64-bit windows offering 4GB of address space - shouldn't that be way bigger, or am I stupid?
64-bit Windows lets you run 32-bit applications (such as the linker in question) with 4gb of address space. On 32-bit Windows, the OS uses 2GB of address space for itself, or 1GB if you set the/3GB flag on boot.
There is no MSVC x86-32 compiler which runs as an x86-64 application, unfortunately. This is what you'd need to get a larger-than-4GB address space.
Summary should read: Visual Studio is too teh suck to link Firefox on Windows with PGO.
Firefox links just fine with VS, if you don't use PGO. The problem is that Visual Studio's PGO routine loads all our object files in at once, then uses a ton of memory on top of that. And the linker for 32-bit programs is itself a 32-bit program; if there were a 64-bit x86-32 linker, we wouldn't have this problem. But so far, Microsoft has not given any indication that they will release a 64-bit to x86-32 cross-compiler.
Note that Chrome doesn't build with PGO at all, last time I checked.
Note: Visual Studio 2010 seems to help a bit, but not much. We use VS 2005 because it's the last version whose CRT supports Windows 2000 and Windows XP before Service Pack 2.
You [should] incrememt your major version 4.x.x.x when you release new major features
We include what I'd consider to be major new features in almost every release. Maybe you disagree about what should be considered "major". The point of the numbers is that it prevents us from bikeshedding about these minutia every six weeks and lets us concentrate on what's important.
possibly one can make the argument ALL projects BUT chrome and ff use something in this light
I suppose you could make that argument, but it wouldn't be a very good one. Linux went from version 2.6 to version 3.0 with, in Linus's words, "no special landmark features or incompatibilities related to the version number change".
I wish we could stop arguing about the version numbers. It's the least important part of Firefox. You don't like it. We heard you. I'm sorry. Can we just let it go already?
My recommendation to you, putting it bluntly is to fix 90% of your bugs before deploying any new version
We've never done this. In fact, I'd wager that no large software project has ever, or will ever, meet this goal. It's simply not possible, especially as fixing bugs often introduces new bugs.
I think a lot of the frustration with what we're doing stems from armchair quarterbacking like this. "If only they weren't so stupid as to see what I see as obvious!" I appreciate the desire to help improve our processes. But successful software engineering at scale (not to mention speed) is not as simple as following a short list of rules.
You're much more likely to get the outcome you want -- a version of Firefox without the bugs you care about -- by using our pre-release versions and filing bugs than you are by playing Monday-morning release manager on/..
if they really wanted the individual to use DNT then they would have a big button saying "click me if you don't want to be tracked" when you installed or upgraded. Ask your great grandmother if she knows how to turn off tracking in Firefox and I bet she doesn't know how.
Sure, I don't think the long-term plan is to hide DNT in the preferences pane like it is now. But before we make a big deal of it, it needs wider adoption on the advertisers' end. We're not going to make a Big Red Button unless it does something...
Not that I think it matters outside of principle, because I don't expect Do Not Track to be honored unless it's enforced by law.
The hope is to get it written into law. But of course you can't make a law which effectively says "anyone who runs Firefox, which just happens to have DNT enabled by default, can't be tracked." That's why DNT has to be opt-in.
Plus, these bug fixes are all esoteric crap. I'd like to see fixes for some of the bugs that affect me every browsing session, such as:
1. The whole app becomes unresponsive when any tab is waiting for a response from a host.
If this were a widespread problem, then nobody would be able to middle-click on a link to open it in a new tab and then use the browser while that tab loads. This works for most of us. What's likely happening isn't that Firefox freezes while waiting for a response from a host, but that it hangs while running JS from a site. This is a known problem, and it's unfortunately incredibly complicated to fix. We're working on it, and we have been for years.
If you think the problem doesn't have to do with running JS, I'd love it if you filed a bug so we could investigate. (cc me, jlebar) If we can reproduce this as you describe, a lot of people would be very interested in fixing it.
2. When the context menu is drawn close to the right edge of the screen, it results in automatic selection of the option drawn under the mouse. (Since about 5.0, fixed and regressed at least once.)
I don't see this on my Linux box, but this sounds like a bug. If you cc me, I'll make sure the right people see it.
3. When you save content from a page, such as an image, it downloads the content again instead of simply copying it from the cache. (Since about 3.0, fixed and regressed at least once.)
I'm not sure this counts as a non-"esoteric" bug. Just because it affects you every time you use the browser doesn't mean that it's necessarily a high-priority bug. And understand that the cache is pretty complicated, with a variety of obscure HTTP-related rules it has to follow. We do accept patches, though.:)
You may want to check that you're running the latest version of Flash. There's only so much we can do when Flash screws up. Plugins are hard; let's go shopping.
But you're welcome to file a bug (cc me, jlebar) and I'll have a look.
Slashdot Mirror
Bingo. And, of course, link-time code generation is essential for PGO.
Yeah. It's complicated for us because we do binary hacks on the CRT in order to install our custom allocator, jemalloc, and because MS stopped distributing the build system for the new CRT. But we're working on exactly the suggestions in that SO post.
Well, on the bright side your frustration is a worthy price to pay for the community to hear from someone who actually works on the project and knows what's happening from the inside.
Thanks. :)
But you really don't need to provide maximum PGO optimization of a binary to to achieve acceptable performance.
That's a fair point! But right now, 32-bit Windows builds are all we have. 64-bit Windows builds have been coming Real Soon Now for a while, but I wouldn't hold my breath.
We (try to) focus our efforts where our users are. The vast majority of our users are on 32-bit Windows, so improving their experience -- however we can do that -- is in general a priority above making Firefox run fast on bleeding-edge hardware. (That's not to say that we won't optimize for new hardware now, under the assumption it will become mainstream in the future.)
Yes, we did that (omnijar). But in addition, we merged a number of previously-separate libraries into one giant library, libxul.
I have to admit, it's pretty frustrating to be on a discussion board with someone who insists that I don't understand the project I've worked on for the past few years...
Someone tried this (where test.obj is compiled with 32-bit cl.exe, since there's no 64 --> 32 cl.exe). Here's what we got:
$ 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
We binary patch the CRT in order to insert our own memory allocator. This complicates things greatly.
But if you have a clue that we don't, we gladly accept patches.
According to http://msdn.microsoft.com/en-us/library/x4d2c09s(v=VS.100).aspx , there's no x64 --> x86 cross-compiler.
I have no idea what happens if I pass /MACHINE:X86, but I imagine it just invokes the 32-bit binary. If you can show that's not true, I know a large number of people who would give you a hug.
Are you sure it's not invoking a 32-bit linker? Can you show me some output which convinces me that you're right?
Because the 64-bit toolchain does not support producing 32-bit binaries. It is not a cross-compiler.
I am a Mozilla guy.
There's an official 64-bit version for Linux. We've been shipping that since before I can remember. There are also nightly builds for 64-bit Windows, but we're not shipping these even as Aurora at the moment.
64-bit Linux isn't listed on most of our download pages. I'd argue it should be there, but I'm not in charge. :)
Anyway, here are links to get all the builds we produce:
Nightly builds: http://nightly.mozilla.org/ (has win-64 builds)
Aurora builds: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-aurora/
Beta builds: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/9.0b6-candidates/build1/ (I don't know the directory for the latest beta build, unfortunately, so you'll have to update this URL each time you go looking.)
Release builds: http://releases.mozilla.org/pub/mozilla.org/firefox/releases/latest/
I think what he was trying to say -- in the meanest possible way -- is that the setting you chose tells VS to use the old compiler and linker. It doesn't switch out the CRT -- it switches out the whole toolchain. So using that setting is no different from where we are now, afaik.
Point taken.
But FYI: We use VS2005 because it's the last version whose CRT supports Windows XP before SP2 and Windows 2000.
We would love to upgrade, and are in fact devoting a lot of engineering time towards figuring out if we can upgrade while maintaining compatibility.
One project I've worked on has single files which cause GCC to take over 6 GB to compile when you compile with -O2. Who's bloated now?
I believe it, but at least you can run GCC as a 64-bit binary and compile 32-bit binaries. That's a heckuva lot better than the situation here with MSVC.
It might seem a bit strange now, but back in the good 'ol days we used to have to break up a project into separate components, just in order to compile it!
Yep, we used to do this. Then we merged them together, because it greatly improves the startup speed of Firefox.
We have a lot of smart people working on this stuff, believe it or not.
That's all very nice, but if you run an obsolete and out of support OS, why would you want to run the latest browser? Those users should be more than happy with Firefox 3.6.
There's talk about switching to VS2010 (and I'm sure that'll be presented as a fait accompli on ./ before it's actually decided, just like all our internal discussions are).
But 3.6 won't be supported with security updates forever, so we'd really be abandoning those users. Just because your OS is insecure doesn't mean we should give up on providing you with a secure browser. Maybe we should abandon them, but it doesn't necessarily follow.
Chrome doesn't even try to build with PGO, last time I checked.
http://groups.google.com/a/chromium.org/group/chromium-dev/browse_thread/thread/533e94237691e2f6
Then, there's what appears to be the blatantly incorrect statement of 64-bit windows offering 4GB of address space - shouldn't that be way bigger, or am I stupid?
64-bit Windows lets you run 32-bit applications (such as the linker in question) with 4gb of address space. On 32-bit Windows, the OS uses 2GB of address space for itself, or 1GB if you set the /3GB flag on boot.
There is no MSVC x86-32 compiler which runs as an x86-64 application, unfortunately. This is what you'd need to get a larger-than-4GB address space.
No, the long-term solution involves freezing the 32-bit version as an eternal final-state "stable" branch, and moving on to the 64-bit world.
Um.
Some 90% of our users are on 32-bit Windows. Just because *you're* not one of them doesn't mean that they don't matter.
It's nice that you don't expect us to support your aging XP boxes, but I think you'd find you're the minority in this respect.
(Also, all phones are 32-bit, and will be for at least the next few years.)
Summary should read: Visual Studio is too teh suck to link Firefox on Windows with PGO.
Firefox links just fine with VS, if you don't use PGO. The problem is that Visual Studio's PGO routine loads all our object files in at once, then uses a ton of memory on top of that. And the linker for 32-bit programs is itself a 32-bit program; if there were a 64-bit x86-32 linker, we wouldn't have this problem. But so far, Microsoft has not given any indication that they will release a 64-bit to x86-32 cross-compiler.
Note that Chrome doesn't build with PGO at all, last time I checked.
http://groups.google.com/a/chromium.org/group/chromium-dev/browse_thread/thread/533e94237691e2f6
Note: Visual Studio 2010 seems to help a bit, but not much. We use VS 2005 because it's the last version whose CRT supports Windows 2000 and Windows XP before Service Pack 2.
You [should] incrememt your major version 4.x.x.x when you release new major features
We include what I'd consider to be major new features in almost every release. Maybe you disagree about what should be considered "major". The point of the numbers is that it prevents us from bikeshedding about these minutia every six weeks and lets us concentrate on what's important.
possibly one can make the argument ALL projects BUT chrome and ff use something in this light
I suppose you could make that argument, but it wouldn't be a very good one. Linux went from version 2.6 to version 3.0 with, in Linus's words, "no special landmark features or incompatibilities related to the version number change".
I wish we could stop arguing about the version numbers. It's the least important part of Firefox. You don't like it. We heard you. I'm sorry. Can we just let it go already?
My recommendation to you, putting it bluntly is to fix 90% of your bugs before deploying any new version
We've never done this. In fact, I'd wager that no large software project has ever, or will ever, meet this goal. It's simply not possible, especially as fixing bugs often introduces new bugs.
I think a lot of the frustration with what we're doing stems from armchair quarterbacking like this. "If only they weren't so stupid as to see what I see as obvious!" I appreciate the desire to help improve our processes. But successful software engineering at scale (not to mention speed) is not as simple as following a short list of rules.
You're much more likely to get the outcome you want -- a version of Firefox without the bugs you care about -- by using our pre-release versions and filing bugs than you are by playing Monday-morning release manager on /..
if they really wanted the individual to use DNT then they would have a big button saying "click me if you don't want to be tracked" when you installed or upgraded. Ask your great grandmother if she knows how to turn off tracking in Firefox and I bet she doesn't know how.
Sure, I don't think the long-term plan is to hide DNT in the preferences pane like it is now. But before we make a big deal of it, it needs wider adoption on the advertisers' end. We're not going to make a Big Red Button unless it does something...
Not that I think it matters outside of principle, because I don't expect Do Not Track to be honored unless it's enforced by law.
The hope is to get it written into law. But of course you can't make a law which effectively says "anyone who runs Firefox, which just happens to have DNT enabled by default, can't be tracked." That's why DNT has to be opt-in.
Plus, these bug fixes are all esoteric crap. I'd like to see fixes for some of the bugs that affect me every browsing session, such as:
1. The whole app becomes unresponsive when any tab is waiting for a response from a host.
If this were a widespread problem, then nobody would be able to middle-click on a link to open it in a new tab and then use the browser while that tab loads. This works for most of us. What's likely happening isn't that Firefox freezes while waiting for a response from a host, but that it hangs while running JS from a site. This is a known problem, and it's unfortunately incredibly complicated to fix. We're working on it, and we have been for years.
If you think the problem doesn't have to do with running JS, I'd love it if you filed a bug so we could investigate. (cc me, jlebar) If we can reproduce this as you describe, a lot of people would be very interested in fixing it.
2. When the context menu is drawn close to the right edge of the screen, it results in automatic selection of the option drawn under the mouse. (Since about 5.0, fixed and regressed at least once.)
I don't see this on my Linux box, but this sounds like a bug. If you cc me, I'll make sure the right people see it.
3. When you save content from a page, such as an image, it downloads the content again instead of simply copying it from the cache. (Since about 3.0, fixed and regressed at least once.)
I'm not sure this counts as a non-"esoteric" bug. Just because it affects you every time you use the browser doesn't mean that it's necessarily a high-priority bug. And understand that the cache is pretty complicated, with a variety of obscure HTTP-related rules it has to follow. We do accept patches, though. :)
http://bugzilla.mozilla.org/
You may want to check that you're running the latest version of Flash. There's only so much we can do when Flash screws up. Plugins are hard; let's go shopping.
But you're welcome to file a bug (cc me, jlebar) and I'll have a look.
http://bugzilla.mozilla.org/