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.
You mean some people still run a 32-bit OS?
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
I think it speaks volumes about the bloat of VS2005 more than about the bloat of FF.
Every end has half a stick.
Take a Zen approach Mozilla, less is more.
Firefox devs requesting immediate RAM bailout.
It doesn't mean much now, it's built for the future.
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.
I don't want 90% of the drek Firefox is including. I don't know what most of it is. I want a browser that can run a page with a self-update script and not end up consuming 3gb or memory overnight. I'm trying out Comodo Dragon right now for that, it uses the annoying chome interface, but seems to avoid the rampant growth.
It takes 16GB to compile Android.
"When information is power, privacy is freedom" - Jah-Wren Ryel
You're two major versions behind, that's the problem.
It would build just fine in 2010.
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.
I would doubt they are compiling VS. That would be a bad idea for anything but developing. Most likely they are calling the compilers directly. Building on 64 bit targeting 32 bit is easy for .Net. Hope its easy for them too.
I guess that America's obesity problem has extended to software.
To offset political mods, replace Flamebait with Insightful.
Google doesn't build Chrome with PGO enabled with Visual Studio for the very same reason. Firefox only reaches the issue now.
I saw problems months ago, when I accepted the (then) latest update on my older 512 meg XP based HP notebook and Firefox suddenly could no longer open more than just a few tabs before bogging down completely. I mentioned that in Slashdot and the insightful people here told me I was stupid and didn't know what I was talking about.
I'm an American. I love this country and the freedoms that we used to have.
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.
Is rendering web pages more complicated than rendering Defender levels? My C-64 did that with 64k. That's 65536 bytes. That's 16-bit. Really cools sounds. Stuff that moves. Yes, text too.
I miss it. I also miss software that doesn't suck.
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.
Comment removed based on user account deletion
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?
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.
In this thread you reply with problems with firefox and how they are related to code bloat. Technical explanation please! This is a great opportunity to tell the entire world exactly why firefox is bloated- And prove it too!
I, for one, want to know how the sub 10 megabyte download for windows is considered bloated. No really. I want to know.
I want to hear why firefox is bloated and chrome, safari, opera, IE, etc are not.
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?
What about fixing TF compiler/linker?
Stupidity is an equal opportunity striker.
Fellow slashdotter Bill Dog
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
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 ]
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!).
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
More like too bloated. This thing is becoming the new Netscape 4.0 "Communicator"
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 ]
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.
so long as you're still building and distributing a 32-bit version?
Microsoft's 32 bit linker is only available as a 32 bit application for the version of MSVC they're using.
Newer versions of MSVC produce executables that cannot be run on windows 2000.
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.
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?
Eight bits, I tell you.
And we pushed the registers ourselves!
Lazy coders ...
-- Tigger warning: This post may contain tiggers! --
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 ]
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?
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.
Quick, spread some FUD!
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.
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
...which was worked around by adding a /3GB switch to the Windows build servers
why, oh why, did they not think to add a /4GB switch? did they learn nothing from the Y2K??? times like this make me sad for humanity :(
Poor dev is poor dev, so I call it like I see it. I will quote myself in response, because clearly, you're being selectively literate. Most memory issues are the direct result of poor programming techniques and excessive code bloat. Any seasoned veteran will tell you this.
But the point at which THAT much RAM isn't enough to build a browser, then as a dev, you need to turn off the computer and relearn how to engineer software by taking appropriate remedial courses.
relearn how to engineer software by taking appropriate remedial courses.
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 ]
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 _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?
My Altair 8080 only has 2K of RAM, you insensitive clod!
now we need to go OSS in diesel cars
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.
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?
Remember the day that number portability became the law and AT&T collapsed almost overnight as everyone fled to Verizon and other carriers? That's what's going to happen the day Chrome really supports AdBlock.
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.
Turkeys raised for meat these days are genetically engineered to be huge beasts. They have grown so large over the years that they cannot even reproduce anymore. The turkeys must be artificially inseminated.
Firefox, likewise, has grown too large for the host system and target system to be the same. Sounds like cross-breeding with a pheasant to me.
Ok, I thought I was going somewhere with this. Would someone please care to assist with this analogy?
Damn kids and their PGO giving double digit perf increases! Get off my lawn!
-1 overrated isn't the same thing as "I disagree".
I like its operating system emulator and default plugin array better anyway. Its html parsing is better too, not that anybody needs that for browsing anymore.
If Microsoft encountered this problem while compiling a windows component they just turned PGO off. End of problem.
Forgive my ignorance, but this wouldn't be an issues in languages that run in virtual machines right? Doesn't the JVM and whatever C# uses do such optimizations while the programming is running? It sounds like PGO takes profiles of the application running and tries to do similar optimizations on it.
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 ?
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...
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
So compile for x64 - who uses x86 anymore :)
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
http://www.michaelv.org/
It's almost ready for 386-enhanced mode and Workgroups(tm)!
It's not as good as Transgaming Wine with Norton Desktop For Windows, however. Norton Desktop should be on every flavor of Wine as it is that much better than anything that could come out of KDE & Gnome. Maybe it'll make an appearance as a minimal footprint with a DirectFB installation.
This is something that just "will be fixed at some point" with firefox and everyone seems to accept it. If the same story came out about IE, all of slashdot would be in uproar about how ridiculous it is and how bloated the whole process and application must be to require so much memory to do such a simple task such as linking... Not sure why i read slashdot any more, seems to just say "its open source, so its just better, no matter what the feature base or the bugs or the lack of support, its just better" which is just blind idiocy...
portfolio
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).
Everything I visit requires NoScript.
Don't need Flash and PDF and DRM modules loaded at the moment but they are there already default.
FireFox is easily replaced by OffByOne browser as soon as someone creates a cross-over plugin to extend it's engine to export engines of Javascript and Plug-ins & Add-ons to 3rd-party programs.
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/
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 the trolly troll is trolling.
Unless you regularly compile optimized builds of Chrome, Opera, Safari, or IE, kindly STFU.
'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.
You can install a 64-bit nightly build of Firefox on windows right now, and work is underway for a 64-bit official release.
This has absolutely nothing to do with the problems of the 32-bit compiler. The 64-bit compiler can compile 32-bit Firefox only for Windows XP SP2 and higher, which would leave Windows 2000 and pre-XP2 users without updates beyond Firefox 12.
Now the next time I see a comment about this from you winspear, it should actually be worth reading.
I'm curious and confused. Wait, a 32 bit version of Windows 7 exist? Just asking. All of the computers that I see in advertisements come with Windows 7 64 bit Home Premium or above.
also, isn't virtual memory the same thing as swap file space (paging memory)?
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.
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.
... how does Firefox manage to get inside a smartphone/tablet and yet be too great for Windows?
Are we talking about two different beasts? If so, why? I mean, what about that old "single codebase" thing?
I've ran Firefox for quite some time now (stable, alphas and betas). It's only just after the 3.0 release where it started getting a bit bulky. They even started to trim it down again before the 4.0 release Now, running 8.0 64-bit on Linux, it's a very satisfactory browser; the best I've found.
Remember, this is Slashdot...where people who use GUIs get abused by cl junkies.... Way to go Slashdot FUD! :D
90% of Slashdotters are either trolls, anal retentive or both. :)
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.
Or, at least, chromium is... its source is about 10x larger than firefox's.
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.
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
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
Yep, this is not an issue of firefox being "bloated" (although it is a bit.) It's that link time optimizations require gigantic amounts of RAM. This isn't even a Microsoft issue specifically. I tried running gcc with the -flto option on my gentoo box (I ended up turning it off because too many packages would not build with it -- not due to OOM (out of memory) but just some other failure.) I'd watch some build use like 2GB or more of RAM, and not for something big like openoffice or whatever. Optimizing compilers tend to chew RAM on certain types of code, and this essentially optimizng the whole binary at once instead of some .c file just makes it chew even more. I'm quite sure I will have to turn off -flto for several builds that will hit the 32-bit addressing limit.
In the same vein -- how the hell does Android need so much RAM to build? Recommendation for Ice Cream Sandwhich (4.0) is a box with 16GB of RAM, and on an 8-core system it takes over 5 hours to build. I can see it taking a long time to build if it's building lots of binaries (which I'm sure it is) but 16GB of RAM? Wow.
Comodo Dragon web browser
http://www.comodo.com/home/browsers-toolbars/browser.php
Secure DNS, too. :)
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).
Reading more of the TFThread says that the last bump, from 2GB to 3GB, was about two years ago; so... probably one more year? Hopefully that will be enough time for them to start shipping 64 bit browsers for Windows and convince all the benchmarking people to use that, so they can stop worrying about 32 bit performance so much...
How is pointing out the flaws in the current release of firefox in any way trolling?
Is what this piece is.
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 ]
If you're used to segmented memory model and "far" pointers, that's not as nasty as it sounds.
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.
Well, sure. Except the code is compiling just fine as of yesterday, after a few changes to it. Tempest in a teapot and all.
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.