Re: 32 or 64 bit

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

 



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

-- 
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora Magazine]     [Fedora News]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux