Alan McKinnon wrote:
On Monday 10 March 2008, Dan Kegel wrote:
Geoff Streeter <geoff@xxxxxxxxxx> wrote:
Funny, my view is the exact opposite. I first used 64 bit on a Dec
Alpha in about 1993. I have been wondering ever since why anybody
would want to cling to 32 bit.
Abstractly, I agree. But there are so many gotchas and so little
payoff for desktop users in the switch to 64 bits that it seems
premature, at least for people who don't want to help ferret out
the remaining problems.
I had better declare my bias; I implement an APL interpreter. A
significant number of my users are bouncing off address space
restrictions and are being held back because their users are
constrained to use 32 bit windows as a platform.
Sure, your users have a real reason to go 64 bits. The
average desktop user doesn't.
I have to say that I am with Dan on this one. Off the top of my head, I
can't think of any *desktop* app that requires the full addressing
capabilities of 64 bit. Come to think of it, I can't think of any
desktop or notebook *machines* that have more than 4G of RAM installed.
Plus, there are a whole slew of desktop apps that just don't work right
on 64bit systems - starting with flash.
In the general case on x86 cpus, 64bit desktops tend to supply the user
with a whole large set of brand new shiny problems while solving no
existing ones. There are always exceptions of course - sometimes I
would like to demo two certain column-based database and an abstraction
layer along with reporting tools, ETL stuff and have the whole lot
delivered to the user from JBoss. Sadly, this lot will never run on a
notebook, so the demo consists of dragging several machines in boxes
off to the client's premises. But that's an obscure case...
Servers - different story. I'm very close to the point where I simply
will not support new apps deployed on new 32 bit systems. Current needs
in *this* area for the majority of customers I have to deal with
already go beyond what 32 bit can deliver.
This isn't to say that there is something wrong with 32 bit code - there
isn't. It's just that the code lying around for desktop use is written
for 32 bit and also satisfies current and foreseeable future needs.
I don't think history supports this view. If my memory serves, and I am
old enough for it to be unreliable, Bill Gates in the mid '80s said
"640K is enough for anyone", then a combination of the 80386, Pharlap
and Metaware High C made the statement seem stupid. There is a sort of
corollary to Moore's Law that means that the memory requirements of
applications grow at about a factor of 2 every 18 months. So that 640K
can now be multiplied by 2^16 ish. This is approximately 4GiB. Most 32
bit opsys deliver about 2GiB of address space to the program. By
fiddling a bit you can get some more (on AIX up to more than 3GiB). So I
would argue that we are already at or about the limit of 32 bit address
space for applications.
I have not noticed the problems with 64 bit that are described. I use
XP64 at work and the only real problem has been that some apps come with
16bit installers which won't run. I have to be a bit selective with
hardware to ensure that I get 64 bit drivers. I have to be a bit
selective with hardware for Linux for similar reasons, this is much less
true than it used to be. I use AIX, Solaris(SPARC) and a few Linux
distributions, none of them have given me any issues about running 32
bit apps on 64 bit opsys. These things were sorted out by the AIX and
Solaris guys in the 1990s. Applications written for Microsoft Windows
are more suspect. I got an MSDN library that refused to use the 64 bit
version of IE, I had to force it to use the 32 bit version. We have put
Vista64 on laptops that then did horrible things on hibernation. 64 bit
Linux has been fine.
Dig around the net for the growth rates of share trading quotes. There
is an APL like language called K that targets this area. They will scare
you. I accept that the share trading markets are lunatic and these sorts
of growth rates only demonstrate that lunacy. However, there are real
systems that target these environments and have to handle those data
volumes.
I repeat my comment that 64 bit is about address space rather than real
memory so the present boundary of 4GiB imposed by motherboards aimed at
desktops and laptops is not an argument for sticking with 32 bit. This
is not to say that real memory is not important. We have customers with
96GiB of real. Those motherboards will be hosting 16GiB in two years
time and our customers will be using machines with 256GiB by then.
Keeping this on topic for this list; I am really looking forward to a 64
bit winelib.
Geoff Streeter
