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

[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?

[mick]

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.

--
mick

[Dominique]

Misha <Mi...@invalid.com> �crivait news:520ea9e7$0$98465$afc38c87
@read01.usenet4all.se:

With 16 MB of memory, either 32 or 64 bits should be very very sloooow.

[Wolf K]

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

--
Best,
Wolf K
kirkwood40.blogspot.ca

[Paul]

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

[JJ]

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.O. Aho]

On 17/08/13 03:46, JJ wrote:
> On 16 Aug 2013 22:38:31 GMT, Misha wrote:
>> 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.

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.

--

//Aho

[Jasen Betts]

On 2013-08-16, Misha <Mi...@invalid.com> wrote:
> 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)

--
⚂⚃ 100% natural

--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---

[Jasen Betts]

On 2013-08-17, J.O. Aho <us...@example.net> wrote:

> 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%28v=vs.85%29.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.

[Richard Kettlewell]

Misha <Mi...@invalid.com> writes:
> 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.

--
http://www.greenend.org.uk/rjk/

[J. P. Gilliver (John)]

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

In message <87bo4w8...@araminta.anjou.terraraq.org.uk>, Richard

Kettlewell <r...@greenend.org.uk> writes:
>Misha <Mi...@invalid.com> writes:
>> 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...

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.
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

"EARTH is 98% full. Please delete anybody you can." - Fortunes file

[Richard Kettlewell]

"J. P. Gilliver (John)" <G6...@soft255.demon.co.uk> writes:
> (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.

> Richard Kettlewell <r...@greenend.org.uk> writes:
>>* 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,

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

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

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

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

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.

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

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.

--
http://www.greenend.org.uk/rjk/

[JJ]

On Sat, 17 Aug 2013 08:22:14 +0200, J.O. Aho wrote:
> 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.

[Pascal Hambourg]

JJ a écrit :

> On Sat, 17 Aug 2013 08:22:14 +0200, J.O. Aho wrote:
>> 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.
>

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

[Misha]

On Fri, 16 Aug 2013 20:43:13 -0400, Wolf K wrote:

> 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

[Ant]

On 8/16/2013 4:40 PM PT, Dominique typed:

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

[Aragorn]

On Saturday 17 August 2013 14:49, JJ conveyed the following to
alt.os.linux...

> On Sat, 17 Aug 2013 08:22:14 +0200, J.O. Aho wrote:
>> 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.

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.

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

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.

--
= Aragorn =
GNU/Linux user #223157 - http://www.linuxcounter.net

[Wolf K]

On 2013-08-17 4:54 AM, Richard Kettlewell wrote:
> Misha<Mi...@invalid.com> writes:

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

Nice clarification/correction. Thanks.

[J. P. Gilliver (John)]

In message <87haeo3...@araminta.anjou.terraraq.org.uk>, Richard

Kettlewell <r...@greenend.org.uk> writes:
>"J. P. Gilliver (John)" <G6...@soft255.demon.co.uk> writes:
>> (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.

Strange: the post to which I posted the last followup most definitely
did (and my newsreader just presents the content inline anyway, so no
problem); this one didn't. I've noticed it increasingly recently that
some posts (not just yours) are in that form. It's not a problem!

>
>> Richard Kettlewell <r...@greenend.org.uk> writes:
>>>* 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,
>
>I have no idea why you’d think that (see below for further discussion).

OK, see below.

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

Agreed. I'm out of touch with what goes on in today's 32 and 64 bit
world; certainly some 8 bit processors had 16 bit address buses, and I
think some 16-bit ones had 32. (Sometimes implemented as individual
pins, sometimes half that with a high/low pin.)

>
>>>* 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.)
>
>CPU caches are measured in kilobytes or megabytes, not bits.

They have a width as well as a depth.

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

I didn't realise that such packing occurs by default.

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

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

It all gets very confusing when you have cores that _can_ do operations
on, say, four or eight 8-bit values at once (a lot of image processing
for example), and then you also have multiple cores ... all too new for
me!

--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

The Daily Mail has led the campaign to limit pornography - "it demeans and
belittles women," they explain, "and that's our job." (Sandi Toksvig
[scripted], News Quiz 2013-7-26.)

[Paul]

J. P. Gilliver (John) wrote:
> (Did you know that your posts take the form of a text attachment?)
>
> In message <87bo4w8...@araminta.anjou.terraraq.org.uk>, Richard
> Kettlewell <r...@greenend.org.uk> writes:
>> Misha <Mi...@invalid.com> writes:
>>> 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...
>
> 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.)

On Intel Core2, the feature is called MacroFusion.

http://abinstein.blogspot.ca/2007/06/decoding-x86-from-p6-to-core-2-part-3.html

"So instead of trying to fused all possible macroinstruction pairs,
Core 2 Duo fuses only the selected macroinstructions -

* The first macroinstruction must be a TEST X, Y or a CMP X, Y
where only one operand of X and Y is an immediate or a memory word.
* The second macroinstruction must be a conditional jump that checks
the carry flag (CF) or zero flag (ZF).
* The macroinstructions are not working in 64-bit mode. <---

...the frequency of macro-fused operations in SPEC2006 CPU ranges from
0-16% in integer codes and just 0-8% in floating-point codes. In other
words, in the best case, macro-fusion would reduce the number of
macroinstructions from 100% to 92% for integer and just 96% for
floating-point execution, hardly the whopping 20-25% reduction as
described by Intel's marketing department
"

And that's what is supposed to make 64 bit code slower than 32 bit code
on an Intel Core2. "macroinstructions are not working in 64-bit mode".

Apparently AMD doesn't use macrofusion in their design, and without
that feature, the execution rate of 32 bit and 64 bit is the same.

Paul

[JJ]

On Sat, 17 Aug 2013 15:18:47 +0200, Pascal Hambourg wrote:
> 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 ?

Crap. My brain has been glitchy lately.
Yes, I meant the AWE.

Chromium (Canary?), which is the base of Google Chrome.
Its 32-bit version is not yet large address aware, in the PE header.
32-bit Firefox already has this bit enabled.

[JJ]

On Sat, 17 Aug 2013 15:18:47 +0200, Pascal Hambourg wrote:

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

Crap. My brain has been glitchy lately.
Yes, I meant the AWE.

Chromium (Canary?), which is the base of Google Chrome.
Its 32-bit version is not yet large address aware, in the PE header.
32-bit Firefox already has this bit enabled.

Or... is this bit for PAE instead of AWE?

[Pascal Hambourg]

JJ a écrit :

>
> Chromium (Canary?), which is the base of Google Chrome.
> Its 32-bit version is not yet large address aware, in the PE header.
> 32-bit Firefox already has this bit enabled.
> Or... is this bit for PAE instead of AWE?

Neither. "Large Address Aware" indicates that a 32-bit application can
handle the full 32-bit 4 GiB addressing space instead of the traditional
2 GiB space (the remaining 2 GiB being reserved for the kernel on 32-bit
Windows versions). Of course this is only relevant for 32-bit
applications running on 64-bit Windows versions (WOW64).

[Yousuf Khan]

No, it was never as much as 10% slower, it was more like 1-2% slower
sometimes. Most of the reason for the slowness was operating
system-dependent. Because the real OS kernel is 64-bit, the 32-bit apps
are presented with a simulated 32-bit OS to work with. The simulated
32-bit kernel is just a wrapper for the 64-bit kernel, converting 32-bit
calls to 64-bit and vice-versa (they called this "thunking"). That extra
layer of OS added the 1-2%. That of course is only a problem for 32-bit
apps, and it's not much of a problem at that. Native 64-bit apps have no
such additional layer to go through. Also as I said, it was
OS-dependent, so some OS's might have had a much more efficient thunking
layer than others, e.g. think Linux vs. Windows.

However, on the plus side, on a 64-bit OS, all 32-bit apps see their own
full private 3GB of address space, they aren't sharing it with other
32-bit apps. So this may help performance with those apps as they are
much less memory constrained than on their own native 32-bit OS.

And then finally, you have 16GB of RAM! You will be wasting more than
12GB of that RAM if you load it down with a 32-bit OS! Since 32-bit OS's
don't see much more than 3-4GB of RAM, usually (though there are
complicated ways around that).

Yousuf Khan

[Pascal Hambourg]

Yousuf Khan a ï¿œcrit :

>
> However, on the plus side, on a 64-bit OS, all 32-bit apps see their own
> full private 3GB of address space, they aren't sharing it with other
> 32-bit apps.

AFAIK, the applications see their own full private address space and
don't share it with other applications on 32-bit systems too. Of course
they share the physical RAM, but that does not change on 64-bit systems.

[Peter Köhlmann]

Pascal Hambourg wrote:

> Yousuf Khan a écrit :

That is not completely right.
On 32Bit systems, even with PAE enabled (which excludes all windows systems
except few selected Server versions) any application can see a max of about
3 GByte memory. The remaining 1 GByte is mapped to the OS
On 64 bit systems, any 32bit application can have a max of nearly 4 GByte
memory. More is not possible since in 32bit mode, only 4 GByte are
adressable

[Pascal Hambourg]

Peter Kï¿œhlmann a ï¿œcrit :
> Pascal Hambourg wrote:
>
>> Yousuf Khan a ï¿œcrit :

>>> However, on the plus side, on a 64-bit OS, all 32-bit apps see their own
>>> full private 3GB of address space, they aren't sharing it with other
>>> 32-bit apps.
>> AFAIK, the applications see their own full private address space and
>> don't share it with other applications on 32-bit systems too. Of course
>> they share the physical RAM, but that does not change on 64-bit systems.
>
> That is not completely right.

What part exactly is not right ?

> On 32Bit systems, even with PAE enabled (which excludes all windows systems
> except few selected Server versions) any application can see a max of about
> 3 GByte memory. The remaining 1 GByte is mapped to the OS
> On 64 bit systems, any 32bit application can have a max of nearly 4 GByte
> memory.

This has been mentionned earlier in the thread. However it does not mean
that applications share their address space with others, does it ?

[Andy K]

On Thursday, August 22, 2013 3:00:35 PM UTC-5, Pascal Hambourg wrote:
> Peter Köhlmann a écrit :
>
> > Pascal Hambourg wrote:
>
> >
>
> >> Yousuf Khan a écrit :

I skimmed thru the posts and here is what I have found.

I use XP 32 bit and OpenSuse.

My system is 64 bit capapble.

I could not tell any speed difference with a Linux system using both 32 and 64 bit o.s.'s

Both were much faster than Windows. :-)

I have 4 Gb of ram and I feel my system is pretty fast with an Intel 2 core chip.

Windows only uses 3 Gb of the memory and I always have pretty of free ram.

I am not very familiar with the strategy that Linux uses for memory allocation as I am for Windows.

My pagefile is 400 Mb fixed size. I understand the reason for not getting rid of the page file altogether, but not why at times, it will use 400 + Mb of the ram when there is still 2 Gb of free ram.

I have used computers with 64 bit Windows 7 and did not notice any speed difference compared to 32 bit with comparable RAM.

I may see if there are any freeware benchmarking programs that could pin down some facts.

Thanks,
Andy

[Aragorn]

On Friday 23 August 2013 14:34, Andy K conveyed the following to
alt.os.linux...

> [...]

> I could not tell any speed difference with a Linux system using both
> 32 and 64 bit o.s.'s
>
> Both were much faster than Windows. :-)

That is a given, and it has been even stated numerous times by people
who run Windows applications on GNU/Linux via the Wine compatibility
layer that those Windows applications actually perform better when
running on Wine than when running natively on Microsoft Windows.

> I have 4 Gb of ram and I feel my system is pretty fast with an Intel 2
> core chip.
>
> Windows only uses 3 Gb of the memory and I always have pretty of free
> ram.

The amount of available RAM in 32-bit operating systems depends upon the
number of PCI devices in the system. PCI devices are accessed via a
memory address space, which extends from the top of the 4 GiB barrier
down.

Considering that memory addresses can only be assigned to one device,
the RAM between (roughly) 3.1 GiB and 4 GiB is then consumed by the PCI
address space and is not usable anymore as RAM, unless it is remapped to
a logical address above the 4 GiB barrier, but this in turn would
require a PAE-enabled kernel or a 64-bit operating system, because a
non-PAE-enabled 32-bit operating system does not "see" any RAM above the
4 GiB barrier.

> I am not very familiar with the strategy that Linux uses for memory
> allocation as I am for Windows.

Windows has a different swapping strategy and also swaps out parts of
its kernel. It does that by default. The Linux kernel on the other
hand only swaps out stuff in order to make room for other stuff, but
that "other stuff" includes caching, and the choice of what is swapped
out is more intelligent than in Windows.

It is on the other hand possible to tell the Linux kernel not to swap so
rapidly if you want to keep more stuff in RAM. If you add...

vm.swappiness=10

... to /etc/sysctl.conf, it'll swap out far less than with the default
swappiness value. If you set it to "0", it'll only swap out if there
really is no other way to prevent the system from running out of free
memory.

> My pagefile is 400 Mb fixed size. I understand the reason for not
> getting rid of the page file altogether, but not why at times, it will
> use 400 + Mb of the ram when there is still 2 Gb of free ram.

Considering that you're talking of a pagefile, I'm assuming that the
above applies to Microsoft Windows. GNU/Linux can use swap files, but
prefers using a dedicated and raw swap partition.

On account of reducing the swappiness of the Linux kernel, see higher
up.

[Aragorn]

On Friday 23 August 2013 14:51, Aragorn conveyed the following to
alt.os.linux...

> Considering that memory addresses can only be assigned to one device,
> the RAM between (roughly) 3.1 GiB and 4 GiB is then consumed by the

^^^^^^^^
> PCI address space and is not usable anymore as RAM, [...]

Not "consumed" but obscured. It is still there and unused, but as the
Linux kernel uses a virtual memory system, the address space as
mentioned above has been assigned to the PCI devices instead of to the
RAM.

[Andy K]

> GNU/Linux user #223157 - http://www.linuxcounter.net

Considering that memory addresses can only be assigned to one device,
the RAM between (roughly) 3.1 GiB and 4 GiB is then consumed by the PCI
address space and is not usable anymore as RAM, unless it is remapped to

a logical address above the 4GiB barrier, but this in turn would
require a PAE-enabled kernel

Thanks for the info.

I have PAE enabled, but XP shows 2.9 gigs of RAM.
BIOS sees all 4 Gbs.

I just remembered that I may have integrated video in my HP laptop.
I can't see it using a Gb ?

Andy

[Jasen Betts]

On 2013-08-24, Andy K <andrew_...@yahoo.com> wrote:
> On Friday, August 23, 2013 7:51:52 AM UTC-5, Aragorn wrote:
>> On Friday 23 August 2013 14:34, Andy K conveyed the following to
>>
>> alt.os.linux...
>

> Thanks for the info.
>
> I have PAE enabled, but XP shows 2.9 gigs of RAM.
> BIOS sees all 4 Gbs.

microsoft says XP does not support PAE only server enterprise (2003|2008)

Windows is mostly crippleware so they can upsell you a more expensive
version

linux is all industrial strength.

[Peter Köhlmann]

PAE on windows (except a few server versions) is *not* useable to extend
memory beyond 4GBytes
It is only used to enable the NX-Bit (No Execute) which is only accessable
in 64bit mode or PAE

The reason for not supporting more memory is that the drivers too need to be
PAE-aware if you go beyond 4 GByte memory
Extremely few drivers are, so MS restricted this mode to selected models

Linux has not had this problem, as the drivers are compiled with the kernel
and so are PAE-aware

[Andy K]

On Saturday, August 24, 2013 4:45:53 PM UTC-5, Jasen Betts wrote:
> On 2013-08-24, Andy K <andrew_...@yahoo.com> wrote:
>
> > On Friday, August 23, 2013 7:51:52 AM UTC-5, Aragorn wrote:
>
> >> On Friday 23 August 2013 14:34, Andy K conveyed the following to
>
> >>
>
> >> alt.os.linux...
>
> >
>
> > Thanks for the info.
>
> >
>
> > I have PAE enabled, but XP shows 2.9 gigs of RAM.
>
> > BIOS sees all 4 Gbs.
>
>
>
> microsoft says XP does not support PAE only server enterprise (2003|2008)
>
>
>
> Windows is mostly crippleware so they can upsell you a more expensive

>

> linux is all industrial strength.
>

> --- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---

Let's be objective.

If it wasn't 4 windows, Linux share would not be rocketing up. :-)

You are right about Windows doing some lying, stretching the truth, and obfuscation.

But like Linux users and code writers who are on a mission to make things better, theire are freeware and other authors are working hard to improve Windows and no charge in most cases.

I think some of the Windows coders may feel some guilt.

They have quite a few detailed comments(about what the code does)embedded in some of their programs.

Those comments give info that leads to chip makers, retailers,etc.

I think you get the picture.

Ich bin mude.

[Laszlo Lebrun]

On 17.08.2013 03:46, JJ wrote:
> 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).

Never heard of that, interesting. Where can one change that setting?

--
One computer and three operating systems, not the other way round.
One wife and many hotels, not the other way round ! ;-)

[Aragorn]

On Sunday 01 September 2013 14:44, Laszlo Lebrun conveyed the following
to alt.os.linux...

> On 17.08.2013 03:46, JJ wrote:
>
>> 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).

More correctly, 3 GiB per individual userspace process, and 1 GiB for
the kernel (which /includes/ the PCI address space), or in the case of
Microsoft Windows, 2 GiB per userspace process and 2 GiB for the kernel
and PCI address space.

> Never heard of that, interesting. Where can one change that setting?

One cannot. It is set at kernel build-time, or at least, in Linux. I
don't know about NT - which is a pageable kernel - so if NT allows for a
change of the address space division, then it would either way require a
reboot to activate it. However, given that Microsoft chooses to limit
the power of the kernel depending on the Windows license - e.g. Home
versus Professional versus Server, et al - I doubt that it would be
anything other than a build-time option.

--
= Aragorn =

[Andy K]

3 Gb is the limit even on XP Pro even with PAE being enabled.

Some server versions would use more RAM.

Humor for the day.

In Windows XP they left in an old audio recorder program.

I have 4 Gb of RAM and ...

When you try to record a .wav file by using Sound Recorder on a computer that has more than 2 gigabytes (GB) of RAM, you receive the following error message:

Not enough memory available to complete this operation. Quit one or more applications to increase available memory, and then try again.

Note: This problem only occurs when the amount of available physical memory is more than 2 GB.

:-)

[Robert Newson]

On 03/09/13 06:43, Andy K wrote:
...

> Humor for the day.
>
> In Windows XP they left in an old audio recorder program.
>
> I have 4 Gb of RAM and ...
>
> When you try to record a .wav file by using Sound Recorder on a computer that has more than 2 gigabytes (GB) of RAM, you receive the following error message:
>
> Not enough memory available to complete this operation. Quit one or more applications to increase available memory, and then try again.
>
> Note: This problem only occurs when the amount of available physical memory is more than 2 GB.

Obviously they used "int free_mem" instead of "unsigned int "free_mem"

^_^

[Andy K]

Might be.

Or one of their "security patches" disabled sound recorder.

Andy

[Pascal Hambourg]

A bit late, but...

Aragorn a écrit :

> On Friday 23 August 2013 14:51, Aragorn conveyed the following to
> alt.os.linux...
>
>> Considering that memory addresses can only be assigned to one device,
>> the RAM between (roughly) 3.1 GiB and 4 GiB is then consumed by the
> ^^^^^^^^
>> PCI address space and is not usable anymore as RAM, [...]
>
> Not "consumed" but obscured. It is still there and unused,

Or said otherwise : the memory address space, not the RAM, is consumed
by the PCI address space.

> but as the
> Linux kernel uses a virtual memory system, the address space as
> mentioned above has been assigned to the PCI devices instead of to the
> RAM.

This is physical addressing defined by the motherboard. Nothing to do
with virtual memory. The 32-bit virtual memory address space is still 4 GiB.

[Aragorn]

On Sunday 13 October 2013 15:45, Pascal Hambourg conveyed the following

to alt.os.linux...

> A bit late, but...
>
> Aragorn a écrit :
>> On Friday 23 August 2013 14:51, Aragorn conveyed the following to
>> alt.os.linux...
>>
>>> Considering that memory addresses can only be assigned to one
>>> device, the RAM between (roughly) 3.1 GiB and 4 GiB is then consumed
>>> by the
>> ^^^^^^^^
>>> PCI address space and is not usable anymore as RAM, [...]
>>
>> Not "consumed" but obscured. It is still there and unused,
>
> Or said otherwise : the memory address space, not the RAM, is consumed
> by the PCI address space.

That is what I meant, yes. The address space is in use, but not the
RAM. And that means that if one wants access /to/ that obscured RAM,
this obscured RAM will have to be mapped to a different address space.

>> but as the Linux kernel uses a virtual memory system, the address
>> space as mentioned above has been assigned to the PCI devices instead
>> of to the RAM.
>
> This is physical addressing defined by the motherboard. Nothing to do
> with virtual memory. The 32-bit virtual memory address space is still
> 4 GiB.

I'm not sure exactly why I worded it wrongly, but I guess I was trying
to point out that, due to the nature of the virtual memory system of the
Linux kernel, the obscured RAM can be assigned with different addresses.
These addresses will then of course be above the 4 GiB barrier of 32-
bit, which means that one needs either a PAE kernel (which has 36 bits
for memory addressing, but in paged mode) or a 64-bit kernel (which also
uses PAE).

[Peter Köhlmann]

Aragorn wrote:

>
> I'm not sure exactly why I worded it wrongly, but I guess I was trying
> to point out that, due to the nature of the virtual memory system of the
> Linux kernel, the obscured RAM can be assigned with different addresses.
> These addresses will then of course be above the 4 GiB barrier of 32-
> bit, which means that one needs either a PAE kernel (which has 36 bits
> for memory addressing, but in paged mode) or a 64-bit kernel (which also
> uses PAE).
>

No. A 64bit kernel does not use PAE. That is a mode confined to 32bit mode

[Richard Kettlewell]

That’s not what the AMD64 System Programming guide says...

--
http://www.greenend.org.uk/rjk/

[Aragorn]

On Sunday 13 October 2013 16:15, Richard Kettlewell conveyed the
following to alt.os.linux...

Nor the Linux Kernel Configurator, for that matter.

[Peter Köhlmann]

Thats fine. It still is not used then. Since it is a Physical Address
Extension (for 32bit mode), you can't actually say with a straight face that
it would still be used in 64bits, since then the virtual address is 64bits
and physically addressable are ususally 48 bits

[Aragorn]

On Sunday 13 October 2013 18:31, Peter Köhlmann conveyed the following
to alt.os.linux...

> Richard Kettlewell wrote:
>
>> Peter Köhlmann <peter-k...@t-online.de> writes:
>>> Aragorn wrote:
>>
>>>> I'm not sure exactly why I worded it wrongly, but I guess I was
>>>> trying to point out that, due to the nature of the virtual memory
>>>> system of the Linux kernel, the obscured RAM can be assigned with
>>>> different addresses. These addresses will then of course be above
>>>> the 4 GiB barrier of 32- bit, which means that one needs either a
>>>> PAE kernel (which has 36 bits for memory addressing, but in paged
>>>> mode) or a 64-bit kernel (which also uses PAE).
>>>
>>> No. A 64bit kernel does not use PAE. That is a mode confined to
>>> 32bit mode
>>
>> That’s not what the AMD64 System Programming guide says...
>
> Thats fine. It still is not used then.

On the contrary, it *is* being used.

http://en.wikipedia.org/wiki/Physical_Address_Extension

[quote]

First implemented in the Intel Pentium Pro in 1995, it was extended by
AMD to add a level to the page table hierarchy, to allow it to handle
up to 52-bit physical addresses, add NX bit functionality, and make it
the mandatory memory paging model in long mode.

[/quote]

32-bit without PAE uses two pagetables. PAE offers a third pagetable,
which is used both by "32-bit with PAE" mode and 64-bit (alias "long
mode").

The PAE extensions are needed for the x86-64 processor to be able to
switch into long mode.

> Since it is a Physical Address Extension (for 32bit mode), you can't
> actually say with a straight face that it would still be used in
> 64bits, since then the virtual address is 64bits and physically
> addressable are ususally 48 bits

You misunderstand. It was originally designed /for/ 32-bits processors
- i.e. the i686 and compatibles - but AMD64 /has extended PAE/ and /is
using it as part of/ long mode operation.

[Richard Kettlewell]

I think you’d better take that up with AMD.

--
http://www.greenend.org.uk/rjk/

[Peter Köhlmann]

In 64bit mode no physical address extension is needed to pyhsically adddress
more than 4GB. That parts of the PAE-Hardware is used in 64bit mode does not
mean that "PAE is used in 64bit-mode"

[Aragorn]

On Sunday 13 October 2013 20:03, Peter Köhlmann conveyed the following

PAE *is both used and needed in 64-bit mode* in order to allow *three
pagetables* instead of two for regular 32-bit. The three pagetables are
what allow for the 64-bit memory addressing by way of *virtual memory*
as there aren't enough physical address lines to cover for the 64-bit
address space.

[Peter Köhlmann]

So we are talking about the same thing, just different semantics.
I already wrote that usually 48 bits of the 64 bits are used as address
lines. Not all 64 address lines are physically present (yet).

Then naturally some of the PAE hardware is used in 64 bit mode (as it is
already present for 32bit PAE-mode). It is still not really OK to call it
"PAE", as there is no "address extension" performed.

[Aragorn]

On Sunday 13 October 2013 20:44, Peter Köhlmann conveyed the following

Well, there is: for running 32-bit applications in a 64-bit operating
system. An individual process will still only see 4 GiB (kernel +
userspace) but the total amount of memory remains the same as in native
64-bit mode, as opposed to a 32-bit system with PAE, which then has
access to only 64 GiB of RAM.

And semantically it is okay to call it "physical address extensions"
even in 64-bit mode, because after all the third pagetable makes it
possible to address the capacity of 64-bit /virtual/ memory, even if the
machine physically supports /less/ than that. The third pagetable is an
extension, because native 32-bit without PAE only has two pagetables.

[Richard Kettlewell]

Aragorn <thor...@telenet.be.invalid> writes:
> The third pagetable is an extension, because native 32-bit without PAE
> only has two pagetables.

There may easily be hundreds or thousands of page tables. The thing
that there are two (legacy mode, CR4.PAE=0), three (legacy mode,
CR4.PAE=1) or four (long mode) of is levels in the page table hierarchy.

Performance implication of long mode not often mentioned: presumably TLB
misses are more expensive due to PML4 lookup. Hey, we’re back on topic.

--
http://www.greenend.org.uk/rjk/

[Pascal Hambourg]

Aragorn a écrit :

>
> I'm not sure exactly why I worded it wrongly, but I guess I was trying
> to point out that, due to the nature of the virtual memory system of the
> Linux kernel, the obscured RAM can be assigned with different addresses.

Again, this has nothing to do with virtual memory, Linux or any other
operating system. The RAM relocation beyond the 4 GiB range is purely a
hardware feature performed by the memory controller.

[Aragorn]

On Sunday 13 October 2013 22:17, Richard Kettlewell conveyed the
following to alt.os.linux...

> Aragorn <thor...@telenet.be.invalid> writes:
>
>> The third pagetable is an extension, because native 32-bit without
>> PAE only has two pagetables.
>
> There may easily be hundreds or thousands of page tables. The thing
> that there are two (legacy mode, CR4.PAE=0), three (legacy mode,
> CR4.PAE=1) or four (long mode) of is levels in the page table
> hierarchy.

Thank you for wording it more succinctly than I could, Richard. ;-)

> Performance implication of long mode not often mentioned: presumably
> TLB misses are more expensive due to PML4 lookup. Hey, we’re back on
> topic.

Yes, but personally I do maintain that having twice the amount of
registers (which are also twice as wide) would provide for a performance
gain.

Of course, there was a time when x86-64 was still new and lots of
software was written specifically for 32-bit, and by consequence, simply
recompiling the code to 64-bit would yield sub-optimal results. But
nowadays, that's behind us.

So the bottom line is that for some things, 64-bit will be faster than
32-bit, and for other things, 32-bit might be faster. I either way
doubt that it would be a 10% speed advantage in either case.

[Aragorn]

On Sunday 13 October 2013 22:28, Pascal Hambourg conveyed the following
to alt.os.linux...

It can be done either in hardware or in software. I've had a machine
where, when remapping of the obscured RAM was enabled in the hardware
itself, this would disable the ECC functionality of the memory
controller. However, the Linux kernel can itself also recuperate the
obscured RAM, even when the remapping is disabled in the BIOS. Look up
on SWIOTLB.

[Eef Hartman]

Peter Köhlmann <peter-k...@t-online.de> wrote:
> No. A 64bit kernel does not use PAE. That is a mode confined to 32bit mode

I _think_ a 64-bit kernel could use PAE, but then to address memory
beyond the 64-bit limit (the segment registers ARE still present, but
normally a 64-bit flat-address space is used, that is, all segment
registers contain 0). But I could be wrong, it might also be that
the EM64T technology cannot make use of the segment registers at all,
that only a 64-bit address is being used.
--
*****************************************************************
** Eef Hartman, Delft University of Technology, dept. EWI/CE **
** e-mail: E.J.M....@tudelft.nl - phone: +31-15-27 82525 **
*****************************************************************

[Richard Kettlewell]

Eef Hartman <E.J.M....@tudelft.nl> writes:
> Peter Köhlmann <peter-k...@t-online.de> wrote:
>> No. A 64bit kernel does not use PAE. That is a mode confined to 32bit
>> mode
>
> I _think_ a 64-bit kernel could use PAE, but then to address memory
> beyond the 64-bit limit (the segment registers ARE still present, but
> normally a 64-bit flat-address space is used, that is, all segment
> registers contain 0). But I could be wrong, it might also be that the
> EM64T technology cannot make use of the segment registers at all, that
> only a 64-bit address is being used.

DS, ES and SS are ignored in 64-bit mode.

CS is only used in a very limited way:

The CS-segment DPL, D, and L attributes are used (respectively) to
establish the privilege level for a program, the default operand size,
and whether the program is running in 64-bit mode or compatibility
mode.

It doesn’t feature in address calculations.

FS and GS, on the other hand, can be included into address calculations,
but this doesn’t escape any address size limits: they are not scaled,
everything still happens within a 64-bit word, and the virtual (and
physical) address limits still apply.

--
http://www.greenend.org.uk/rjk/

[Andy K]

On Saturday, August 17, 2013 6:38:31 AM UTC+8, Misha wrote:
> 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?

As far as Linux is concerned, NO, apps do not run slower as a general rule.

Linux is a little slower on movies than Windows.

I have compared 32 bit Windows XP with 64 bit Linux.

I have found Linux to be more efficient than Windoze in several categories.

Andy

[Mike Easter]

Andy K wrote:

> As far as Linux is concerned, NO, apps do not run slower as a general
> rule.
>
> Linux is a little slower on movies than Windows.
>
> I have compared 32 bit Windows XP with 64 bit Linux.
>
> I have found Linux to be more efficient than Windoze in several
> categories.

Recently Johnny Hwang in the alt.os.linux.suse group was successful in
converting from unacceptably ugly GG to cleanly formatted nntp
client-server usenet. Why don't you do the same.

Thread in GG
https://groups.google.com/forum/?hl=en#!topic/alt.os.linux.suse/Ad3Lt_K1SDg


One happy message in HK's tool:
http://al.howardknight.net/msgid.cgi?ID=138210632700

Item Date, ng, M-ID
From: Johnny
Newsgroups: alt.os.linux.suse
Subject: Re: Wireless problem: I have installed SUSE 12.3 on my laptop,
driver
for my BCM4311 as well, everything seems to run well, can connect to
my router, but cannot connect to internet.
Date: Fri, 18 Oct 2013 10:19:55 +0800
Message-ID: <52609ACB...@gmail.com>


abbreviated content:
Yes, Mike. I am using Thunderbird to browse this group now. It's much
cooler than Google group, although the configuration almost make me
annoy. :-)


--
Mike Easter