That means Firefox will still be limited to 4 PiB, which I'm sure it'll be reaching by the release of Firefox 12,458 next year. We need a 128-bit version.

Naw...
it is two things. Cleaner code and the lack of 32bit library cruft in a system.
However plugins like flash and even Java32-.vs.-Java64 make me think
that well flash is crud and Java not as portable as it should/could be.

The 64 bit branch of FireFox and loved it, it was much faster. Some recent update broke compatibility and I have to do a total uninstall and then reinstall while backing up every Firefox thing elsewhere to restore, since it uses the same profile, etc.

Too lazy to work out the issue, in other words.

But if you have a nice fast 64bit machine, try Wtaerfox, you'll probably love it. Unless it sucks now.

Probably because flash, java, and other plugin makers are so slow to move to 64 bits. Not to mention many out there feel a browser should not use more than 4 gigs of ram and is a light text and graphics reader. Not a minature operating system running complex ajax applications

Java is 64-bit since a long time. Flash also has a 64-bit version on windows for quite some time. As for Java... it's a PITA to install 32 and 64 bit versions at the same time. Amazing how Oracle messed that up. Going 64-bit only however makes this problem disappear: the 64-bit version is all you need and there are no more clashes. And it gives an immediate speed bonus as well, as 64-bit simply is faster.

64-bit isn't just simply faster. It's sometimes/often/usually faster depending on what you do, but it is ALWAYS larger in memory and disk space usage, and plays less well with other applications (Cache size overruns caused by the larger size).

The fact that the pointers use an extra 4 bytes is a negligible detail because the L1 caches are huge in relation to those 4 bytes. You would need a very large amount of pointers within the cache to have any sort of measurable effect, so large that following even small percentages of them (why are they in the caches if you arent using them?) will always cause significant L1 thrashing.

I'm glad you admit you don't know what you are talking about. I wish more people who didn't know would admit it right up front like you did.

The fact that the pointers use an extra 4 bytes is a negligible detail because the L1 caches are huge in relation to those 4 bytes. You would need a very large amount of pointers within the cache to have any sort of measurable effect, so large that following even small percentages of them (why are they in the caches if you arent using them?) will always cause significant L1 thrashing.

The fact that pointers (and anything dealing with size or offset) uses DOUBLE the size, and isn't negligible. It's effectively halving the size of the caches (total size, line size) in terms of the number of pointers/ints that they can contain.

But an even harder argument for you to try to refute is that Intel isnt stupid. The cache parameters (total size, line size, number of sets, for each level of cache) are optimized for 64-bit computing on their 64-bit processors. Intel didnt choose a 64 byte L1 line size willy-nilly. Intel didn't choose 32KB of L1 data willy-nilly. Intel didnt choose 8-way set associativity for their L1 willy-nilly.

I'm not going to refute that, nor is that directly related. However, as a side note that I don't want to get tied up in, I wi

But going to 64-bit on an x86 machine also doubles the number of registers, as well as introduces any number of extra instructions that can speed things up. If you aren't getting a significant speedup with a 64-bit build, then something is usually wrong. Like you are casting to a 64-bit integer, but are still treating it like it's 32-bit.

Plus your benchmarks mean nothing with FireFox -> the people behind the builds have put that much more effort into optimizing it for 32-bit over 64-bit. It's

Yes, you have twice the number of registers in 64-bit, however, there are some performance penalties for using them (prefix ops), and I'm pretty sure that the register renaming that is done really makes that a rather moot point except for the prefix op penalty still applies if you try it. You are going to find a mixed bag of performance characteristics trying to use them unless you are really really careful, and most compilers aren't, and most apps aren't going to hand code assembler to get it right.

Too bad many of my clients have Cisco connect which only works with java 1.4.2 and IE 6/7 or some $1,000,0000 ERP abomination-ware tied to Oracle financials that only work on Java 1.4.2, not java 1.4.1, not java 1.4.3, but java 1.4.2.

These machines need to keep being reimaged from infections and as a result can't leave XP or IE 7 behind. Sometimes Firefox works believe it or not in quirks mode with these old java releases. The new ones are not compatible as they follow w3c and not the corporate standards MS

Not to mention many out there feel a browser should not use more than 4 gigs of ram and is a light text and graphics reader.

Having a >4GB footprint is not the only reason to move to a 64-bit address space. As more software becomes 64-bit, those legacy 32-bit apps become more of a problem, both in terms of longer application launch times (because the 32-bit library stack that it uses isn't loaded initially) and in terms of added memory pressure (because of all those unnecessary libraries loaded into RAM).

Probably because flash, java, and other plugin makers are so slow to move to 64 bits. Not to mention many out there feel a browser should not use more than 4 gigs of ram and is a light text and graphics reader. Not a minature operating system running complex ajax applications

Pale Moon is also quite good and has a 64bit version although they compile their for newer CPUs (Athlon64, P4 and above) but if you are running 64bits you probably aren't using an ancient CPU anyway.

But the FF numbers have been dropping and its from nothing but shit like this, being arrogant and not listening to their customers. After all that is EXACTLY what they are, for without them Google wouldn't pay Mozilla for the search rights and the whole company goes down the drain so its time they started actively listening to their customers instead of pissing them off.

This is one thing we have so much better than we did when FF first came out, it no more "use this or get stuck with IE" nonsense, no more having the entire web coded for IE quirks, now we have this great bounty of choice so if any company refuses to listen to us we can just go somewhere else without having to jump through hoops or deal with a crippled web experience. Just off the top of my head I can name Chrome, Chromium and Comodo Dragon in the Chromium based camp, FF, Pale Moon, Waterfox,Kemelon and Comodo IceDragon in the gecko builds, then you got the more "one offs" like Safari and Opera, that's ten browsers that will ALL render the web just fine, so if the numbers for FireFox go down they have nobody to blame but themselves. maybe next time instead of just pulling a boneheaded stunt how about actually asking your customers first, huh?

I can see where Mozilla is coming from as they have limited resources to double the development efforts for a so called free product. I wish Mozilla would invent Mozilla search to go head to head with Google, but they do not have the revenue for such a risky maneuver.

Look, it's perfectly appropriate that deprecated hardware should run deprecated software. Besides, Mozilla could continue releasing security updates for 32-bit; I just don't think they should waste effort on new features (especially at the expense of 64-bit), that's all.

Anything using any math is a LOT faster on 64bit than on 32bit. I switched to 64bit back in 05 when XP X64 came out (one of MSFT's best OSes, right up there with Win2K and Win 7 in my list of top notch OSes) and even though I didn't have 4Gb at the time you could really tell a difference, I was gaining on average 10%-15% thanks to having the larger registers.

As far as killing 32bit? If MSFT wasn't currently run by retards they would have made ALL versions of Win 7 come with XP Mode VMs and could have kill

You win the comment of the year award. The tech industry needs to realize that perpetually following or wanting to be Apple is badly damaging all of us. I wonder if it's too hard for them to figure out a design that is not Apple, is them, but one which is clean, pretty, and works.

Actually you'll probably laugh, but guess what my Win 7 desktop is? Vista Black, the only thing i liked about Vista was the Vista Black without all the see-through crap so I simply found a Basic theme that would give me Vista black and that's on everything.

And again if MSFT wasn't run by retards this could be an easy fix, simply GIVE THE USER CHOICE. You should have the choice in Win 7 to have it in XP Blue, Vista Black, or 7 Aero, and Win 8 should have those options along with 8 Metro. That way YOU could

Honestly, who isn't running a 64-bit processor these days? Being limited to 4GB of RAM is a bigger issue than "OMG, it's issuing slightly larger instructions on a 4Ghz processor with a 240 GB SSD and 32 GBs of RAM! That's like 0.00000000000000000000000000000000000000000000000000000000000000000001 less efficient than a 32-bit instruction, and is so fast that no one even notices!"

I feel like we're playing tug of war with the Windows XP crowd, who still want to run the latest FireFox, but aren't willing to upg

I normally use SeaMonkey (as the least obnoxious of the Moz family) but when some website expects yesterday's FF build, I use Palemoon -- the only FF incarnation I can stand. -- Their general memory piggishness seems to be a cache-handling bug, probably a side effect of an hour of use generating 4000 directories and 500 files (not a typo, there are bunches of empty folders) and never cleaning up after either. I found if I clear cache every few minutes, the galloping memory usage doesn't happen.

I do not, for the life of me, understand why FireFox is so hell-bent on 32-bit versions.

I do not for the life of me understand this blind push to 64bit when there is no demonstrable speed improvement.32bit software on a 64bit platform is not measurably slower for the tasks that a browser needs to do.

It may be a blind push to 64-bit, but when AMD and Intel debut some 128-bit CPUs for mainstream computing, which may leave some 32-bit support out just as much 16-bit stuff was left out of 64-bit, obviously there will be a need for at least a 64-bit version of the application. Then you'll see a push for a native 128-bit version. Look at what happened with the switch from Windows 9x/ME to XP. Microsoft put many 16-bit applications on life support after XP came to the desktop to replace the 9x/ME versions

... that do not need to use either real mode or virtual 8086 mode in order to execute at any time... Real-mode programs and programs that use virtual 8086 mode at any time cannot be run in long mode unless they are emulated in software...

Speaking as someone who's been writing software since 1988, please enlighten us with more information on your background as a programmer. I strongly suspect the the GP was right in positing that you simply don't have the faintest idea what you're talking about.

I do not for the life of me understand this blind push to 64bit when there is no demonstrable speed improvement.

Part of the problem is all Firefox tabs and windows are part of the same process, unlike IE (and I believe Chrome). So, if a misbehaved AJAX app in one tab uses a gig and a half, every browser window becomes unusable. If FF were 64-bit, then it could use the 8GB or 16GB found in most new machines to mask the problem.

With the current Firefoxes, you can go to the help menu and see what tabs are using what memory from the 'troubleshooting information' item. then you can see a rogue tab has gobbled all your ram, and close it. That's a solution.

What? 64-bit image routines chomp 32-bit image routines! This is a known fact! And that's just the beginning!

And it's the fact that memory is limited under 32-bit code to 4 GB of RAM that we really care about. FF moves like a pregnant yack when you have 20 tabs open, and has the memory usage of a 700 lb sumo wrestler at an all you can eat buffet.

> I do not, for the life of me, understand why FireFox is so hell-bent on 32-bit versions.

Same here. I've been running Waterfox for some months now on a low-end 64-bit desktop PC. It's very fast, and I've not had any plugin or extension problems. Given what a pig Firefox is for memory (and to be fair Chrome and the other browsers too) if there is one application that should drive 64-bit technology it should be these damned web browsers!

Waterfox is just Firefox built as 64-bit with some compiler switches and a name change (required by trademark guidelines). It's not a fork and there are no additional bug fixes. It has all the bugs that Firefox does when compiled as a 64-bit binary. You're far better off sticking with Firefox 32-bit which works just fine under 64-bit Windows.

That's true of any decent compiler targeting x86-64 since all x86-64 processors include SSE2 support. One of the nice things about targeting x86-64 is that you get a nice feature set that you don't have to detect support for at runtime and maintain a multiplicity of code paths to take advantage of features. If you know a feature will be there, it reduces complexity both in source and the compiled output.

Not really. Look at their own benchmarks [waterfoxproject.org] - at best performance is roughly 15% faster, some cases slower. They also commit the cardinal sin of using benchmark charts that do not start at zero, #1 on the list of "how to lie with numbers."

The N280 is also 32-bit only, so is the ULV celeron used in the original Eee PC. Intel didn't release a 64-bit capable netbook atom* until december 2009.

Now granted, the Z and E series Atoms do not all support 64-bit, but they are not intended for 'regular' computers.

It seems that Z series atoms were intended for "ultra mobile PCs" which afaict were even tinier than netbooks but still ran regular PC operations systems. Afaict ASUS did put a Z series atom in a netbook too.

If Mozilla does not want to double the work then just focus on 64-bit. Besides a few Vista users who went to 7, I do not know anyone who uses the 32-bit version. Usually they tell me some driver or piece of software is not compatible. Most cases running it in XP mode is better nowdays and by 2014 that hardware will very old!

Maybe release the long term version on that day as the last 32 bit version for 1 year? By 2015 no one should be runnin

the specs and requirements hasn't changed for MOST applications and tasks since late 2006 (coincides with vista oem release). even the next version of desktop windows is expected to have similar requirements... a dual core athlon from 2006-7 with 2-4gb ram is enough for most people (hard core gamers, 3d graphics artists, and engineers are not 'most people').... and is about the same speed as lower-end desktops today (some "new' ones are actually slower). age of hardware,

It's good to see that someone is being held accountable here. Benjamin Smedberg creates a shitload of negative publicity, pisses off a proportion of dedicated testers and he:A. Gets a promotionB. Is removed from positions of responsibility because he demonstrates poor judgementC. Nothing happensD. Gets a pay increase.

Answer = CCome on guys at least make him wear a T shirt for a month that says, I must not override the recommendations of others in relation to 64 bit builds.One of the key problems in organisations is that people aren't held accountable for poor judgement, or at least a running sheet is not maintained. Ben will probably continue to be promoted even through he has demonstrated that he has a fundamental lack of connection with what end users want. There is obviously something wrong occurring in the firefox mozilla groupthink and yet nothing is being done.

There is obviously something wrong occurring in the firefox mozilla groupthink and yet nothing is being done.

That's the feeling I have as well. I don't use 32 bit desktops any longer. Actually haven't consistently used a 32 bit desktop in four years. To somehow not be aware of the behavior of real users is a huge fail.

And lets not indulge anymore '64 bits isn't necessary' tripe. People that don't understand why key software must adopt the native ISA of a system and avoid backward compatibility kludges need to stop talking about this.

Anyhow, I just upgraded my main personal desktop hardware and reinstalled my retail Win 7 OS, in addition to Linux. I installed Firefox out of habit but I haven't bothered to reacquire my usual cohort of extensions... I don't use it anymore. Chrome is superior in every way, with the sole exception that noscript is better than scriptno.

Mozilla is repeating Netscape history. Then as now, leadership is the problem.

That's the feeling I have as well. I don't use 32 bit desktops any longer. Actually haven't consistently used a 32 bit desktop in four years. To somehow not be aware of the behavior of real users is a huge fail. (...) I don't use [Firefox] anymore. Chrome is superior in every way

I think they know their users perfectly, even slashdotters seem to be clueless that they're running 32 bit software under their 64 bit OS.

Haven't these people heard of ASLR [wikipedia.org] and heap spraying [wikipedia.org] Do they not understand the concepts?

Without 64-bit, you have two huge security problems. The first is that there simply isn't enough address space to randomize well. Attackers can guess things. They guess right often enough that the effort is worthwhile. The second huge security problem is that the address space is easy to fill with code-equivalent data for a ROP [wikipedia.org] attack. Actually, with Firefox you could even use real code [wikipedia.org]!

Using a 32-bit browser in 2012 is kind of insane. It's near-complete security FAIL.

IE 10 32-bit has ASLR and heap spraying protection sandboxing right in. I think Chrome does as well but someone can correct me on this if I am wrong. Infact, the only thing Windows 7 64-bit has that the 32-bit does not is signed bootloaders and drivers to prevent rootkits.

ASLR has been part of 32-bit operating systems for years since Vista.

If someone knows the ram address of a particular dll they can target it anyway with a poke regardless of the bitness. You can still spray on a 64 bit system as well. It j

It barely works. There simply isn't enough address space to make it effective. This is like having a door using a 1-pin lock instead of a 7-pin lock. Picking a 1-pin lock is trivial.

You can still spray on a 64 bit system as well.

You can't usefully spray on a 64-bit system. To be useful, your spraying needs to cover a significant portion of the address space. (else you are unlikely to hit it when you trigger the bug) It also can't require more memory than the system has, and it can't need to run for months.

So if I had 4 gigs of ram it would not matter if the OS is 32-bit or 64-bit.

Yes it would. The amount of physical RAM has nothing to do with this issue. The "P" in PAE stands for "physical", which only matters to the hardware and the OS kernel. A 32-bit app will never be able to see more than 4 GB, even if you have PAE or a 64-bit OS.

On a 32-bit system, every process gets a 4 GB address space. (the OS may steal 1 or 2 GB) You may have only 512 MB of RAM installed, or you may have 16 GB of RAM installed, but every process still sees 4 GB. If the process uses more memory than the amou

Since only the most powerful servers have it I see it as offering no real advantage. XP users use PAE to go around the 4 gig limit hack anyway. So if I had 4 gigs of ram it would not matter if the OS is 32-bit or 64-bit. The memory addresses would be the same. If I had 8 gigs of ram I would have it extended if I ran XP with PAE so I would have an identical amount of memory addresses in either case.

Leaving aside the fact that recent desktop versions of 32-bit windows (starting with XP SP2) are gimped to only allow 4GB of physical address space even when in PAE mode it's not physical addresses that matter for this attack, it's how the size of VIRTUAL address space compares with the amount of ram.

Suppose that the hacker has an exploit that lets him make the program run some bytecode from a address he specifies without applying security checks to it but can't find out before running the exploit where any

If I ask you to guess a number that I have picked, would you rather the range be 1 to 100 or maybe 1 to 100 million? You can reliably guess one of those if you try for a bit, but the other is kind of hopeless.

The only time a sandbox should be a way of life is when you can't fix the bugs.

Even if you had a hyper-intelligent alien life form to write bug-free code, the attacker still has a chance. We're running the code on hardware without ECC RAM or even parity bits. Every now and then, the code will jump to the wrong address. It happens.

I've been using 64bit nightly since the idea of dropping the builds was mentioned in bz. There was a big debate and a bunch of tech news sites picked up the story and now the latest is that they're being "restored". But the 64bit nightly builds never stopped! I'm sure this story is just to get everyone to STFU about it already.

Good news. Even if it doesn't result in 64 bit final products soon it should provide more material for the Waterfox project to develop upon. As long is there is developer support from Firefox for the 64bit the onus is on the developer advocats of 64bit computing to prove that it can show a significant enough performance enhancement to be taken seriously and pushed to mainstream.

While I realize that there are theoretically 32 bit versions of Vista, Windows 7, and Windows 8 available, I have never seen one installed on a system. For the Mozilla team to say there will "never" be a 64-bit build for Windows is an asinine and bass-ackwards approach to maintaining compatibility with the OS.

If it's the plugin-providers causing the problem, then they deserve as much "Boo Hiss" as Mozilla does.

Let's try to keep up with the times. 64-bit Windows has been stable and standard for years!

1. XP is still one of the most popular if not the most popular OS in the world. 64-bit XP on the other hand is non-existent.2. 32-bit vista and seven were used quite a lot in older computers that had less then 4GB of RAM. I have a netbook bought a couple of years ago that caps at 2GB that uses 32-bit seven for example. It works fine.

Either make a portable website that works on every computer or mobile device users have. Or make a native app which, if your wish, can make extensive use of server-based HTML while still incorporating your "plugin" code. But exposing users to overhead, crashes and security issues of your custom code when your application is NOT running is indefensible.

What I would like to see is the web go back to geocities. Websites never consumed any significant resources, RAM/CPU consumption was most likely due to a bug, than website (like Slashdot) itself consuming it.

32-bit for desktop systems is outdated since more than a decade ago, and a complete anachronism for everything except backwards Windows. But even Windows caught up five years ago.

Somehow I have the feeling that the hostility of the closed and primitive Windows platform locks Windows developers in some kind of mental box, that causes them to be very limited in their thinking, when it comes to how to approach developing things or moving to 64-bit for example.I mean, the damn thing doesn't even have a package manager. (No, Windows Installer doesn't even remotely count.)

Difference is the win32 environment is not free. As a result customers tend to hang on to old obsolete systems. As a result older incompatible and backwards operating systems still need to be supported like Windows 98. If you use dos like stuff in your windows 98 that is also compatible with XP, then it probably wont run on 7/8. Unless you run the 32-bit version of course. You couldn't have just made it XP compatible only in 2006 (the version most customers use) as people still had win98.

Most processors do but typically XP is 32-bit. Given it has a huge market share for such an old OS, one might guess say 30% of machines. According to Steam survey [steampowered.com] Windows 7 (32-bit) 14%, XP (32-bit) 10%, and that's gamers.