On Oct 30 2007 10:20, Randall R Schulz wrote:
>On Tuesday 30 October 2007 09:42, Russell Jones wrote:
>> Randall R Schulz wrote:
>> > On Tuesday 30 October 2007 08:58, Patrick Shanahan wrote:
>> >> * BandiPat <[EMAIL PROTECTED]> [10-30-07 11:54]:
>> >> [...]
>> >>
>> > But why? Do you run applications that need a 64-bit address space?
Even if you use a "36-bit" PAE kernel, it can only give a process
a 32-bit address space.
You want at least a 64-bit kernel. Everyone does that on SUN processors
even though 64 bitisms are more expensive there.
>> > If not, it's only more execution overhead to move nearly twice as
>> > much data around to get any given task done. The fact that the main
>> > system busses are 64-bits wide does not negate this overhead. [...]
>>
>> 64-bit machines don't use much more RAM.
>
>This is not primarily about RAM required, but about the volume of data
>that must be moved between the CPU and main store to get any given
>computational task done. 64-bit code uses 64-bit pointers and 64-bit
>integers, and for any given hardware configuration, moving twice as
>much data takes twice as long.
AMD64 is *NOT* the same as SPARC64. If it were, it would not sell.
For yer commodity x64-bit processor:
64 bits are moved between registers as fast as 32, 16 or 8 bits are.
For yer commodity x86/32-bit processor:
32 bits are moved between registers as fast as 16 or 8 bits are.
While the volume does not really change in register transfers,
neither does the speed.
And programs that actually move data between the CPU and memory
do not automatically have to transfer more data (that is, if you
were not drunk while writing the program).
Have a cookie:
char big[1048576]; /* 1 MB */
memset(big, 0, sizeof(big));
What's faster - 256K 32-bit writes or 128K 64-bit writes? (Hint: the
latter because you need to do half the number of loops.)
Your "volume" argument is - except for the drunk case mentioned above -
totally moot.
>Any program that
>accesses native sizes (pointers and integers, basically) and does so
>sequentially and with a relatively small amount of processing within
>the CPU per item transferred will exhibit nearly a twofold reduction in
>sustained processing when switching to a 64-bit ISA.
>[...]
>That's why there is no point in running in 64-bit mode unless you're
>running applications that need to or are significantly advantaged by
>operating in a 64-bit virtual address space. Which in turn is an
>advantage only if you have more then 4 GB of physical memory.
Obviously you had never had a look at the AMD64 instruction set.
It features new addressing modes such as RIP-relative,
where pointers are usually 16 to 80 bits only.
Another cookie:
int p = 0;
int *x = &p;
int main(void)
{
*p = 1337;
}
yields (for both 64-bit and 64-bit PIC):
400510: 48 8b 05 11 0b 20 00 mov 2099985(%rip),%rax
7 bytes for what most people would think could have been a 10 byte insn.
Even more interestingly, the same piece of code gets translated into
11 bytes in 32-bit, or even *13* bytes in 32-bit PIC mode (which is
what most shared libraries and new programs use).
80483d1: a1 18 a0 04 08 mov 0x804a018,%eax
80483d6: c7 00 39 05 00 00 movl $0x539,(%eax)
PIC:
8048401: 8b 83 fc ff ff ff mov 0xfffffffc(%ebx),%eax
8048407: 8b 00 mov (%eax),%eax
8048409: c7 00 39 05 00 00 movl $0x539,(%eax)
Thanks for taking the time to think about it!
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
