Do 64-bit OS's really always run 10% slower than 32-bit OS's?


M

Misha

I have a 1.6GHz Lenovo W510 with 16MB of memory and I'm not sure
if I should put 32 bit or 64 bit Windows on it.

I have 64-bit Linux on now but I'm making it a dual boot system.

Normally I'd just "go" with 64-bit, to follow the crowd, without
really knowing why - but I was always told that 64-bit OS's always
run about 10% slower than 32-bit OS's.

Is that true that applications *always* run slower on 64-bit OS's
than on 32-bit OS's?
 
B

Bob I

Well for one thing if you load the 32 bit version, you won't have access
to 3/4 of your RAM
 
M

mick

I have a 1.6GHz Lenovo W510 with 16MB of memory and I'm not sure
if I should put 32 bit or 64 bit Windows on it.

I have 64-bit Linux on now but I'm making it a dual boot system.

Normally I'd just "go" with 64-bit, to follow the crowd, without
really knowing why - but I was always told that 64-bit OS's always
run about 10% slower than 32-bit OS's.

Is that true that applications *always* run slower on 64-bit OS's
than on 32-bit OS's?
First time I've heard that, 10% slower?, would you actually know or
even notice. As for 32bit, if you use that then you are wasting 12MB
of your RAM. Its 64bit all the way.
 
D

Dominique

I have a 1.6GHz Lenovo W510 with 16MB of memory and I'm not sure
if I should put 32 bit or 64 bit Windows on it.

I have 64-bit Linux on now but I'm making it a dual boot system.

Normally I'd just "go" with 64-bit, to follow the crowd, without
really knowing why - but I was always told that 64-bit OS's always
run about 10% slower than 32-bit OS's.

Is that true that applications *always* run slower on 64-bit OS's
than on 32-bit OS's?
With 16 MB of memory, either 32 or 64 bits should be very very sloooow.
 
W

Wolf K

I have a 1.6GHz Lenovo W510 with 16MB of memory and I'm not sure
if I should put 32 bit or 64 bit Windows on it.

I have 64-bit Linux on now but I'm making it a dual boot system.

Normally I'd just "go" with 64-bit, to follow the crowd, without
really knowing why - but I was always told that 64-bit OS's always
run about 10% slower than 32-bit OS's.

Is that true that applications *always* run slower on 64-bit OS's
than on 32-bit OS's?
A) You mean 16GB of RAM, right? The 32-bit OS will see only 4GB.

So the speed question is moot, but here's my take on it FWIW:
B) It depends. 32-bit apps may run slower, since the CPU fetches 64 bits
every time, and that means 32 Bits are wasted. In the early days of
64-bit OSs running on single core CPUs, people claimed to notice a
difference, but I don't think you'd notice any now.

C) With that much RAM you won't notice any difference anyhow, since the
system will do very little paging. and it's paging that's the choke
point. Aside from you and me, that is: the human is the slowest element
in the system.

HTH
 
P

Paul

Misha said:
I have a 1.6GHz Lenovo W510 with 16MB of memory and I'm not sure
if I should put 32 bit or 64 bit Windows on it.

I have 64-bit Linux on now but I'm making it a dual boot system.

Normally I'd just "go" with 64-bit, to follow the crowd, without
really knowing why - but I was always told that 64-bit OS's always
run about 10% slower than 32-bit OS's.

Is that true that applications *always* run slower on 64-bit OS's
than on 32-bit OS's?
The claimed 10% figure might be attributed to the difference
between Intel and AMD pipelines.

On Intel (Core/Core2 or later) families, I think there is some
64 bit path element inside the processing pipeline. In 32 bit
mode, two instructions are packed together for transport. In
64 bit mode, the packing is no longer possible, and it affects
execution rate.

AMD, on the other hand, doesn't have that same optimization.
The 32 bit and 64 bit instructions travel through their pipes
the same way. There should be no 10% factor for plumbing, on AMD.

So from that point of view, 64 bit is a bit slower on Intel,
from a "plumbing" perspective.

The 64 bit could be faster, when the code is recompiled, and
the code takes advantage of the extra width. For example, I
had a small program, which could be compiled 32 bit or 64 bit,
and it achieved a 70% speed up in 64 bit mode (the 64 bit library
uses is faster). But that is a "best case" as far as I'm concerned.
In that program, there was more "math" than anything else. And if
you do math on 64 bits at a time, versus 32, it takes fewer
instructions to represent an operation on an infinite precision number.
The speedup should have been 100% (twice as fast), but I think it
did good reaching the 70% figure.

Paul
 
J

Jeff Barnett

Bob I wrote, On 8/16/2013 4:56 PM:
Well for one thing if you load the 32 bit version, you won't have access
to 3/4 of your RAM
He said 16mb not 16gb. What do you think we should believe?

Jeff Barnett
 
P

Paladin

Bob I wrote, On 8/16/2013 4:56 PM:
He said 16mb not 16gb. What do you think we should believe?

Jeff Barnett
That 80286 cpus are coming back :)
 
J

JJ

I have a 1.6GHz Lenovo W510 with 16MB of memory and I'm not sure
if I should put 32 bit or 64 bit Windows on it.

I have 64-bit Linux on now but I'm making it a dual boot system.

Normally I'd just "go" with 64-bit, to follow the crowd, without
really knowing why - but I was always told that 64-bit OS's always
run about 10% slower than 32-bit OS's.

Is that true that applications *always* run slower on 64-bit OS's
than on 32-bit OS's?
With nowaday programs having too much eye candies, they'll use your memory
quickly. Performance would no longer matter in this case.

With 32-bit Windows, only 4GB of memory can be utilized (read: reachable).
3GB for all programs combined, and 1GB for hardware (the default setting is
2GB for programs, 2GB for hardwares). Other OSes may differ on how much
memory are reserved for hardwares, but all of them can only utilize 4GB.

When memory usage of all programs exceeds the physical memory, the system
will slow down to a crawl. With 64-bit Windows, it can utilize all of the
memory and give more room for programs before choking the OS.
 
J

J.O. Aho

With nowaday programs having too much eye candies, they'll use your memory
quickly. Performance would no longer matter in this case.

With 32-bit Windows, only 4GB of memory can be utilized (read: reachable).
3GB for all programs combined, and 1GB for hardware (the default setting is
2GB for programs, 2GB for hardwares). Other OSes may differ on how much
memory are reserved for hardwares, but all of them can only utilize 4GB.
I guess you missed that there is PAE (Physical Address Extension), which
allows you to utilize up to 64GB or RAM on a x86 CPU (Pentium Pro and
later and AMD Athlon and later), still the application run is limited to
4GB. PAE is slower and most of microsoft windows versions with PAE is
still limited to only 4GB.

When memory usage of all programs exceeds the physical memory, the system
will slow down to a crawl. With 64-bit Windows, it can utilize all of the
memory and give more room for programs before choking the OS.
Following 64bit os versions do have memory limits that can cause
problems for the OP:
microsoft windows vista Home Basic is limited to 8GB
microsoft windows 7 Home Basic is limited to 8GB
microsoft windows server 2008 R2 Foundation is limited to 8GB


A side note, microsoft windows 64bit is more of a mixed environment,
where you have some drivers running in a 32bit space and of course many
applications are only released as 32bit versions, so you will not get a
genuine 64bit experience on it like you get when running GNU/Linux or
Unix as 64bit OS:es.


To harness the full power of 64bit, you need applications which do heavy
calculations with large numbers, which seldom happens when you surf or
play games.
 
J

Jasen Betts

I have a 1.6GHz Lenovo W510 with 16MB of memory and I'm not sure
if I should put 32 bit or 64 bit Windows on it.
Now why would you want to do that :)
I have 64-bit Linux on now but I'm making it a dual boot system.

Normally I'd just "go" with 64-bit, to follow the crowd, without
really knowing why - but I was always told that 64-bit OS's always
run about 10% slower than 32-bit OS's.
If you want 32 bit windows and 16G RAM you have 2 choices
server 2008 enterprise or server 2003 enterprise.
Is that true that applications *always* run slower on 64-bit OS's
than on 32-bit OS's?
FWIW PAE isn't free either. (it "costs" some speed)
 
J

Jasen Betts

I guess you missed that there is PAE (Physical Address Extension), which
allows you to utilize up to 64GB or RAM on a x86 CPU (Pentium Pro and
later and AMD Athlon and later), still the application run is limited to
4GB. PAE is slower and most of microsoft windows versions with PAE is
still limited to only 4GB.
Yeah, Windows has PAE, but only the old enterprise server editions.

http://msdn.microsoft.com/en-us/library/windows/desktop/aa366778(v=vs.85).aspx
A side note, microsoft windows 64bit is more of a mixed environment,
where you have some drivers running in a 32bit space and of course many
applications are only released as 32bit versions, so you will not get a
genuine 64bit experience on it like you get when running GNU/Linux or
Unix as 64bit OS:es.
:) linux is mixed too, eg: if you use wine. or any 32-bit closed
source apps.
 
R

Richard Kettlewell

Misha said:
Is that true that applications *always* run slower on 64-bit OS's
than on 32-bit OS's?
There seem to be several misconceptions in this thread...

* 64-bit operating systems do not inherently run applications 10% slower
than 32-bit operating systems.

* A 32-bit operating system need not be limited to 4GB of RAM, though in
practice some are. Still, a 32-bit OS on 64-bit hardware would be a
bizarre choice for most use cases today.

* A single 32-bit application can only address a maximum of 4GB of
virtual memory (even if running under a 64-bit OS). A given OS may
impose lower limits.

* 32-bit code does not "waste" half of every memory fetch on a 64-bit
system. Modern computers are replete with buffers and caches which
exploit locality of reference for code and data fetches. Even the
original Pentium (P5 µarch) had a 64-bit external data bus despite the
32-bit instruction set.

On Intel/AMD hardware, the 64-bit instruction set brings a couple of
performance advantages:

* There are twice as many general-purpose registers. That substantially
reduces the chance that a performance-critical fragment of code will
need to spill values to memory (which is still slower than using
registers despite the extensive caching mentioned above).

* The general-purpose registers are (obviously!) 64 bits wide instead of
32 bits. Whether this is an advantage in practice depends on the code
in question.

Furthermore, ABI designers have taken advantage of the instruction set
change to introduce more efficient function call mechanisms
(i.e. passing parameters in registers), which can also reduce the number
of memory accesses required for performance-critical code.

Finally: there *is* a performance regression that may affect some code.
Pointers (addresses) are twice as large, so code using pointer-heavy
data structures occupies more memory, resulting in less efficient use of
cache (including RAM, interpreted as cached virtual memory). The impact
will depend on the particular program; usually it will be much too small
to notice.
 
J

J. P. Gilliver (John)

(Did you know that your posts take the form of a text attachment?)

Richard said:
There seem to be several misconceptions in this thread...
I've been thinking that!
* 64-bit operating systems do not inherently run applications 10% slower
than 32-bit operating systems.
No, that figure of 10% was puzzling me too. If run on totally 32-bit
_hardware_, they'd have to do two fetches per instruction, but that
would only be slower (and that by 50%, not 10%) if the code wasn't
optimised for 64-bit. (Which a lot of it isn't; on the whole, I wouldn't
run a 64-bit OS on 32-bit hardware.)
* A 32-bit operating system need not be limited to 4GB of RAM, though in
practice some are. Still, a 32-bit OS on 64-bit hardware would be a
bizarre choice for most use cases today.
Mostly agreed. If the 32-bit OS had _knowledge_ of the existence of
64-bit hardware, and arranged memory usage and the like in pairs, it
might not lose much, but still an odd choice. (Though I know of one
piece of software that _won't work_ - because it is closely linked to
the explorer shell - with 64-bit [XP, Vista, 7, or 8], but will with
32-bit versions. [Right up to pre-release, it _would_ work in 64-bit
versions, since MS had the 32-bit shell present; only on the final
release of 7 did they break access to that 32-bit shell.] People who
want to use that software under 7 - about half of them run 32-bit 7, the
rest run it in a virtual machine, usually under XP where it's a bit
happier anyway. There probably are other 32-bit app.s - and, certainly,
16-bit and older - that won't work in a 64.)
* A single 32-bit application can only address a maximum of 4GB of
virtual memory (even if running under a 64-bit OS). A given OS may
impose lower limits.
Well, 2^32 is 4G, so it can't address more than that with single-word
addresses; that never stopped 8-bit processors addressing 64K rather
than only 256 locations. However, you are right that most 32-bit app.s
don't use multi-word addresses, at least in part because processor
hardwares - and OSs - when 32 bits came in didn't consider multi-word
addresses necessary, 4G seeming big enough at the time (unlike 256 in
the 8-bit days).
* 32-bit code does not "waste" half of every memory fetch on a 64-bit
system. Modern computers are replete with buffers and caches which
exploit locality of reference for code and data fetches. Even the
original Pentium (P5 0 > 32-bit instruction set.
Unless these caches etc. are only 32 bits wide, though, I don't see how
the fetches _aren't_ wasting capacity - _unless_ there is
packing/unpacking hardware at each interface. (And in terms of
instructions, the processor would have to have the ability to process
them in pairs too, which isn't always possible if one instruction
depends on the results of the previous one.)
On Intel/AMD hardware, the 64-bit instruction set brings a couple of
performance advantages:

* There are twice as many general-purpose registers. That substantially
reduces the chance that a performance-critical fragment of code will
need to spill values to memory (which is still slower than using
registers despite the extensive caching mentioned above).
Yes, that is certainly an advantage. Having twice as many registers
doesn't of itself fall out of the use of 64 rather than 32 bits, but I
am not surprised that Intel/AMD decided to provide it at the same time.
* The general-purpose registers are (obviously!) 64 bits wide instead of
32 bits. Whether this is an advantage in practice depends on the code
in question.
Indeed. Unlikely to be that significant for maths operations except in
extreme cases, but for parallel processing of shorter values, assuming
there is the necessary packing/unpacking hardware (and the code knows
about it), there is a potential halving.
Furthermore, ABI designers have taken advantage of the instruction set
change to introduce more efficient function call mechanisms
(i.e. passing parameters in registers), which can also reduce the number
of memory accesses required for performance-critical code.
Indeed. (More of what I'm calling packing/unpacking hardware.)
Finally: there *is* a performance regression that may affect some code.
Pointers (addresses) are twice as large, so code using pointer-heavy
data structures occupies more memory, resulting in less efficient use of
cache (including RAM, interpreted as cached virtual memory). The impact
will depend on the particular program; usually it will be much too small
to notice.
Agreed - certainly on the first part about the _theoretical_ penalty;
I'm not qualified to comment on the "usually", so I yield on that.
 
R

Richard Kettlewell

J. P. Gilliver (John) said:
(Did you know that your posts take the form of a text attachment?)
They don’t. If they are displayed like that it is a bug in your
newsreader.
No, that figure of 10% was puzzling me too. If run on totally 32-bit
_hardware_, they'd have to do two fetches per instruction,
I have no idea why you’d think that (see below for further discussion).
but that would only be slower (and that by 50%, not 10%) if the code
wasn't optimised for 64-bit. (Which a lot of it isn't; on the whole, I
wouldn't run a 64-bit OS on 32-bit hardware.)


Well, 2^32 is 4G, so it can't address more than that with single-word
addresses; that never stopped 8-bit processors addressing 64K rather
than only 256 locations. However, you are right that most 32-bit app.s
don't use multi-word addresses, at least in part because processor
hardwares - and OSs - when 32 bits came in didn't consider multi-word
addresses necessary, 4G seeming big enough at the time (unlike 256 in
the 8-bit days).
“n-bit†isn’t a very exact way of describing a CPU’s capabilities, but
TTBOMK everything that people call a “32-bit CPU†has 32-bit user
addresses. That’s not something an application can readily do anything
about.
Unless these caches etc. are only 32 bits wide, though, I don't see
how the fetches _aren't_ wasting capacity - _unless_ there is
packing/unpacking hardware at each interface. (And in terms of
instructions, the processor would have to have the ability to process
them in pairs too, which isn't always possible if one instruction
depends on the results of the previous one.)
CPU caches are measured in kilobytes or megabytes, not bits.

Consider an instruction fetch, as a motivating example. In the x86 ISA
one instruction may be as little as 8 bits wide. The other 56 bits of
the memory read are not wasted, because they contain the next few
instructions, so no access to physical memory is required for them -
they are already inside the CPU.

The situation is similar with data. While it’s not inevitable that data
that is used together is stored together, it’s something that often
arises naturally even before one puts any effort into performance
improvement.
Indeed. Unlikely to be that significant for maths operations except in
extreme cases, but for parallel processing of shorter values, assuming
there is the necessary packing/unpacking hardware (and the code knows
about it), there is a potential halving.
It’s pretty relevant for bignum operations...

For many kinds of parallel operation there is a separate set of very
wide registers used by the SIMD instructions, and those are available in
the 32-bit ISA too.
 
J

JJ

I guess you missed that there is PAE (Physical Address Extension), which
allows you to utilize up to 64GB or RAM on a x86 CPU (Pentium Pro and
later and AMD Athlon and later), still the application run is limited to
4GB. PAE is slower and most of microsoft windows versions with PAE is
still limited to only 4GB.
You're right, I forgot about that.
Interestingly, I find that the 32-bit Chromium v27 is not yet PAE enabled.
A side note, microsoft windows 64bit is more of a mixed environment,
where you have some drivers running in a 32bit space...
Are you sure about this? AFAIK, all drivers in 64-bit Windows must be 64-bit
also. Windows' service manager internal function do enumerate kernel-mode
drivers as services, but I've never see any 32-bit drivers in a 64-bit
Windows.
 
P

Pascal Hambourg

JJ a écrit :
You're right, I forgot about that.
Interestingly, I find that the 32-bit Chromium v27 is not yet PAE enabled.
Huh ? AFAIK there are no PAE enabled applications, PAE is an internal OS
thing. As J.O. Aho wrote, PAE does not extend the applications' virtual
addressing space.
Or do you mean ChromiumOS ? Or AWE (Address Windowing Extensions)
instead of PAE ?
 
M

Misha

A) You mean 16GB of RAM, right? The 32-bit OS will see only 4GB.
I misread the results of this command:
$ cat /proc/meminfo
MemTotal: 16264328 kB
 
A

Ant

With 16 MB of memory, either 32 or 64 bits should be very very sloooow.
Or impossible with today's softwares!
--
Captain Marvel: Shazam. Billy Batson: Now put her down. Black Adam: See?
Like an ant. --Superman/Shazam!: The Return of Black Adam
/\___/\ Ant(Dude) @ http://antfarm.ma.cx (Personal Web Site)
/ /\ /\ \ Ant's Quality Foraged Links: http://aqfl.net
| |o o| |
\ _ / If crediting, then use Ant nickname and AQFL URL/link.
( ) If e-mailing, then axe ANT from its address if needed.
Ant is currently not listening to any songs on this computer.
 
A

Aragorn

You're right, I forgot about that.
Interestingly, I find that the 32-bit Chromium v27 is not yet PAE
enabled.
Applications are never PAE-enabled. PAE is a matter of the kernel, not
of userspace. A 32-bit process will still only support an address space
of 3 GiB (plus 1 GiB for kernelspace) whether PAE is active or not.

What PAE does - at least, in the Linux kernel - is that it gives the
kernel an extra pagetable, so that there are three pagetables, as
opposed to only two for "plain" 32-bit. With the extra pagetable, a
PAE-enabled processor can address the physical RAM by way of 36 bits, so
that a total of 64 GiB of RAM can be accessed, but - as I wrote higher
up - in pages of 3 + 1 GiB, or alternatively, 2 + 2 GiB, or another
ratio. The exact split ratio between kernel and userspace is set at
kernel compile time.

I could be wrong, but as I understand it, Windows maintains a 2 + 2 GiB
split.
Are you sure about this? AFAIK, all drivers in 64-bit Windows must be
64-bit also.
That is correct. I believe J.O. Aho was referring to the fact that
certain components of the 64-bit Windows operating systems as a whole -
meaning kernel /plus/ userland - are still 32-bit-only.
Windows' service manager internal function do enumerate kernel-mode
drivers as services, but I've never see any 32-bit drivers in a 64-bit
Windows.
There aren't any. In a monolithic kernel like Linux or NT, (most)
drivers run in kernelspace, and must thus be of the same "bitness" as
the kernel code itself.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top