[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: 32 or 64 bit

> I've never heard any claims or evidence that 32/64 bit ODs have any 
> impact on the harddisk access times. Someone please correct me if I'm 
> wrong but this is not the reason people use 64 bit OSes.

None at all on a typical system. Disk transfers are 16bit for ATA anyway
(32bit PIO as a special case we don't normally do but some day I should
add for the drives that do it), and DMA is used for all real disks today.

> As far as I am aware there are two reasons.
> 1. For technical reasons, a 64 bit build is normally a bit faster than a 
> 32 bit build, just due to compiler options. For normal desktop usages 
> its unlikely you would notice a difference, but it can have one if you 
> do heavy number crunching.

Its a bit more complicated. Generally speaking on systems user 64bit
binaries are slower than 32bit as they are bigger. PC (x86/x86-64) is a
bit different as x86-64 is very compact and also because it doubles the
number of usable registers in the instruction set which is a huge win. So
typically its about 10-20% faster. Desktop performance is usually bounded
by video performance (lots of opportunity for the X folks to improve
performance left) and most of the time the box is idle anyway so being
able to display an icon 20% faster isn't a big visible hit.
> 2. 64 bit OSes, have a larger memory address they can access. With 32bit 
> OSes the largest amount of memory a single process can use is 4G I 
> think. With 64bit this problem goes away. You may wonder why any single 
> process may need that much ram... Its true not many will but some tasks, 
> like large databases or image processing can get that high.

Even more importantly - the kernel can address more than 4GB at a time
without doing expensive memory management unit updates. That makes a very
big difference above 4GB and quite a big one above 1GB RAM (the kernel
normally has 1GB of RAM and 3GB available for the user application - more
requires switching between the user and physical memory view which is not

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]