Forgot your password?
typodupeerror

Comment: Re:VS 2005? (Score 1) 753

by luserSPAZ (#38376062) Attached to: Firefox Too Big To Link On 32-bit Windows

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.)

Comment: Re:Not FF's fault (Score 1) 753

by luserSPAZ (#38375936) Attached to: Firefox Too Big To Link On 32-bit Windows

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

Comment: Re:VS 2005? (Score 1) 753

by luserSPAZ (#38375772) Attached to: Firefox Too Big To Link On 32-bit Windows

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

Comment: Re:Trying to do too much (Score 1) 753

by luserSPAZ (#38375682) Attached to: Firefox Too Big To Link On 32-bit Windows

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.

Comment: Re:VS 2005? (Score 1) 753

by luserSPAZ (#38375534) Attached to: Firefox Too Big To Link On 32-bit Windows

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.

Comment: Re:Every improvement is highly needed, FF4 sux (Score 1) 306

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.

Comment: Re:What about distributions (Score 1) 306

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.

Comment: Re:A good summary of Linux on the desktop (Score 1) 306

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.

Comment: Re:A good summary of Linux on the desktop (Score 1) 306

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.

Comment: Re:A good summary of Linux on the desktop (Score 1) 306

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.

Hard work never killed anybody, but why take a chance? -- Charlie McCarthy

Working...