# 64-bit computing compared to 32-bit - Not much difference?



## spanglefox (Mar 26, 2013)

Hi!

Now back in the day I remember the apparent "massive" boost in speed of computing transferring from 16-bit to 32-bit processing. I was underwhelmed by 8-bit to 16-bit change though (however that is straining on the limits of my memory and very subjective to judge speed by "experience").

I was formerly excited in anticipation with the change from 32-bit to 64-bit; however, the difference in speed in most 64-bit OSs appears to be minimal! Even when using 64-bit applications. I wondered if I was missing a trick, such as bandwidth limitations of system buses, programme bloat, shared libraries still 32-bit or similar but could not puzzle out why there was virtually no difference.

What prompted me to write this post was that FreeBSD delivered a surprise. I had been building ports for 32-bit when I needed to build for the 64-bit version. Lo-and-behold it was significantly quicker (not ground breaking but definitely quicker)! So I was happy but did make me think why on certain OSs the 64-bit programmes appear to offer negligible speed increases and appear to only exist to offer more than 4GB of RAM?

Also do you perceive your 64-bit version of FreeBSD to be "quicker" than a 32-bit?

(More of a pop quiz question yay or nay).

Thanks in advance


----------



## SirDice (Mar 26, 2013)

There is no intrinsic speed difference. Both 32 and 64 bit instructions run directly on the processor. So they both have comparable speeds. The only differences you'll see are the use of SSE instructions instead of the slow FPU instructions. Which have no use in the kernel and userland tools of FreeBSD.

The 'perceived' speed increase is more likely due to the fact you can address more than 4GB RAM on a 64 bit processor. More RAM improves the reactiveness of the system because it's able to cache more (filesystem cache for example).


----------



## spanglefox (Mar 26, 2013)

Hmmm, I must have not quite hold of the right end of the stick.

I always thought that the speed was determined by the CPU clock speed multiplied by the bits it processes. So for example a 64-bit processor would take half the time to process a set amount of data than that of a 32-bit processor as it can process double the number of bits for a given clock cycle. As in the days of 386 to 486 to 586*/*Pentium. So in theory all other being equal it should be faster?

The actual machines that I compared were two virtualised machines both with 2GB RAM and that's why I was even more surprised to see the better performance. Albeit very "straw poll" in methodology. 

GAH! Well Have just busted over 20 years of mistake! Just Wikipedia'd the 286 (as I was lucky enough to play with one of those). Turns out I had assumed that 386 to 486 to 586 represented 8-bit to 16-bit to 32-bit computing - erroneous (thanks Dad)! - the 286 was a 16-bit processor! So my comparison days of 486 to 586 were incorrect. Just using extra features built into the CPU.

Well I have learnt today. Thanks.


----------



## SirDice (Mar 26, 2013)

spanglefox said:
			
		

> I always thought that the speed was determined by the CPU clock speed multiplied by the bits it processes.


Bits have nothing to do with this. Speed is determined by the clock speed multiplied by the number of cycles an instruction takes. An ADD instruction for example executes in the same amount of cycles on 32 and 64 bit. There is no difference.

Also keep in mind that all Pentium and higher processors have an external 64 bit address bus even though they are 32 bit processors.



> As in the days of 386 to 486 to 586\Pentium. So in theory all other being equal it should be faster?


This comparison doesn't work because they are essentially different architectures and thus have different execution speeds per instruction.


----------



## kpa (Mar 26, 2013)

AMD64 is bit of a special case compared to other 64-bit architectures. It's an extension to the i386 instruction set so many of the operations are actually the same and require the same amount of memory for operands. The result is that the binaries do not tend to be that much larger than equivalent i386 binaries.

As SirDice points out, the 64-bitness refers to only to the natural "word size" of the CPU. It's 32 bits in i386 and 64 bits in amd64. It also implies that the size of pointer variables is 64 bits to allow addressing of the full memory space of 2 ** 64 bytes (however all real implementations stop at 48 bits atm). The bus that connects to memory for example can be wider though, I think it's 128 bits bus for most modern systems.


----------



## spanglefox (Mar 26, 2013)

Yes, I noted that my question was based on flawed logic and that your first post blew the question out of the water.

I am about to dive into the internet to re-teach myself this and to check that I have nailed down the difference between ISA and PCI properly as I think what I was taught on bits/bytes might not be accurate.

Thanks once again.


----------



## phoenix (Mar 26, 2013)

Data bus speeds are measured in "bits * MHz / 8 = MB/s".  This is a measurement of "how many bits can I shove down this/these wire(s)".

CPU speeds are not measured in the same way.  CPU speeds are just measured in "cycles per seconds" or "GHz".

Note also, that you are confusing the two meanings of the ISA acronym:

ISA:  Industry Standard Architecture, the original accessory slot/bus for PCs
ISA:  Instruction Set Architecture, meaning the set of instructions that CPU understands and can process
ISA (the bus) was replaced by VLB, then PCI, (with a brief detour through AGP), then PCI-X, and now PCIe.

And, we're still stuck with the x86 ISA (although it's been extended with amd64).  

Clear as mud?


----------



## throAU (Mar 27, 2013)

X86/X64 and other modern architectures are special also because many of them already had >32 bit streaming instructions and dedicated math instructions to speed up things anyway, like MMX, SSE, 3dNow, etc.

The big boost from 64 bit on the PC architecture is to do with memory addressing.

Accessing more than 4 GB of memory without 64 bit requires use of hacks like PAE (essentially segmented memory model like we had back in the bad old days of real mode DOS).


If you aren't accessing more than 4 GB of memory (well yes, 2 GB or 3 GB or some other lower limit depending on OS) then the performance benefits of 64 bit are more limited.  Yes the CPU has more and larger registers, but as above, many performance intensive tasks already had dedicated 128 bit instructions already and 64 bit operands use up twice as much L2 and L3 cache.

The Pentium onwards has already been able to transfer 64 bits across the data bus at a time - it's like a 386 SX in reverse.  Data bus bigger than the address bus and ISA.



			
				SirDice said:
			
		

> Also keep in mind that all Pentium and higher processors have an external 64 bit address bus even though they are 32 bit processors.



64 bit DATA bus, address bus has only been 32 bit, hence the requirement to use PAE segmented memory model for >4 GB address space until AMD64/EM64T (which then enabled flat memory addressing beyond 32 bit, like protected mode did with the shift from 16 bit addressing to 32 bit).


----------



## SirDice (Mar 27, 2013)

throAU said:
			
		

> 64 bit DATA bus


Oops, yes, I meant the data bus :r


----------



## spanglefox (Mar 27, 2013)

Thanks chaps!

I have put myself "back in school" :stud with this and currently re-reading the theory!

I can see that having a higher bit CPU doesn't necessarily translate into a speed boost directly; due to the ability to "process more bits", and that any speed boost I have seen on my machine is probably due to the 64-bit OS accessing specific speed boosting features on the CPU.

Yes, I did mean the ISA cards. The beautiful bundles of joy that you had to pop the case off in order to change IRQs, etc. It is apparent I was confusing bandwidth 





> "how many bits can I shove down this/these wire(s)"


with computational power. As that is the formula I recognised.

As a sort of spin off (although maybe worth separate thread) how did you learn about computers\FreeBSD? Official course; such as at a university, tinkering with an old machine, self-study, etc.?


----------



## SirDice (Mar 27, 2013)

spanglefox said:
			
		

> As a sort of spin off (although maybe worth separate thread) how did you learn about computers\FreeBSD?


My parents had the brilliant idea to buy a Commodore 64 when I was 12. Got really into it, never did anything else but computers. I am now almost 42, so that's 30 years worth of experience :e



> Official course; such as at a university, tinkering with an old machine, self-study, etc.?


I did take the computer courses when they became available. Unfortunately it was all so new at that time I actually knew more about it than my teachers :\


----------



## Uniballer (Mar 27, 2013)

throAU said:
			
		

> 64 bit DATA bus, address bus has only been 32 bit, hence the requirement to use PAE segmented memory model for >4 GB address space



If the hardware address bus was only 32 bits then you couldn't address more than 4GB of physical memory without external memory management hardware.  PAE is/was an architectural wart that allowed the use of more physical address bits by, I believe, using extended physical page base addresses in the page tables.  I think the first x86 CPU that had it was the Pentium Pro (1995) which had a 36-bit physical address bus long before there were any amd64 architectural extensions.


----------



## phoenix (Mar 27, 2013)

spanglefox said:
			
		

> As a sort of spin off (although maybe worth separate thread) how did you learn about computers\FreeBSD? Official course; such as at a university, tinkering with an old machine, self-study, etc.?



Search the forums.    There's a thread specifically asking "how you got into FreeBSD".    Lots of history in there.


----------



## kpa (Mar 27, 2013)

Endless tinkering with various machines, starting with C-64s and Amigas in late 80s and early 90s. That's how I learned the basics of computers.


----------



## fonz (Mar 27, 2013)

kpa said:
			
		

> Endless tinkering with various machines, starting with C-64s and Amigas in late 80s and early 90s.


Similar story here. I initially started out with a Laser 310 and then a Laser 500, then I moved on to the Sinclair ZX Spectrum (which I still think was a brilliant little thing for its time) and Commodore 64. After that came the Atari 1024 and the early PCs (XT/AT with MS-DOS and initially GW Basic, soon followed by Borland Pascal). Once at university, even though I initially studied physics, I got exposed to C++ and to UNIX (more specifically, HP-UX and IRIX). One thing led to another, I ditched physics for computer science and as they say: the rest is history.


----------



## throAU (Mar 28, 2013)

Uniballer said:
			
		

> If the hardware address bus was only 32 bits then you couldn't address more than 4GB of physical memory without external memory management hardware.  PAE is/was an architectural wart that allowed the use of more physical address bits by, I believe, using extended physical page base addresses in the page tables.  I think the first x86 CPU that had it was the Pentium Pro (1995) which had a 36-bit physical address bus long before there were any amd64 architectural extensions.



Yeah, I thought someone would pick that up, I was aware of the 36 bit address bus for PAE but didn't want to go into explaining it 

You're right, pretty sure the Pentium Pro was the first CPU with PAE support and 36 bit addressing accessible via the PAE extensions.

Most of the CPU stuff I learned was initially out of learning to do quick and dirty bits of inline assembly for a graphics library I was writing for Turbo Pascal back in the DOS days (which meant learning about the x86 segmented memory model in real mode), later I was interested to know what the new CPUs could do and read articles on arstechnica.com.


----------

