On Tuesday 30 October 2007 18:47:28 Jan Engelhardt wrote:
> 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;
Program was aborted with signal 11.
0 = 1337 is not good programming :)
Did you mean *x = 1337;
In either case, I wouldn't expect "1337" to be compiled into a memory lookup.
That seems a bit inefficient.
--
Madness takes its toll
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
