Slashdot Mirror
Firefox Too Big To Link On 32-bit Windows
An anonymous reader writes "Firefox has gotten so large that it cannot be compiled with PGO on a 32-bit linker anymore, due to the virtual memory limitation of 3 GB. This problem had happened last year with 2 GB, which was worked around by adding a/3GB switch to the Windows build servers. Now the problem is back, and things aren't quite that simple anymore."
This only affects the inbound branch, but from the looks of it new code is no longer being accepted until they can trim things from the build to make it work again. The long term solution is to build the 32-bit binaries on a 64-bit system.
And this would be the point where the fact that the Firefox devs have been trying to do too much with a "browser" becomes beyond blatantly obvious. Firefox team: get your stuff together or you will die a slow death of attrition.
E.g. where's the status bar in recent firefoxes?
Size of the Firefox codebase is one factor of course, but the amount of RAM needed by Visual Studio to compile code with all optimizations turned on (especially PGO, which is extra RAM-intensive at the compilation stage) is also a major factor. Notice that this only happens in the 32-bit Visual Studio builds specifically.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
Firefox devs requesting immediate RAM bailout.
It doesn't mean much now, it's built for the future.
1080P video has nothing to do with the bitness of your operating system.
I want to delete my account but Slashdot doesn't allow it.
It takes 16GB to compile Android.
"When information is power, privacy is freedom" - Jah-Wren Ryel
Some of us actually think that using a web browser is more important than compiling a web browser.
Seriously. My resource usage rarely goes about 1 GB with multiple applications open. These days, the hard drive is a far bigger bottle neck than RAM. Well, unless you're compiling Firefox it appears.
You're two major versions behind, that's the problem.
It would build just fine in 2010.
Adobe Acrobat still has no port for 64-bit Linux. At the rate things are going, I'm becoming skeptical they ever will.
And while I know there are plenty of other PDF readers out there, there aren't any other than Acrobat that support layers that can be turned on or off at runtime (which have been supported by Adobe Acrobat since, I believe, v6 or so).
File under 'M' for 'Manic ranting'
640k? don't you mean 64k? A C64 should be enough machine for everyone
Life is pain. Anyone who says differently is selling something.
The long term solution is to build the 32-bit binaries on a 64-bit system.
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.
Yes, most people still run 32-bit hardware. And yes, most likely someone would maintain 32-bit backports of FireFox for years to come. But the Mozilla foundation needs to direct their efforts on the reality of the present, not cripple themselves in the interests of backward compatibility.
FWIW, I write this as someone who would primarily use that 32-bit backport at the moment. But I don't expect Mozilla to support my aging XP boxen any more than I expect them to support the Timex Sinclair 1000 or Atari ST I have stashed in the bottom of a closet somewhere.
"First tests indicate that, for example, moving parts of the WebGL implementation to one side could save 300 KB. In a test run, the newer version of Visual Studio required less memory than the one that was previously used, and 64-bit Windows offers 4 GB of address space."
So, first of all, saving 300KB on WebGL seems like a pittance. 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?
Sheesh. I can remember when we had to keep the size of the completed application small enough to fit on a 360K bootable floppy.
He was just trying to say that 1080p gives him a big endian.
No, no it doesn't, but I'm impressed, turning this against MS instead of complaining about the real culprit, kudos.
I guess that America's obesity problem has extended to software.
To offset political mods, replace Flamebait with Insightful.
Speaking of someone who regularly does large C++ builds, MSVS is nowhere near a bad culprit here. The linker is essentially doing code generation -- link time optimization. Why? Because LTO gives a substantial performance benefit. The profile-guided optimization mentioned in the summary gets them about 10% over even doing non-profile-guided LTO.
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?
(Takeaway: broadly speaking, MSVS is actually very competitive, at least compared with GCC, when comparing similar settings.)
It sounds like a build-tool chain problem, not an issue with the eventual binary produced for Firefox.
Why not just run the 64-bit tools on a 64-bit platform and have them output 32-bit code, the same as can be done by virtually any cross-platform compiler system. I can't imagine worrying about the fact that I can't run the builds on an outdated 32-bit OS as long as I can produce the binaries for such platforms.
I shudder to think what it would have been like to develop for some of the military communications systems I worked on for my first job if we had to run the compilers on that pathetically slow mil-spec Sperry AN-UYK system (magnetic core memory -- talk about slowing down the CPU! But it's radiation hard!) We only tested on the Sperry -- all builds and editing were done on a VAX.
In modern terms, could you imagine having to run your editors and compilers on an iDevice instead of OS/X?
I do not fail; I succeed at finding out what does not work.
Adobe Acrobat still has no port for 64-bit Linux. At the rate things are going, I'm becoming skeptical they ever will.
And while I know there are plenty of other PDF readers out there, there aren't any other than Acrobat that support layers that can be turned on or off at runtime (which have been supported by Adobe Acrobat since, I believe, v6 or so).
If you ever wondered what multilib was for, now you know! And knowing's half the battle.
There's something seriously wrong when a browser hits a 3GB linker limit.
Imho, the only sane solution is to delete most of the code. It's been crap for years anyway.
Did you ever try compiling Chromium before you made that statement?
You're right. As anyone who's read C++ FQA by Yossi Kreinin might guess, C++ itself could be one of the culprits.
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.
Of course... but on slackware, multilib is an unsupported extension, and slackbuilds are not guaranteed to compile or install correctly on systems that have multilib installed.
File under 'M' for 'Manic ranting'
Firefox has been getting lighter and lighter (at least in RAM use) since v4 so I don't get how the update made it slower.
"When information is power, privacy is freedom" - Jah-Wren Ryel
Comment removed based on user account deletion
"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?"
emm ... those single project files?
More like 640GB these days.
The determined Real Programmer can write Fortran programs in any language.
Let's guess Firefox for Windows is about the size of Google Chrome for Windows because it does about as much. But an HTML5 browser almost has to be an operating system by itself, containing a GUI layout engine (for CSS), a JIT-compiling virtual machine (for JavaScript), a window manager (tabbed document interface), a memory manager (RAM and disk caches), and a task scheduler (for scripts in one tab and scripts in another tab). Is Chrome a plug-in, a single application, or an operating system?
I don't know if the blame is so easy to place. It is kind of like watching one fat guy explain to another why they can't sit on the same bench.
The software product I work on also used PGO at one point. Our software is roughly 2-3 million lines of C++ code, and links with 40-50 external libraries. Under Window XP, VS2008 could not link our product with PGO turned on.
Before you complain about the bloat of FF, please understand that PGO uses many many times more memory than just compiling a regular release build. This is a Visual Studio linker problem, not FF problem.
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.
I still play 8-bit video games, and the memory card adapter I use to play them has an 8-bit OS.
Back in my day we didn't have gigabyte memory and disk space was at a premium.
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!
This is where your interface and API design skills came in handy. If you could partition some piece of the project off into it's own DLL, you could effectively break up the project into smaller pieces that could be individually compiled.
That's where the name DLL came from originally: "Dynamic link library". You didn't need to have all the code read into memory when you first executed the application - less commonly used features wouldn't get loaded until they were actually asked for.
It's not like it is nowadays, where you actually need all the code to be available all the time. "Rich user experience" they call it.
I suppose it's just the future overtakin' us. Them good old days is gone forever.
Only GB?
To offset political mods, replace Flamebait with Insightful.
Like said here before, just compile it on a 64-bit system. Why stick on 32-bit?
there aren't any other than Acrobat that support layers that can be turned on or off at runtime (which have been supported by Adobe Acrobat since, I believe, v6 or so).
Why would you want to do that? I've never seen this feature used (I'm not saying it doesn't have a use, just that I can't conceive of one).
"First they came for the slanderers and i said nothing."
What about fixing TF compiler/linker?
Stupidity is an equal opportunity striker.
Fellow slashdotter Bill Dog
Can we turn this into a competitive sport? Please?
"Lack of speed can be overcome. In the worst case by patience." --Znork
Requirements to run Firefox and resources required to compile Firefox aren't the same thing at all. Your attempt to conflate the two suggests you're stupid and don't know what you're talking about.
I'd say it nicer but then I'd risk not hitting +5 Funny.
"Oh no... he found the
I was merely illustrating how I've gone from being ahead of the tech curve to years behind. However I think you'll find that bits and byte order do count when writing a compression codec. In short; you're wrong!
You didn't specify a compression codec, you specified a video resolution, which is indeed completely irrelevant to the bit-count of your processor.
In short, you're wrong. Please stop.
Having trouble comprehending computer binary sequence, and word size transmissions?
Hint: It was a joke about 1080p and data transfer through the data bus.
-- This space for lease, low setup fee, inquire within!
I say we take off and nuke the site from orbit. It's the only way to be sure.
Hey, know what else is too big to link with PGO on 32-bit Windows? Chrome! http://code.google.com/p/chromium/issues/detail?id=21932
yes, it true... but that doesnt mean that it doesnt work...
but if you want to make sure, installl a slackware64, do a mkdir /chroot and install in there a normal slackware.. then do some mount --bind for proc, sys, tmp and dev and do a chroot on that directory to get a full 32bit enviorment.... if you need to use X, export the DISPLAY and copy the xauth cookie for the 32bit apps connect to the 64bit X11 server... problem solved! :)
Higuita
So not only is Chrome faster and uses less resources, it also has fewer compile time optimisations? Sounds like Mozilla need to step up their game a bit
I would have thought the answer was obvious... because I have PDF's that utilize the feature for customizing what features of the document that one wishes to print. It is most practical for maps, but has a few other applications as well.
File under 'M' for 'Manic ranting'
No, it has nothing to do with running Firefox. It has everything to do with running Visual Studio's linker.
This matters only to Firefox developers.
Not that they shouldn't care, mind you, as that is some seriously monolithic code. But it won't make any difference to Joe Sixpack.
John
You mean some people still run Firefox?
Templates out the wazoo. Don't blame me, I didn't design it. (Or write most of it; I'm only tangentially related nowadays.)
Point being, there are features which, while valuable, are costly. I blame our source, our fondness of templates, and the compilation consequences that templates almost necessitate way more than I blame GCC for having a poor implementation of templates.
But similarly, going "stupid bloaty MSVC, it shouldn't support this feature which can give double-digit percentage speedup because it takes a lot of memory" is stupid. LTO is costly -- period. It's just very worth it.
Old gripe about window-to-the-whole-world is old. And we're talking about builds, not in-use resource consumption... where it behaves just like every other browser.
You mean some people still run a 32-bit OS?
Not only that, but apparently Windows cannot use PAE - Physical Address Extension to address more than 4GB (according to the WP entry, PAE is supported, but the 4GB limit is still enforced - due to some obscure licensing problems).
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
I agree with that, and I don't want to dispute that particular benefit of GCC (or more broadly, open source).
But saying "I should have a 64->32 linker so that it can use more than 4 GB of memory" is a lot different from saying "MSVC is bloated if linking takes 4 GB". :-)
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.
How about not using shitware?
Support my political activism on Patreon.
until the shit overflowed the container?
The reason building on a 64 bit machine works is because the 64 bit OS can run a 32 bit application while giving it 4gb of space to work in. But they are at 3GB now, how long before even THAT isn't enough? Note that the finished exe needs FAR less space to run in (thank god!).
Why not? You can tell just by looking at the version number that Firefox is almost as advanced as IE and Chrome. *rolls eyes*
As for memory, there was an article a while back I believe, explaining that it takes a million gigs of RAM (I'm exaggerating) to compile/link an Android app, and I still don't get it. What do you have to store in memory aside from a symbol table?
Yes... they will work... most of the time in fact. But when they don't, there is absolutely no support offered.
I had thought about doing a 32bit chroot on a 64-bit system before, but am unsure how I would properly connect the 32-bit system to the 64-bit one for X apps. You've described basically what needs to be done, but I would really need a considerably more detailed step-by-step explanation. I didn't have much luck finding one the last time I gave this any thought.
It's really just as annoying as hell that Adobe has evidently stopped supporting Acrobat for Linux after v9... but oh well... what can you do, right?
File under 'M' for 'Manic ranting'
that operating system is compiled one component at a time.
to be honest you can build it on a 4G system, it will just take a long time and you won't be able to do a parallel build without digging deep into swap.
“Common sense is not so common.” — Voltaire
I don't think that is correct. Slackware comes multilib capable. So it quite easy to make it multilib and everything works just fine with it. No where have i ever seen a "use at your own risk, this can break 64bit apps". Not only that, but it doesn't. I have this installed on 3 different desktops and 2 laptops without issues.
If information wants to be free, why does my internet connection cost so much?
As much as I want to believe what you say (and I think it until I break it apart in my head), it's not quite as simple as rendering something to the screen.
That's part is a specific subsection of code within the browser. The rest is array indexes, plugin coordinations, and a bunch of other things all happening at the same time. While I'm not a browser coder, I understand the complexities. That being said, once a browser goes over 3G memory use, you start scratching your head.
-- This space for lease, low setup fee, inquire within!
Or just, yknow, stop running a bloated resource hog of an INTERNET BROWSER.
Read TFA agin. Oh, I know this is /.
So read the summary again.
it cannot be compiled with PGO on a 32-bit linker anymore, due to the virtual memory limitation of 3 GB
It is the compiler which is having ressource problems. The profile-guided optimiser needs more than 3GB to be able to do its optimisations. And apparently, the Windows its running on can't do PAE to use more than 3GB neither.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
This article isn't about how much RAM Firefox needs when *running*, it's talking about how much RAM Microsoft Visual Studio uses when *compiling* (actually, linking) Firefox.
Do you even know anything about perl? -- AC Replying to Tom Christiansen post.
In this particular case, it's actually doing link-time code generation for optimization purposes.
And how is this connected to the amount of memory required to link Firefox?
It's insane that a compiler, any compiler, needs 3+GB to "just" link a whatever big number of object files into an executable.
It's insane that a single piece of software cannot be linked in a 32bit environment. That is, a Windows32 environment, as it can be linked into a 32bit Linux environment.
How much insanity nowadays!
Sent as ripples into the electromagnetic field. No single photon has been harmed in the process.
Exactly! Those of us using a REAL operating system like Windows 3.0 never have to worry about mixing 64-bit and 32-bit environments! ;)
--TheOrangeSquid Is it any wonder things seem so awry? We swim in a sea of confusion and don't have to think to survive
So the codebase is once more becoming bloated, in fact so bloated that they cant compile it in 3 gigabytes of address space, and their long term solution is to compile it in an enrivonment that allows more address space??? Instead of, maybe, getting the code base down to a non bloaty non total total disaster area?? Looks like this is one more confirmation that Mozilla have lost the plot with Firefox.
It is multilib capable, but multilib is still an unsupported extension.
It doesn't break any standard slackware apps, but it can break some slackbuilds... For what it's worth, I've even seen this happen several times. Their official response on the matter when I sought technical help about it was that multilib is not supported by the slackbuild process, and the recommendation was to not use multilib if I wanted to have reliable slackbuilds.
File under 'M' for 'Manic ranting'
How big are the single files?
I wonder how much of that can be modularized a little better.
Yes, almost every does use JavaScript, but couldn't components such as JS be included as a module from the main engine?
He was gonna answer that question but he took and arrow to the knee.
Eight bits, I tell you.
And we pushed the registers ourselves!
Lazy coders ...
-- Tigger warning: This post may contain tiggers! --
People keep saying stuff like this, but in my experience it's just not true. Right now I'm clocking Firefox at 596,900 kB commit + 75,000 kB for the plugin-container.
I have never seen it above 1 GB, although I've only sampled maybe once/month.
Are you using another measuring technique than I, or are you just trolling?
What?
This isn't about RUNNING Firefox, but compiling/linking it. I guarantee Skyrim takes more than 500GB under that context.
However, yes, Firefox has become exceedingly bloated.
It is more productive to voice thoughtful opinions (reply) than to judge (moderate) others.
Not only, but most distribution of Linux (although not the next Ubuntu, apparently) do support PAE on their 32bits variants, and can thus use more than 4GB virtual space.
So GCC *could* use 6GB on a 32bits machine, even if its more than 2GB.
Whereas Visual Studio is stuck on 3GB. So you cannot compile with it on a 32bits machine.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
The sub 10 MB download for windows is a stub to install over the 'net. It's not the product.
-- This space for lease, low setup fee, inquire within!
Folks are crawling all over each other to show how ignorant they are. "I ditched firefox for Chrome cause it's lighter!" only to ignore the fact that Chrome also has the same problem with the PGO thing running out of RAM so they don't even bother with trying those optimizations anymore. "Geez Firefox needs more RAM than the kernel to compile? Something's wrong!" Yes if the Linux kernel was built with PGO on VS 32-bit it probably would run out of RAM there too. Then there's the guy that claims this PGO problem is evidence that the Firefox devs need to go back to remedial school. I'm sure he could do it far better (and avoid the PGO linking optimization running out of memory too!).
Hilarious reading. At least I choose to laugh rather than cry at people's inability to read and understand the issues here.
> 1) What the hell are you doing with your code to be
> that large?
How large? It's a few million lines of C++ code, just like every other browser. What it's doing is implementing all the stuff people want to do on the web.
> 2) What the fuck is your linker doing to do that?
Please read up on link-time code generation.
> 3) Why the hell didn't you see this coming and
> prune LONG before you hit the 3Gb limit if you
> already hit the 2Gb limit once already?
This is an excellent question that I too am asking.
> 4) What's the problem with compiling on 64-bit
> computers only,
None, except updating a large build farm from 32-bit to 64-bit can't happen overnight. Needs some staging, testing, etc.
> You're honestly telling me that Firefox is more
> complicated and needs more memory to compile
> than, say, LibreOffice?
Have you tried to compile LibreOffice with LTO and PGO turned on?
> The Linux kernel?
Quite possibly. The kernel is C, not C++; C++ is a lot more of a pain for compilers to deal with.
The whole point of LTO is that you optimize your entire binary as a single object, no matter how your code is structured. It requires more memory, but can produce faster code because the compiler is able to make optimizations it can't make otherwise.
Whether that's "crappy" is a matter of your priorities, of course. 10-25% performance improvement tends to be a high priority for web browsers, though perhaps not for KDE or LibreOffice.
You do realize that Chrome had this same issue a few years back, right?
Maybe you need to do some reading about how to engineer software and about the specific compiler options being used here and why they might cause a lot of memory usage?
Interesting question. I'll get back to you.
(They'll be large, but not tremendously large. The real problem arises because of a combination of the size and lots of template use.)
MacOS 10.5-6 are 64bit if you're hardware supports it (so, only 32bit on PPC G4 and Intel Core Duo). OS 10.7 is 64bit only.
I'm starting to think GNU is the problem with "GNU/Linux" these days.
From an address space POV, 64-bits vs 32-bits is 4294967296 times greater. The short answer is, not in your lifetime will it overflow the container. That said PGO looks to have reached the limit of it's current incarnation. Eventually it will just get too slow to be workable. If it really is valuable as an optimization tool, MS will have to fix it, true enough.
I run 32-bit Linux with PAE, and the 4GB/process limit has "restrained" Firefox a few times.
Funny. Sad if I didn't have 8GB (it's an old T61 so that's all I can fit), but still funny.
"This post is an artistic work of fiction and falsehood. Only a fool would take anything posted here as fact."
Except Chrome uses more resources, in my experience. And may or may not be faster.
Though I'm looking at it on Mac, not on Windows, where they're just compiled completely differently (e.g. Chrome is 32-bit while Firefox is 64-bit, etc).
Since i do install quite a few things via slackbuilds, do you have a list of things that don't work?
If information wants to be free, why does my internet connection cost so much?
Quick, spread some FUD!
Near as I can tell, there is no advantage to running 64-bit unless you plan to have installed (and to use) significantly more than 4GB of RAM. At or even somewhat above that amount of installed RAM, you are at a disadvantage as everything will use more memory in 64-bit mode than in 32-bit. I have run 32-bit Linux on every laptop I've had in the last several years, 64-bit support or not.
64bit Microprocessors were new in 1991...I hope you're hardware isn't that old.
I'm starting to think GNU is the problem with "GNU/Linux" these days.
My ASUS EEE netbook is 32-bit and only 1G RAM. The push for smaller and smaller machines (in the physical sense) is still resulting in small machines in the configuration sense (32 bits or less, 1 GB or less).
These small machines, of course, must accept lesser functionality to remain small. If that means a meaner leaner Firefox-lite, then so be it. But don't be surprised if you find me running the lite version on my big Xeon powered 2 socket 10 core 20 thread 48GB Xfce based desktop that runs in 64-bit mode. I still code in C and use text consoles, too. I can always link with libbloat if I ever need to make my programs look big.
now we need to go OSS in diesel cars
I wonder if you could borrow ideas from operating systems like micro-kernels (e.g. L4) or software isolated processes (e.g. Sigularity)? It's not a project that I have the time or experience for, but I'd be interested to see the results if someone else tried.
Even more unfortunate that 3/4 of the whole discussion will be "Re: Wow" as everybody dogpiles unrelated replies onto the frist post, because we all know that for mod points, it's not what you post but where you post it.
Why would you choose slackware and then seek technical help? Are you sure you're their target user?
Thanks, but that was not my intention at all -- I have nothing against Microsoft.
./ fad, I predict in time it might become more fashionable than MS-bashing here.
It seems to me that seeing MS-bashing in every post looks like some kind of new
Every end has half a stick.
1/2. Link time Profile Guided Optimization. Eats memory like crazy, but nets you a big performance boost on the resulting code.
3. Dunno.
4. Problem is that the 64-bit linker won't output a 32-bit executable.
upon the advice of my lawyer, i have no sig at this time
If you are hardware that supports it, I'd be more worried about you being Skynet. And that Skynet runs OS X.
Yes, but how much time did Skyrim claimed from your own lifetime, see there is always a drawback
same result though, MS sucks, gcc wins.
Praise Saint IGNUcius!
Seems ironic that the FF team is using stuff from seven years and two major versions ago while at the same time bemoaning that anybody might want to keep a version of Firefox for more then 6 weeks
Installing a new version of Firefox is quite trivial :
- it's opensource, meaning that it's available for free
- since version 4, all new version are only minor improvement. (technically, it should be some subversions of 3.7.x, had they kept the same versionning scheme as before). No big architectural change since then. Version 9 might not be identical to version 4, but no big jump in between. Each new release brings only minor changes.
Installing a new version of Vistual Studio is not :
- it's commercial, so it costs money to get it.
- Among critical feature changes: it completely drops suipport for some older OSes. So if Mozilla moves to a newer compiler, they need to drop support for some chunk of their userbase. How big this chunk is will influence this decision.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
I used to think like that, but now I'm using Window ME and let me tell you, I've seen the light!
What's VC++ doing for Firefox that can't be done any other way?
YUP, indeed ?
Apparently the latest version of GCC (4.6.2) can also do Link-Time Optimisations and Profile-Guided Optimisations. This version which is also available as part of the ming toolchain, and it is even possible to cross compile from Linux 64 host to Win32 target with Ming.
Is the performance difference between a VS2005-compiled version and a ming-gcc 4.6.2 compiled one *that* much big?!
Or is some feature of VS critical (like direct support for COM objects in the compiler, instead of having to rely on some external library/code to support them) ?
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
You insensitive clod, I only have a 286 with 640kb, they told me I didn't need any more than that!
You _really_ need to actually go read about the issue here.
This is about needing that much ram with a particular set of very memory-hungry compiler options. You can build the browser in much less ram than that if you don't enable those particular compiler optimizations.
So as far being selectively literate... are you sure that's not you?
You're wrong, you can easily output 32-bit binaries with a 64-bit toolchain with MSVC - even from within the Visual Studio IDE if you set up the environment from the command line and then type "devenv /useenv". However you need to be running a 64-bit Windows which presumably the Firefox buildbots aren't.
The interactive way to Go -- http://www.playgo.to/iwtg/en/
We already have perfectly good Operating Systems, but now everyone is trying to make the browser into another operating system.
Mainstream operating systems aren't "perfectly good" if they lack a sandbox in which to run untrusted CPU-independent code. The closest thing we have to that is the JavaScript, Flash, and Java applet environments. With what would you replace them while retaining the cross-platform and CPU-independent characteristics?
What would you do if tomorrow there would be no search engine any more (no Bing, no Yahoo, no Google, no what ever you using)?
I think I understand the sentiment of your rhetorical question. But in your proposed replacement for the web, what mechanism would you provide for finding information?
But why there is no author tag
My best guess is because you haven't looked up <link rev="made"> in HTML4 or <link rel="author"> in HTML5.
no table-of-content-tag
Are you talking about site-wide TOCs? Use <link rel="up">. Or are you talking about TOCs within a document? If so, look for a big unordered or ordered list each of whose elements has a document-relative fragment link <a href="#...">, especially those linking to the IDs of heading elements (<h1>, <h2>, and the like).
no index-tag
<link rel="archives">
We already tried that with Flash, Java Applets, SL. So now we try it again, but this time it will be "magical" because it's all Html5.
What's magical about HTML5 compared to Flash, Java, and Silverlight is multiple competitive implementations. For years, prior to the Open Screen Project, Macromedia and Adobe had been using license agreements to stifle work on a competitive SWF player.
Tired today...grammar not fully processing. Maybe I could go for having 64 bit hardware in me.
I'm starting to think GNU is the problem with "GNU/Linux" these days.
The KERNEL32.DLL wrapper provided by OldBoy2k and OldCigarette also makes executables with EncodePointer/DecodePointer work in windows 2000.
Hey don't blame me, IANAB
Apparently the linker outputting 32bits executable is a 32bit application.
There is no cross-linked for 32 application running in 64 bits in VS2005
To keep with your metaphore, it would be as if the only way to link an iDevice executable would be to run a iDevice-linker on the iOS simulator application, instead of running the linker that came with OS X Lion.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
If I understand the article correctly, this is only about the build-process. Why not cross-compile on 64 bit? Or is this another one of the (numerous and stupid) limitations of Windows?
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
This is basic stuff to anyone who actually maintains a build, but Slashdot hasn't been a forum mostly populated by engineers for a number of years, now.
This appears to be due to link-time optimization blowing up the resident memory size of the linker, taking it past 3GB (which is already a non-standard hack the 32 bit build has had to do). Firefox is large, yes, but this has nothing to do with the final binary - which appears to be about 100MB total including all libraries in the Aurora builds.
I used to routinely run out of 32 bit address space compiling executables for a 64MB embedded ARM platform. This was due to symbol bloat, not executable size (which was 8MB). I also ran out of space compiling for a DSP with 288KB of RAM and 1MB flash, but that was mostly piss poor tools (Tasking). In fact, doesn't Chrome and even the Android sources already require building on a 64 bit host?
And even then they've been around for 30 years.
Pretty good is actually pretty bad.
And we're talking about builds, not in-use resource consumption... where it behaves just like every other browser.
Nope. It doesn't even behave like the 3.x series (of the very same browser, Firefox!) before rampant version number inflation. A perfectly serviceable "Athlon XP" based system with 750MB of RAM went from just fine to useless (in terms of firefox usage) at the version number break, under both Windows XP and Fedora. Memory footprint was my first suspect, but throwing in more RAM (up to 2.5GB now) helped but didn't make it completely better. Ironically, it's almost ok now under XP and still atrocious under Fedora.
Something baaad happened. But who cares about old systems, right? Only users, it turns out, not people triaging bugs.
Apparently the lameness filter hates dashes.
Blame MS.
The sane option for windows from vista on would have been to deny users the choice and install a 64bit os if the hardware supports it.
Personally I have run 64 bit since xp, although you can only call that a test, vista 64 was ready for all.
Yes I know, the 1 in 16384 people that insist on having some old POC device. Well they can keep an old machine around for it if it is that important.
The better option would have been to deny users the choice and only offer 64-bit builds of Vista and 7.
"But it doesn't work with my 14 year old scanner!!!" Then keep using Windows XP?
There were already growing pains with Vista (shitty GPU drivers from AMD and Nvidia, a new audio framework, and users not being administrator by default), so it would have been the perfect time to force everyone to move to x64. They couldn't force people to switch with 7 because they wanted to get people off of Vista ASAP (even though Vista itself was fine). Oh well, hindsight is 20/20 and what not.
It would be cool if there was a solution to properly handle a 32-bit driver in a 64-bit host environment, but there isn't. (Is there? Even if you use a 32-bit VM on a 64-bit host, you can't do shit.)
This isn't about RUNNING Firefox, but compiling/linking it. I guarantee Skyrim takes more than 500GB under that context.
However, yes, Firefox has become exceedingly bloated.
500 GB?
Well shit. I thought I was fine when I built my desktop with 16GB. Well, it was 2 months ago, I guess it is time for an upgrade.
The compiler part is an issue because Firefox is open source. They don't want to force the Firefox development community to upgrade to new computers.
Iceweasel, 35 tabs open, 1 week uptime, 352MB of resident memory ;)
Dilbert RSS feed
YM every other browser that, if I accidentally forget and leave it open with a few tabs on different websites overnight, will have become unresponsive and eaten half of my system memory by the time I come back in the morning? FF is noticeably different than any other browser when it comes to in-use resource consumption, in my experience, not that it has much to do with the original story.
Damn kids and their PGO giving double digit perf increases! Get off my lawn!
-1 overrated isn't the same thing as "I disagree".
If Microsoft encountered this problem while compiling a windows component they just turned PGO off. End of problem.
64bit computing yes, hence why I specified microprocessors. I really hope that his hardware isn't as old as 64bit computing....
I'm starting to think GNU is the problem with "GNU/Linux" these days.
Can you elaborate? Chrome already supports AdBlock
I know nothing about this, but with X being a display protocol, couldn't you run X in 64-bit and connect to it from a 32-bit app just fine?
No C++ is not one of the culprits.
That is because this optimization happens on link time, and has no relation at all with the complexity of the compiler.
Rethinking email
It would be cool if there was a solution to properly handle a 32-bit driver in a 64-bit host environment, but there isn't. (Is there? Even if you use a 32-bit VM on a 64-bit host, you can't do shit.)
In the beginning, Microsoft used Thunking to be able to use 16-bit drivers (and other DLLs) on a 32-bit system (Windows 95). This halted in Windows 98 (driver wise) due to horrible stability problems. Eventually, Microsoft moved to Windows on Windows (WOW) which provided an adequate environment for 16-bit apps to run on 32-bit Windows NT. However, if you have a 64-bit version of Windows, you don't have WOW, but WOW64, which runs 32-bit apps on 64-bit Windows, and has no support for 16-bit Windows applications.
"When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
My guess is that this is just a Visual Studio limitation, in terms of how much RAM their tools need to link an executable that, ultimately, will require much less memory to load and run.
But what I'm wondering is why they don't switch to some dynamic linking? Modularize it into DLLs (or equivalent), so that each can be linked separately at compile time, and have all these modules pulled in at runtime. It really won't slow down loading much at all.
The main objection would be that this is impossible because Firefox is much too spaghettified in terms of how different components communicate. Components would have to be rewritten so that they're always accessed through a simpler interface.
I have an idea: why not fork Firefox and create a leaner/faster just-a-browser and cut out all the excess junk.
And it could be named after some sort of animal or bird that comes out of ashes maybe ?
You can't get one of those from Microsoft
Uhm, yes you can. I do it all the time. Its been that way for years. Since at least VS2k5, I don't remember it in 2k3 though.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
...
Which can also use a 64 bit compiler to compile 32 bit applications ...
Its really fucked up that you think GCC is anything comparable to the MS compilers. GCC is basically the worst compiler on the planet that is known by more than 3 people.
Intel's compiler is the cream of the crop, MS's is a comfortable second, GCC is a distant last as far as performance, code output and all around quality.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
I would be dismayed if Skyrim really took more than a couple hundred megabytes to compile, given that you're only compiling the engine, which is likely small and even a piece of shit computer from 10 years ago could probably compile it in under 30 minutes. The game's assets (music, graphics, whatever) have no bearing on this.
The main install for Firefox is now 14MB in the latest version, but it's not a stub install. I've run the installer just fine on an unconnected PC. On the other hand, updates come out so fast, that you could almost consider the download copy a "stub install" that also happens to be a full install of Firefox that then auto-updates over the Internet.
Are you sure it's not invoking a 32-bit linker? Can you show me some output which convinces me that you're right?
Its time to make the 64-bit Firefox a reality. It would take the same amount of work needed to make a 32-bit compile on the 64-bit OS. Go..Mozilla Go...
Making the usage of Firefox fast is the whole point of PGO, a process that uses up orders of magnitude more when compiling and linking an executable than without PGO. So, in order to get the fastest speeds out of the Firefox binary, the Firefox build process optimizes and uses lots of RAM in the process. The problem is that the MSVC linker is 32-bits, so the *linker* is running out of memory ONLY WHEN FIREFOX IS COMPILING AND OPTIMIZING. The executable that is generated is not as large, does not use as much memory, and is faster than if Firefox was built with a "straight" boring old build process.
The whole point of this exercise is to save assholes like you more time by making your browser faster and more responsive so you can post snarky criticisms of Firefox (without understanding the problem) faster.
Your welcome, asshole.
You can't. Microsoft simply doesn't offer a 64-bit linker that can produce 32-bit code.
I seem to remember issues with FreeCAD and OpenCASCADE. There were about half a dozen or so others.... I don't recall the names of any of the others offhand.
File under 'M' for 'Manic ranting'
This only effects builders of FF not users. If they need a 64 bit system to build their own code who the hell cares ? Lame++
And that is supposed to make it OK?
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
I suppose you could use a VM based language where the optimisation takes place at run time instead, but they're trying to do all that in one step where it affects the developer (who can take the need to have a super computer to build) rather than the user (who doesn't want to have a super computer to run it), or an interpreted language where you have to write a VM to run it to get any form of acceptable performance.
Or you write it in something like C++ and complain that the optimiser tool uses too much memory itself (or that the developers didn't modularise it sufficiently)
Either way, the FQA is a terrible rant with plenty of over-exaggerations, inconsistencies and 'bad things' that were obsoleted decades ago. Ignore it and hope it goes away, or read this for some rebuttals.
To branch out more, it's really complaining against using bulky languages and IDE's rather then good old C / Asm and a console window.
Well... when two different programs trying to implement the same set of functionality have the same issue with the linker, you _could_ assume that both development teams are incompetent. Or you could assume that the functionality involved takes a lot of code and the linker doesn't scale well. Your choice.
Comment removed based on user account deletion
When they speak of using VS2005 to build it, it effectively means Visual C++ 8.0 (the command line compiler). I mean, do you seriously think their build system actually launches VS and emulates pressing Ctrl+Shift+B?
You mean, there are people who read C++ FQA and actually take it seriously?
No, it doesn't, it speaks about the amount of memory required when you try doing code optimization across an entire program image, instead sticking to optimizations inside translation unit boundaries.
Coffee-driven development.
GP is not talking about running a 64-bit process on a 64-bit OS. You can't do it with VS - it has a 64-bit compiler and linker, but they only output IA64 or amd64 binaries, and Mozilla needs an x86 binary.
However, when you run a 32-bit linker on a 64-bit OS, you get an extra 1Gb of address space (because the OS doesn't need the top 1Gb for itself).
You mean some people still run Windows?
FTFY
512mb is plenty even for modern browsers if you pick the right one. Opera 11 worked just fine on an Eeepc 701, for instance (the last version of Firefox that worked on it was 2.0). Likewise Opera mobile works superbly on this Archos g9 80 tablet, which also only has 512mb of ram.
regards, the_leander
I suppose you couldn't enchant my toolchain? The dull old linker barely links Skyrim...
hello.c:
#include
#include
int main(int argc, char *argv[])
{
printf("Hello world!\n");
return EXIT_SUCCESS;
}
hello.bat:
@ECHO OFF /MT /c hello.c /MACHINE:x86 /LIBPATH:"%VCINSTALLDIR%\lib" libcmt.lib hello.obj
SETLOCAL
CALL "%VS80COMNTOOLS%..\..\vc\vcvarsall.bat" x86
cl
ENDLOCAL
SETLOCAL
CALL "%VS80COMNTOOLS%..\..\vc\vcvarsall.bat" amd64
link
ENDLOCAL
output:
C:\Project>hello.bat
Setting environment for using Microsoft Visual Studio 2005 x86 tools.
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.762 for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.
hello.c
Setting environment for using Microsoft Visual Studio 2005 x64 tools.
Microsoft (R) Incremental Linker Version 8.00.50727.762
Copyright (C) Microsoft Corporation. All rights reserved.
C:\Project>hello.exe
Hello world!
The interactive way to Go -- http://www.playgo.to/iwtg/en/
The better option would have been to deny users the choice and only offer 64-bit builds of Vista and 7.
"But it doesn't work with my 14 year old scanner!!!" Then keep using Windows XP?
The reason Windows is so popular in the corporate world is because they don't do stuff like what you suggest. You're thinking about a $50 scanner, but maybe in the corporate world they have 300 $5000 multi-function devices. Or, maybe they have 100 $100k mass spectrometers. Or, maybe they've got a $15M MRI machine. If your vendor doesn't release new drivers then you can't upgrade your OS. Sure, you can run XP for a while, but not forever if you want security patches. Do you really want to throw away a $15M MRI machine that works fine because your OS isn't getting security updates any longer?
Microsoft has generally supported their OS FAR longer than just about anybody else, and this is one of the reasons that they're so hard to displace. In the linux world we call "long term support" a few years. Microsoft still supports XP, and that was out not long after Y2K. Think about what you were doing around Y2K...
This post has absolutely no value at all, but its +5 insightful.. I mean wholly fucking anal drip... Either the mods today should be fucking ashamed, are this cocksucker has sock puppets that he uses to mod his own posts up.
anal drip... hmm bad low calorie chips.
Ah, sorry -- I see the difference now, you're using link time code generation which the x64 bit linker is not capable of when the machine type is x86.
The interactive way to Go -- http://www.playgo.to/iwtg/en/
And it's the linking, not compilation that's the problem.
However it also means that it may be a question of the application structure rather than anything else. Time to see how much that can be broken out to shared libraries (DLL:s) and also see how much that shall be public and how much that shall be internal to each DLL.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
And the trolly troll is trolling.
Unless you regularly compile optimized builds of Chrome, Opera, Safari, or IE, kindly STFU.
That FQA betrays vast ignorance about not just C++ but actual computers. His very first complaint presumes you'll just naturally not know anything at all about the language, and just naturally not bother to learn anything about it either. Seriously, I am not making this up: even in C what he's complaining about isn't a problem for anyone who cares. Spot-checking says the pattern continues. I checked half a dozen pages, and every one was well larded with ignorance and cheap shots.
As always, all IMO. Insert "I think" everywhere grammatically possible.
FF8 on 64-bit Linux was using 3.2GB RAM just now before I closed a FF window that had a bunch of dynamic pages.
Real RAM usage shot up to 7.3GB and virtual memory exploded to 22.1GB. The kernel OOM killer finally saved the system.
"I don't know, therefore Aliens" Wafflebox1
Of course they are not the same. But they are not unrelated either. As a program grows in memory footprint it generally takes more resources to compile and link. That sure looks like what is happening here. Your flaming name calling is completely inappropriate, you should be able to make your point without it.
I'm an American. I love this country and the freedoms that we used to have.
'bad things' that were obsoleted decades ago
I've already e-mailed Yossi about a couple points that C++11 has obsoleted, such as the former lack of practical syntax for closures ("functionoids" or "functors").
or read this [stackoverflow.com] for some rebuttals.
The highest rated answer there admits that Yossi has a few good points buried in the vitriol. Implementing a good compiler or debugger for C++ is far more difficult than for some other languages, as is making meaningful error messages. There is no standard subset with well-defined failure modes. It's not a good choice of language for anything needing reflection. Even distributing binaries to the public becomes a chore unless the market have decided to become a platform monoculture.
Anyone running anything older than XP-SP2 is either a dedicated hobbyist or a criminally negligent system administrator
At $WORK, we've got a CNC machine that runs Win 2000. Only. Moving to a newer Windows release requires replacing the entire control, to the tune of $20K. Guess what we're still running!
(One could argue that means it's a crappy product. Well, I'd agree. But in my experience, most computer products are crappy. Which leaves those of us wanting to get actual work done stuck holding the bag.)
That particular computer doesn't need a web browser, so no loss, but it's not hard to imagine a scenario where one would want HTML rendering, maybe even an interface to some web-based business automation system.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
Here: http://msdn.microsoft.com/en-us/library/5wy54dk2(v=VS.80).aspx ... However it does not support link-time code generation when you're linking object files in a non-native format.
The interactive way to Go -- http://www.playgo.to/iwtg/en/
Why do we need a "sandbox" anyway?
Because one can't know whether or not a given downloaded program is going to deface or disclose the files in one's home directory. The ideal way would be to model what threats are possible and let the user restrict an untrusted application from doing sensitive things. When run for the first time, a program would list the sensitive things that it plans to do. Android, OLPC Bitfrost, and the new capability environment in Mac App Store start to do this.
The viruses are only the result of the lack of proper updates of the system and applications
How can one perform "proper updates" in the face of zero day vulnerabilities, which are exploited before the publisher issues a patch? Sandboxing at least reduces the attack surface until then.
and also some idiotic design decisions like Auto-Run
That was added after numerous support calls from people who observed that the computer didn't appear to respond after the user inserted removable media. If, say, a DVD player appliance didn't respond after a disc was inserted, wouldn't the average end user consider the player broken or at least get confused? How should operating systems have been acknowledging the insertion of media without exposing the user to execution of unwanted software that can harm the user account even if not an administrator?
login-always-as-admin
Microsoft took the first step with UAC in Windows Vista by turning administrators into the equivalent of a sudoers group. But UAC/sudo behavior isn't going to help when fake antivirus and other scareware manages to trick members of the sudoers group into elevating to install what they think is a codec to watch a video. Seeing the "Run automatically on startup", "Read process list", "Force other processes to close", "Cannot be uninstalled without wipe", and "Intercept file system" capabilities on a video codec instead of "Decode media files" might raise a red flag.
For example, my whole comment could be enclosed in a author="devent" tag, a content="comment" tag and a topic="Firefox Too Big To Link On..." tag.
They're working on that, and it's called microformats. I'll grant that it's not there yet.
I think search for new content must be an integral part of the web.
It is an integral part of existing web sites. For example, Phil's Hobby Shop supports full-text search of every product's description. It's just that I can't see a way for web sites to federate on this, especially as web sites try to become more "sticky" and keep users from navigating away to view a competing site's ads.
In the corporate world they also have companies behind those expensive machines that can write a proper driver (when forced to).
In the corporate world they also have people who will say "We should not upgrade to X because of Y".
In the corporate world they also have bosses who will say "Why upgrade to X? Our Y already works, why spend $Z?".
XP will get security updates until April of 2014.
I'm pretty sure there's no one in the world that has anything that meets all of the following criteria:
1) Doesn't have a 64-bit driver
2) Is so complicated/critical/magical that no one can write a 64-bit driver for it
3) Can't be run on a locked-down 32-bit system past April, 2014 because of security FUD
4) Had enough support to make it work on 32-bit Vista/7
I too would pay obscene sums of cash to watch obese people play musical chairs. I don't think reality tv even needs an excuse anymore, we could float this in front of a producer and when they woke up from their orgasm induced concussion, they wouldn't be able to sign the appropriate papers fast enough. "Biggest Loser: Musical Chairs Dallas" - coming to a small screen near you.
Actually, Skyrim uses more and more the more you travel and explore. Which is why some of us enabled the use of >32bit addressing by patching the binary.
I am in the same boat. Couple of hours in (started with a restored session) 8 tabs, 3 plugins. 256 megs. Not anywhere near what other people see. Wonder if using Noscript and blocking unnecessary javascript helps?
Let me know when there is a decent alternative. If Rekonq wasnt so crashy I would consider it.
Microsoft simply doesn't offer a 64-bit linker that can produce 32-bit code
false.
you can link x86 code using the 64-bit link.exe
just use the 32-bit compiler to compile to .obj, then use the 64-bit linker (with the /machine:x86 switch) to link the .objs.
I'd be interested in hearing about any x86-64 PC / Workstation motherboard that took over 256G RAM, haven't seen any. 192GB is the most I recall seeing.
> I know nothing about this, but with X being a
> display protocol, couldn't you run X in 64-bit
> and connect to it from a 32-bit app just fine?
Emphatic yes. One day I decided to do a pure 64-bit Gentoo linux install (pure as in no multi-lib). I use one freeware Windows app that has to be run under WINE. Then I found out the hard way that WINE will not build under a 64-bit-only system. I ended up building a 32-bit Gentoo guest under QEMU-KVM. Wine runs on the 32-bit guest, using the display of the 64-bit host. A chroot would probably also work.
I'm not repeating myself
I'm an X window user; I'm an ex-Windows user
Bingo. And, of course, link-time code generation is essential for PGO.
That's probably more a limitation of Microsoft's linker than of Firefox. Linking, at its heart, is a bit of sorting, filtering, and merging and can be done in fairly modest amounts of memory even for large programs.
I still get calls to support industrial processes driven by DOS based machines.
I am an old guy, raised with these beasts. I know the innards of these things like the back of my hand.
The harbinger of death seemed to be a dearth of disk drives compatible with old DOS machines. Even my stream of disk drives from the recycler is drying up. But it looks like SanDisk and Syba have pulled me and my customer's arse out of the fire again.
Its hard to throw away an enormous expensive piece of machinery because its controller ( which has been doing exactly what it needed to do for 25 years ) isn't supported anymore.
"Prove all things; hold fast that which is good." [KJV: I Thessalonians 5:21]
The 640 remark was made in 1981, while the 286 -based (PC AT) came out in 1984. The IBM PC was 8088/86 based and could only address 640KB in main memory.
I come here for the love
That's trivial -- you just have to mount /home and /tmp (either as normal partitions or with --bind)
inside the chroot, and they will find the X11 socket and the .Xauthority file just fine.
But you don't really need a chroot for that. You can install the 32bit libraries and ld-linux.so somewhere and then starting them with a script like LD_LIBRARY_PATH=/32libs /32libs/ld-linux.so "$@".
What, uh, what little endian 1080p-capable codec are you using?
"Yeah...it was the numbers that were irrational, not the murderous cult of vegetarians...." -- Hippasus of Metapontum
... this feature which can give double-digit percentage speedup because it takes a lot of memory" is stupid. LTO is costly -- period. It's just very worth it.
That's it?? That's kind of meh, when you think about it. "Speed up" shouldn't be measured in percents. It should be measured in decibels, to match the way users experience it.
Can you be Even More Awesome?!
I'm pretty sure I'm not the one that's being selectively literate. If you're having that much trouble with a compiler, then you either need to reduce as many lines of code as possible, while still keeping the features intact, or you need to use a less resource intensive compiler. It's that simple, and still goes back to what I initially said.
As for Kommet calling me a troll and adding me to his foe list... Seriously, dude, where'd you get your degree from? Assmad University?
The first of those is what's being done, of course. What made you think it's not?
The fact it happened twice is a dead giveaway.
You keep missing the fact that there are benefits to having as much code as possible in a single library in this case. So the first time, the address space available was increased. The second time, that will happen as well, and some code was moved out of the library to give time for that to happen.
Long-term, a different solution is needed, of course. At that point, the costs of splitting the code out may have to be borne after all (not the cost of doing the work, but the cost of the resulting code being slightly slower).
A lot of people still have CPUs that are still 32-bit only, and haven't grown their RAM beyond 3GB. That's one of the biggest hurdles in going from XP to 7.
One would have to specify x64 processors to qualify them as new. Otherwise, every RISC CPU had become 64-bit before - MIPS R4x00, Alpha AXP, PA 8x00, Poewr, UltraSparc. Two of them even ran Windows NT, so MS did have the opportunity of having a 64-bit OS ready in advance for the server & workstation markets on RISC, but never took it.
In the corporate world they also have companies behind those expensive machines that can write a proper driver (when forced to).
Uh, clearly you've never owned one of those high-end machines. It is pretty common for them not to receive long-term support, since the vendor wants you to buy a new one, and the people who buy those machines rarely have any IT background and ask questions in advance like "how long will you support the OS?"
In the corporate world they also have bosses who will say "Why upgrade to X? Our Y already works, why spend $Z?". XP will get security updates until April of 2014.
Yup - and we'd be running XP on such a machine until around then. However, what if the machine still isn't ready for replacement then? If you want it on the network then there are a lot of issues with not upgrading the OS.
3) Can't be run on a locked-down 32-bit system past April, 2014 because of security FUD
Well, we've certainly taken this approach for our NT-based machines. However, this is really not a great position to be in. Good security means defense in depth, and you just don't have that when you're running an OS that hasn't been patched in 10 years. The world's greatest perimeter firewall won't help you if somebody plugs a flash drive into the thing.
But, you've actually made my point for me in some sense - the reason that XP is supported until April 2014 is because MS does bend over backwards to provide long-term support for their OSes, and APIs. Why would a company drop 32-bit support if they're willing to support a product for almost 15 years in the first place?
I'm sure they'll drop 32-bit at some point, but I can't imagine that it costs them a huge amount to keep it as an option, and as long as the benefits outweigh the costs they'll do it - even if it makes the purists cringe. MS has never done anything for the purists - if you could cram 4GB of RAM onto an old 25MHz 486SX motherboard I wouldn't be surprised if Vista booted just fine on it (eventually), even without the floating point instruction set (I have to admit I'm suddenly morbidly curious).
Sure, on my desktop at home I've been running 64-bit linux since the socket 754 days. However, at work around the same time I was still nursing a VAX along to the graveyard. That's just the nature of long-term capital investments.
Not that they shouldn't care, mind you, as that is some seriously monolithic code.
They're talking about using link-time optimisation (LTO). That means that you compile each compilation unit to an intermediate representation and then run optimisations on the whole program. This takes a staggering amount of memory (which is why no one bothered with it off high-end workstations with very expensive compilers until very recently), but can sometimes be worth it. It actually helps modularity, because you can keep your source code nicely separated into independent components without worrying about efficiency, and you can do better data hiding.
As a trivial example, consider an accessor method. Something like getFoo() { return foo; }. Without LTO, you'd want to put the declaration of the class and this method in the header so that every compilation unit could separately inline it. This reduces modularity, but it saves you the cost of a function call just to access a field in a structure. With LTO, you can make the class opaque (if you're a C++ junkie, using the Pimpl pattern, if you're a C programmer by just not declaring the struct in the header). You'll get a single copy of the function emitted, and then the link-time optimiser will inline it everywhere.
I am TheRaven on Soylent News
There is no advantage to running 64bit LINUX....FTFY
Not true at all. There are several advantages to running code compiled for x86-64 instead of for x86. If you're on *NIX, then one of the big ones is that x86-64 has rip-relative addressing, while x86 lacks eip-relative addressing. In position-independent code, this means that any call to a static function or access to a static variable is cheaper. Windows doesn't use position-independent code for DLLs on 32-bit (it tries to load them at a fixed address and performs load-time relocations if it can't), so that's not a problem, but on *NIX.
There are other advantages. One of the big ones is that anything targeting x86-64 will default to using SSE for floating point instead of x87. This is generally at least slightly faster in the silicon, but it's also much easier to generate good SSE code for the register-register SSE coprocessor (with lots of registers!) than for the stack-based x87 (with only a handful).
Then, of course, there's the fact that you have a lot more general-purpose registers with x86-64, so you need far fewer stack spills to do the same thing.
I am TheRaven on Soylent News
This doesn't work with WPO/PGO, which makes it useless for the purposes of this post.
It should be recalled that Firefox, which started as "Phoenix" and then became "Firebird" before becoming FF, was the lightweight, stripped-down, modular alternative to the Mozilla Suite. Do age, feature creep and the consequent bloat eventually make a mockery of all such aspirations for lean code?
A process still uses 32bit memory addresses to reference memory. This means that a process can still only address 4GB of memory.
...in the same segment.
But currently, because of lack of proper PAE-support, the WHOLE virtual memory rande is limited to 32bit.
This is normaly splitted in 2x 2GiB chunks. 1 chunk for the application, 1 chunk for the kernel.
With the 3GB switch mentionned, this is split into 3GiB for apps and 1GiB for kernel.
So even if you could addresse several different segments of 4GiB each, the virtual memory systems behind limits you to either 2GiB or 3GiB memory max for all applications altogether.
Meanwhile, a PAE-enabled Linux could address 64GiB of Physical RAM, all this in a 56bits virtual space.
You could put your 32bits 4GiB segment wherever you want in this virtual space.
If you were to use more than 32bit memory addresses to get more memory, suddenly you aren't a 32-bit OS anymore.
you get a 32bit address, relative to the base of the segment.
the segment tehmselves could lie anywhere in the virtual address space.
In segmented memory model (i.e.: using C/C++'s "far" pointer), have the segments point to different chunk of 4GiB each and you can address more than 4GiB from a 32bits application.
(have the processor's DS, ES, FS segment register all point to different segments, for exemple)
That's exactly how 16bits processors have been addressing more than 64k in the dawn of intel CPUs. (Except that back then there wasn't a virtual address space. segment and pointer register did directly address RAM. the 32bit 386 introduced the concept of virtual memory).
In a flat memory model (all segment register point to the same space, which back when "flat model" was invented, should have enclosed the whole memory, but that's not the case on a 32bit app on a PAE-enabled kernel), indeed no segment are really used and an application can only manage 4GB at a time.
Still, these 4GB are more than the 2GB/3GB provided by a non-PAE kernel. /3GB switch would have probably helped VS2005 to do its stuff.
That extra 1GiB more than the
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
In fairness, VC++ does have some baked-in COM magic - that's probably what DrYak was referring to.
Yup indeed.
- Under VC++ you just #import a COM, and then have an object behaving automagically just like a regular C++ object.
- Under GCC you have to rely on stuff like disphelper to call COM objects easily with run-time bindings.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
You might be able to produce code running on Win95 with proper tweaking. You might even be able to contort VS2010 into producing 16-bit realmod 8088/8086 code. But you're not alone.
FireFox is open-source, meaning that it is developped and tested by a myriad of developpers and amateurs all around the world.
Moving from VS2005 to VS2010 would require either :
- forcing all of them to buy VS2010 and forcing them to tweak it so development on Win2000 to WinXPSP2 can continue.
- forcing all of them to buy VS2010 and droping support for Win2000 to WinXPSP2.
- forcing all of them to buy VS2010, having it run in un-tweaked mode producing tests on WinXPSP3 and up only, and then have a dedicated team at Mozilla whose single job is to test if all submitted patch also compile nicely to produce a working Win2k compatible binary.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
You'd either need far pointers or wide ones on the host which I don't know of any systems supporting easily, aside from DOS.
Unix has api for that, and as GCC is open source, it could be adapted to this.
That's why I say *could* and not *will* when speaking about addressing 3GiB.
(Except that running 64bits cross compilers targeting 32bits on a 64bits Linux is way much more easy, so nobody goes that route).
Windows has theoretically an API for that, called AWE.
But then you have 2 problems:
- You need a special server license to use more than 4GiB of memory.
- The VS2005 Linker, is probably *NOT* AWE-aware, isn't open source and thus can't be adapted to AWE.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
I hate saying this, but when the code can't be compiled because the library is too massive for the compiler, there is no benefit.
While I agree that the larger registers are worth having, I personally have been running X64 since XP X64 beta, the poster I was responding to said there wasn't any point for general users to go x64, that it was basically for Linux (hinting that it was programmers that needed it) and those really slamming the machine. When I first went to X64 I only had 2Gb of RAM but it STILL made a difference, especially in video transcoding.
But now even grandma gets major advantages for running X64, with superfetch and the new Windows memory management every drop of that RAM will be put to good use speeding up the OS and preloading programs that are often used.
You'd think though that someone would write a superfetch for Linux, it shouldn't be hard, just keep a list of what programs are run and when and if RAM is left empty to cache those programs. If the user launches them it'll call them from RAM, and if the user launches a program that needs the RAM dump the cache. I'm sure it would be a little more complex than that to implement but that's the basics of it.
ACs don't waste your time replying, your posts are never seen by me.
Well, sure. Except the code is compiling just fine as of yesterday, after a few changes to it. Tempest in a teapot and all.
Does "preload" do what you're talking about or are we not thinking of the same sort of things?
--What, you never heard of Vmware? I run 64-bit Linux Mint on my 6-core beast, and my USB Lexmark X2500 is not supported in Linux. Yet I print from it regularly using various 32-bit XP guests, running the native Lexmark 32-bit XP driver.
.
== WolfriderV6 == I'm willing to admit that *I just might* be wrong... Are you??
WHOAH! A +1 TROLL!
One of the rarest of all creatures!
This is my footer. There are many like it, but this one is mine.
Not really as superfetch is based on usage patterns. lets say that every weekday i launch Chrome, and on every weekend I launch WMP, what superfetch will do is load Chrome during the week, replacing that with WMP on weekends. basically the longer you use the PC the "smarter" it gets about your usage patterns and the better it will be at predicting what you are gonna launch. For example my PC knows I launch Paragon to make a backup on the day after patch Tuesday so it'll be loaded into RAM the second Wednesday of every month like clockwork waiting for me.
I'm sure it wouldn't be hard to cook up something similar in Linux, I've just never heard of anyone doing it. When superfetch came out with Vista there were several projects started but IIRC they are all dead code on sourceforge now. Shame as it is a nice feature.
ACs don't waste your time replying, your posts are never seen by me.
that is isn't quite so clean and neat when you're compiling a program that must work on millions of systems other than your own :)
But I would have thought they were already doing that. While going from 32bit to 64bit doesn't magically make everything faster, it does generally add a tiny bit of speed simply because of the extra registers Intel and AMD add for 64bit operations.
Even if it were only a few points, I would think that building as much as you know they must, ANY tiny bit of speed improvement would add up pretty fast (even if only 1% or 2%).
"Don't be a martyr -- BE THE ONE WHO GOT AWAY!"
My point still stands, regardless of your last-ditch-analogy. Thanks to whoever it was for making sure I got marked as a -1 Troll for posting indisputable fact, though. That actually makes me look like less of an idiot.
There is some indication (though nothing too specific in what I read) that it has some awareness of usage patterns, but I couldn't say. That said, it's hard to imagine application launch being much faster on my current machine anyway. I'm not really going to notice the difference between 3 seconds and whatever would be faster.
Running 7.0.1 with over 50 add-ons. Non-deterministic swap IO chocking, less often freezes, most often exit without saying a thing. 1.4GHz Celeron M, 2x256MB DDR1 RAM, 40GB 5.4krpm PATA drive, 6y.o. laptop, Arch linux, -pf branch kernel i686 microarch optimizations, Xfce4 vanilla.
I know tobacco is bad for you, so I smoke weed with crack.
Well I think the better metric would be the intelligent use of RAM, after all DRAM is gonna take the same voltage whether sitting empty or fully loaded so having a large amount of empty RAM simply isn't doing you any good.
Checking resource monitor in Win 7 just now shows of my 8192Mb of RAM there is only 332Mb free, with 6373Mb being used for caching. With that large a cache it is more likely that when i launch a program its exe and .dlls will be already loaded and waiting on me thus speeding up performance. While you are correct that with modern desktops that extra caching simply won't be felt by most i could really tell a difference in my netbook when i went from 2Gb to 8Gb thanks to the larger cache and superfetch. I got around an extra 40 minutes on my battery, from 5:30 to a little over 6:15 simply because that much larger cache and superfetch keeping my apps loaded meant the drive could stay spun down more.
One thing i don't know why the Linux guys haven't ripped off yet is the new UI tweaks like jumplists and breadcrumbs. Frankly once you've used jumplists and breadcrumbs going back to the old way of file management feels like a real step back. With breadcrumbs I can instantly jump through a file tree without having to drill up or down through folders, and having nearly every app have the last 10 things you did instantly accessible simply by right clicking on the icon is just too damned nice.
ACs don't waste your time replying, your posts are never seen by me.
Of course. Not too long ago, all netbooks were still 32-bit. Those devices haven't magically become 64-bit systems.
I am not devoid of humor.
I use the file manager 3 or 4 times a month. Maybe that is part of it.