rwm

hey people!

i was wondering what exactly the differences between 32 and 64 bit systems are? from what i understand its the memory architecture, 32 bit system memroy is made up of 4 byte memory cells, while 64 bit is made up of 8 byte memory cells, is that right?

how does this relate to performance in software?

hope you can help! thanks!

lectricpharaoh

It's not so much the memory architecture- that will depend on the motherboard and other chips. I believe it's more dependent upon the size of the data bus and CPU registers.

Basically, with a 64-bit processor, you can (usually) operate on 64-bit operands atomically. All other things being equal, it will speed up moving large amounts of contiguous memory. For example, the MOVS instruction on x86 processors can copy one 'unit' of memory at a time. However, it's much faster to do 1000 32-bit such copies than 4000 8-bit ones. Likewise, it would be even faster to do 500 64-bit copies. Of course, this assumes memory operands are aligned (if the processor requires it). To get around this with non-aligned addresses, one can pad the repeated 64-bit copies with 8/16/32-bit ones at either end, as necessary. Optimized routines probably do this already, if you somehow supply them with non-aligned addresses (easy to avoid given that the memory allocation routines tend to return aligned blocks).

Things that benefit from this are applications that move or process a lot of memory, such as software blitters. Also benefitting are programs that require greater numeric ranges and/or precision, as wider data types imply both. On the other hand, many things do not benefit significantly from the move to a 64-bit architecture.

All in all, you're not going to see a linear performance boost in most cases. There are many other factors that will come into play, and even for memory-bound processes, remember that modern CPU speeds far outstrip those of RAM in any case. This isn't to say there won't be benefits- there will, most probably. There will also be drawbacks. Most processors prefer memory to be aligned. Data is almost always aligned by your compiler, and code sometimes is as well, especially code that's been compiled with speed optimizations enabled. What this means is that both are liable to take up more space, sometimes significantly more. Sometimes, this can have negative performance implications in itself (overflowing cache lines more often, for example).

__________________
And once again, Probability proves itself willing to sneak into a back alley and service Drama as would a copper-piece harlot.
- Vaarsuvius, Order of the Stick

rwm

Hey!

thanks for the reply!

true!

so basically the biggest benefit would be for a system involving huge amounts of RAM, and provided the memroy is aligned in a cache friendly manner?

DaWei

Nice explanation, lectric. The characterization depends on the size of the external data bus. For instance, National made a family of micros called the 32008, the 32016, and 32032. They were 8-bit, 16-bit, and 32-bit processors. All had 32 bit registers and busses internally.

Whether or not alignment is required is a hardware design decision.

__________________
Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code.
Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers

lectricpharaoh

That's my understanding (with the minor nit that the cache is a separate thing altogether). But as DaWei points out, alignment is dependant upon the hardware. It's essentially a cost-cutting measure; for the architecture to provide addressing any size operand (within what the CPU can address, generally 8/16/32/64-bit units) at any address often requires that it be more complex (and hence, costly). It's often more cost-effective to 'waste' a bit of RAM instead.

Alignment is often expressed in terms of the size of the data. For example, on many modern architectures, a byte can be addressed at any location without penalty (cache issues notwithstanding). A 16-bit word (x86-centric term, I know) should be aligned on 16-bit boundaries, and a 32-bit doubleword on 32-bit boundaries.

Now for a couple of pics. First we have an aligned 32-bit read:

Notice how it grabs all four bytes in a single operation. Now, lets say we want the 32-bit value at address 1, instead of address 0:

See how there are additional operation involved? It has to read from two separate 32-bit memory locations, shift both of them, then join them together.

As an analogy, let's say you want to read eight consecutive bits. If they are all part of the same byte, then it's no problem- you just read that byte. But imagine these bits straddled a byte boundary; you'd need two reads, two shifts, and a bitwise OR to combine them. It's a similar thing for reading bytes that straddle an alignment boundary.

The reason this is a hardware thing is because the hardware typically does it in a silent, behind-the-scenes manner. The shifting can typically be done in the same step as the read (hence why one can often read a byte at any address without penalty), but when two adjacent locations must be read, shifted, and ORed together, there will be a lsight performance hit. As long as you're doing this kind of thing in a tight loop, however, the impact should be minimal.
Yeah, when I was younger, my first computer (first that was actually mine, not the first in the household) was an Atari ST. This was based around the Motorola 68000, which had 32-bit registers, a 16-bit data bus, and (I believe) a 24-bit address bus. It's rather dated by today's standards, but it was a damn sight better than the 80286 machines that were common back then.

Don't get me started bitching about segmented memory architectures; I'll use up all big_K's bandwidth.

Yup, it's all about the all-mighty dollar.

__________________
And once again, Probability proves itself willing to sneak into a back alley and service Drama as would a copper-piece harlot.
- Vaarsuvius, Order of the Stick

crawforddavid2006

Screw 64 bit, 32 bit has been good enough for me for as long as i can remember.

__________________

lectricpharaoh

Edit time expired, but obviously, I meant to say 'not doing this kind of thing in a tight loop'. Oops.

__________________
And once again, Probability proves itself willing to sneak into a back alley and service Drama as would a copper-piece harlot.
- Vaarsuvius, Order of the Stick

DaWei

Yeah, and people your daddy's age or grandaddy's age said "screw 16 bits, 8 bits has been good enough for me as long as I can remember". What a crock.

Hardware access on any (byte) boundary doesn't require any shifting. Accessing on multiple-byte boundaries just requires less decoding logic.

__________________
Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code.
Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers

rwm

wow, thanks man! those are really good explanations!

makes a lot more sense now!

ta!

crawforddavid2006: why would you say that? that sounds dumb as hell...

Jimbo

As DaWei pointed out, 32-bit is sufficient for most everything today except specialized applications. Currently the only real benefit for the average poweruser or less is the extra RAM; then again, how many people have 4GB+ that they really need? (Well, I certainly could use it, but I get by with 2GB.) Whether or not 64-bit computing will become needed over 32-bit for the common household software any time soon is doubtful; however, marketing strategies (OMGZ64BitIsSoooKEWL!!!) don't always follow the most logical approaches, so we'll probably see a lot of shift in that direction (or at least support for both).

__________________
<insert disclaimer here>
<insert shameless plug for Visual Studio here>