porno trk porno rokettube
Page 1 of 2 12 LastLast
Results 1 to 20 of 26

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

  1. #1
    Ext User(Misha) Guest

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

    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?

  2. #2
    Ext User(mick) Guest

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

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

    --
    mick



  3. #3
    Ext User(Dominique) Guest

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

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

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

  4. #4
    Ext User(Wolf K) Guest

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

    On 2013-08-16 6:38 PM, 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?


    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

  5. #5
    Ext User(Paul) Guest

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

    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?


    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

  6. #6
    Ext User(JJ) Guest

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

    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.

    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.

  7. #7
    Ext User(J.O. Aho) Guest

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

    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


  8. #8
    Ext User(Jasen Betts) Guest

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

    On 2013-08-16, Misha <Misha@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: news@netfront.net ---

  9. #9
    Ext User(Jasen Betts) Guest

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

    On 2013-08-17, J.O. Aho <user@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/libr...=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.


    --
    ⚂⚃ 100% natural

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

  10. #10
    Ext User(Richard Kettlewell) Guest

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

    Misha <Misha@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/

  11. #11
    Ext User(J. P. Gilliver (John)) Guest

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

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

    In message <87bo4w8zp3.fsf@araminta.anjou.terraraq.org.uk>, Richard
    Kettlewell <rjk@greenend.org.uk> writes:
    >Misha <Misha@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

  12. #12
    Ext User(Richard Kettlewell) Guest

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

    "J. P. Gilliver (John)" <G6JPG@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 <rjk@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/

  13. #13
    Ext User(JJ) Guest

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

    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.

  14. #14
    Ext User(Pascal Hambourg) Guest

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

    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 ?

  15. #15
    Ext User(Misha) Guest

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

    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


  16. #16
    Ext User(Aragorn) Guest

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

    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

  17. #17
    Ext User(Ant) Guest

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

    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.

  18. #18
    Ext User(Wolf K) Guest

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

    On 2013-08-17 4:54 AM, Richard Kettlewell wrote:
    > Misha<Misha@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.

    --
    Best,
    Wolf K
    kirkwood40.blogspot.ca

  19. #19
    Ext User(J. P. Gilliver (John)) Guest

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

    In message <87haeo35ze.fsf@araminta.anjou.terraraq.org.uk>, Richard
    Kettlewell <rjk@greenend.org.uk> writes:
    >"J. P. Gilliver (John)" <G6JPG@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 <rjk@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.)

  20. #20
    Ext User(Paul) Guest

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

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



Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •