John said:
Is there any piece of modern hardware that would not work (out of
the box using the included drivers) with my 32-bit Windows XP?
How about software?
I am wondering if "64-bit Windows" is just technobabble marketing
speak.
Thanks.
To use an unfortunate analogy, the "dimensions" of computers are
like the plumbing in your basement. It would be simplistic to say
all the plumbing in the basement was 1/2" or 3" drain pipe. There are
all sorts of plumbing functions down there, each with their own dimensions.
The "bit-ness" of Windows, addresses the processor instruction set.
If you run a 64 bit Windows OS, a lot of the OS will be native
and the instructions used will have exactly 64 bits. But some parts,
will continue to be 32 bit. The OS doesn't run in "pure" 64 bit mode,
and both 64 bit instructions and 32 bit instructions can be accepted.
At program launch, there are two Program File folders, where
32 bit and 64 bit executables can be separately stored. An example
of this, would be Internet Explorer web browser, for which the user
has options to launch either a 32 bit edition or a 64 bit edition.
(Why there are two versions, is a puzzle to me, and perhaps it
has to do with plugin compatibility issues.)
Now, what does 64 bit enable. It enables an extended addressing of
memory. If the machine has plenty of memory, a single program can
get to use all the memory on the computer, if the program is a
"pure" 64 bit application and the OS is also 64 bit. So if you
installed 16GB of memory, fired up Photoshop and worked on a
poster the size of a football field, then a pure 64-bit copy
of Photoshop could use all the memory. If I had an older
version of Photoshop, I might be limited to using no more than
2GB or so, even on the 16GB machine.
http://msdn.microsoft.com/en-us/library/aa366778(VS.85).aspx
If you run a 32 bit executable in a 64 bit system, there is a limit
to how much memory the 32 bit program can use. Perhaps I'd have to
run four or eight graphics editing programs, each working on a
smaller poster project, before all the system memory would be in use.
*******
It's true that hardware can have 32 bit and 64 bit aspects to it.
64 bit wide PCI cards existed, back when there was nothing but
a 32 bit OS available. The 64 bit width in that case, doubles (or more)
the data transfer rate. That has nothing to do with instruction set
on the processor. It's more like SATA I versus SATA II versus SATA III.
Addressing on PCI cards (on the PCI bus), can be 32 bit or 64 bit.
Some PCI cards accept "double address cycles" for example, which
means addresses larger than 32 bits can be handled. If all the "plumbing"
next to the card is similarly endowed, then I presume the card can reach
into more places, or an application can address a larger range of stuff
inside the card. The "double address cycle" thing means, an up to 64 bit
wide address, is transferred as two 32 bit halves, then recombined
in the silicon before being used.
In the past, some OSes have artificially kept add-in cards and
peripheral chips, below the 4GB mark. That may include the allocation
of buffers for DMA, or the base address address (BAR) that the card uses.
The PCI cards, might never get to see or to use, a double address cycle.
If a 64 bit system has an IOMMU, it makes it possible to deal with
hardware (PCI cards and their drivers) that don't deal well with
addresses above 4GB. If a computer doesn't have an IOMMU, then
"bounce buffers" are used by the OS, which involves memory to memory
copies to solve perceived problems. The IOMMU is a seamless way to handle old
hardware. If your 64 bit OS is forced to use bounce buffers, there
could be an extra (small) compute load if your peripheral has a high I/O rate.
Summary:
Question: Why do we use 64 bit OSes ?
Answer: As of today, it allows the usage of the greater than 4GB of
memory we bought for our computer. Other aspects of 64-bit-ness
are currently noise, just like the noise in the answer above.
All the technical details have been handled for us.
Plug and Play...
*******
If you use pure 64 bit executables on your new 64 bit OS, you have
the possibility of using all the memory for a single program. This
can have advantages for large computing problems, which need a lot
of memory. An example of such a program, is a program used for
logic design, synthesis and simulation. Back when only smaller
systems were available, max hardware configs were being used for
such work (stuffing 4GB memory in the box, before big DIMMs
were popular). And the PC memory architecture means such programs
run like molasses in winter. While the quantity of memory has
grown, and the burst transfer rate with it, the number of
memory transactions you can do randomly per second, hasn't really
grown along with it. Logic simulation has a random access pattern to
it, which PCs hate. You can have your 16GB of memory now (so your
whole compute problem fits in memory), but it still takes weeks
for your simulation to complete. Many many cycles on the processor
are wasted, as it waits for blocking memory calls to come back.
When a program does sequential memory accesses, you get good usage
from the memory. It looks like this. Nice, close to back to back
bursts. Programmers are encouraged to write programs, with this
characteristic. The computer looks heroic when a program does
this.
-----------XXXXXXXX-XXXXXXXX-XXXXXXXX-XXXXXXXX-------
When the problem your computer is solving, makes random accesses, the
pattern starts to look like this. The CPU is starved for stuff
to do, and the computed bandwidth for the memory looks terrible.
-----------X--------X--------X--------X--------------
Not all aspects of computing have improved at the same rate,
as you know from the state of magnetic disk drives. Where is our
parallel read/write disk head ?
*******
There is one other area, where 32 bit and 64 bit makes a difference.
I was investigating the math behind finding Mersenne Primes (as
captured in the Prime95 program).
Instead of using Prime95, you can run your own code. I found a
program to do this, and looked at improving it. (It's a short
program, using a naive approach, versus the tons of code and
careful hand optimization and usage of assembler code as found
in Prime95.) I didn't even come close to matching Prime95.
First, I compiled with a 32 bit library for big numbers. When you
use such a library, it allows arbitrary precision arithmetic. In
this case, there might be 40 million digits in the numbers being
manipulated. The library allows you to do things like add two
40 million digit numbers together.
When I recompiled and set if up to use a 64 bit version of the
same library, the program ran 65 percent faster than the 32 bit.
Which is a pretty significant improvement, but not the factor
of thousands I was looking for (I was trying to see how hard
it would be, to do better than Prime95).
Regular applications, don't see a 65% improvement. In this case,
64 bit arithmetic means it takes fewer arithmetic operations to
work with the 40 million digit numbers. Regular programs don't
have such a dependence on data width when they run. If you're
writing a calendar program, and counting the days in a month,
a 32 bit container for the counting works about the same
as a 64 bit one, with no additional performance to be expected
in the calendar program.
Some 64 bit programs run 10% faster, and some run 10% slower.
So you would not go into the acquisition of a 64 bit OS, with
the understanding it'll double the speed the program runs at.
The improvement is quite variable. And may even be dependent
on the laziness of the programmer (no optimization, just a
recompile).
HTH,
Paul
