but the fact that they don't even CONSIDER turning off PGO because of the performance drop means they have no idea how to tune the underlying code without using PGO (and PGO-optimised code will NOT necessarily result in the best possible code for any particular user at all!)
We accept patches.
Except the 64 --> 32 linker cannot use link-time code generation, which is a prerequisite of PGO.
VS2010 ships with the CRT source but not the build system.
I haven't looked at this, but the build system is apparently Very Difficult to recreate.
The 64-bit ARM architecture is ARMv8, which does not exist in any chip at the moment that I'm aware of.
http://stackoverflow.com/questions/1308500/is-iphone-os-64-bit-or-32-bit
http://en.wikipedia.org/wiki/ARMv8#ARM_cores
Because MS stopped providing the build system for the CRT sources.
You'd think that we'd just figure out how to rebuild it ourselves, since we have the old build system. I don't know why we didn't, but that stuff is so ugly, I really don't want to find out.
Apparently this works (which surprised most of us on IRC), but doesn't support PGO, unfortunately (though unsurprisingly).
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
Are you sure it's not invoking a 32-bit linker? Can you show me some output which convinces me that you're right?
"Everything should be made as simple as possible, but not simpler." -- Albert Einstein
