32-64 bit
 

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! :D

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).

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?

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.

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:

http://members.shaw.ca/r.sheppard/te...MemoryRead.gif

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:

http://members.shaw.ca/r.sheppard/te...MemoryRead.gif

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. ;)

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

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

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.

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...

:D

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).