On Sun, 13 Jul 2003, Ulrich Weigand wrote:
> Leland Lucius wrote:
>
> >So, why not run 31-bit Linux guests? Does it matter one way or the other?
> >Are there performance differences?
>
> Not a stupid question, but a quite interesting one ...
>
> There are many factors involved in the decision between 31-bit
> and 64-bit, and some favor the one and others the second option.
> What results in the best performance depends very much on the
> particular application you want to run.
>
> In the following, I've listed the most important of those factors
> (ordered from favoring 64-bit to favoring 31-bit):
>
> 1. Virtual address space size
> This is the obvious reason for wanting 64-bit: if your application
> needs (or runs significantly faster with) a > 2GB address space,
> you want 64-bit. This applies to 'large' applications like SAP,
> databases, large Java application server environments etc.
>
> 2. Physical memory size
> Even if your applications are OK with < 2GB address spaces, you might
> want to utilize > 2GB physical memory, e.g. because the total size
> of multiple running applications exceed 2 GB, or because you need
> a lot of page cache.
Does this mean "Use 64-bit VM?"
>
> 3. 64-bit arithmetic
> If your application performs 64-bit arithmetic ('long long' data types),
> you will benefit from the fact that those are implemented as native
> assembler instructions on 64-bit. (However, most applications don't
> do that ...)
Picky, I know, but they all do. File sizes are 64-bit, and probably some
other system datatypes too.
>
> 4. Other instruction set benefits
> Even for 'normal' purposes, the 64-bit instruction set has a couple
> of advantages, e.g. the LARL and BRASL instructions. This gives a
> (slight) benefit to 64-bit code.
>
> 5. Memory management overhead
> On the negative side, on a 64-bit system virtual address spaces
> are managed via three-level instead of two-level page tables.
> This implies a (slight) additional overhead both for the kernel
> when performing any operation on the page tables and for the
> processor itself when performing a page table lookup.
Is this so even when the actual storage size doesn't warrant it?
>
> 6. Larger code size
> Typical 64-bit code uses a lot more 6-byte instructions than 31-bit
> code, resulting in an average executable size increase of 10-20%.
> This implies a performance disadvantage due to e.g. i-cache pressure.
>
> 7. Larger data size
> 64-bit code is most seriously disadvantaged due to the fact that in
> compiled C code, all pointer and 'long' data types now take up 8
> instead of 4 bytes of memory. This means performance disadvantages
> due to d-cache pressure and slower accesses, in particular for
> applications that do 'pointer chasing' (linked lists etc.)
>
>
> All in all, the situation is that *some* applications benefit to
> a large degree from the advantages of 64-bit (address space size,
> 64-bit arithmetic etc.), while *all* applications take a small hit
> due to the disadvantages. (Those amount to a performance hit of
> about 5% on average, but varying strongly.)
>
> As a recommendation I'd suggest to use 64-bit in those cases
> where clear benefits warrant it, and otherwise stay with 31-bit.
>
> (There is also a third option of running 31-bit applications
> under a 64-bit kernel, which can in some cases combine the
> benefit of faster and smaller 31-bit code with a larger amount
> of physical memory.)
Those who were technically-involved with OS/2 will recall the term
"thunking," referring to the mapping of addresses between 16-bit code
and 32-bit, both for 16-bit applications and for drivers.
Is there a similar issue with moxed-mode operations on the Zeds?
--
Cheers
John.
Join the "Linux Support by Small Businesses" list at
http://mail.computerdatasafe.com.au/mailman/listinfo/lssb
Copyright John Summerfield. Reproduction prohibited.
