1 |
Brandon Edens posted <20060425055400.GA8124@×××××.lan>, excerpted below, |
2 |
on Tue, 25 Apr 2006 01:54:00 -0400: |
3 |
|
4 |
> Having 16 (well actually only 12 according to the SBCL hackers) general |
5 |
> purpose registers (AMD64) versus x86's 8 GPRs is reason enough for me to |
6 |
> run AMD64. |
7 |
> |
8 |
> I believe the major performance bottle-neck in modern computers is |
9 |
> memory access latencies and the like. Not just RAM btw, I'm talking |
10 |
> about the memory hierarchy: register -> cache -> RAM -> hard-drive |
11 |
> (ordered by speed of access: left being fastest, right being slowest) |
12 |
> |
13 |
> Processor calculation speeds have improved at a faster rate than memory |
14 |
> access speeds. Your processor is essentially just sitting there idling |
15 |
> as it waits for instructions to be fed to it (starved). Having more |
16 |
> registers means you have a larger scratch-pad to perform calculations |
17 |
> on. |
18 |
|
19 |
This is the big reason AMD64 isn't simply a 64-bit address space over a |
20 |
32-bit one. Were it just that, it would actually be /worse/ than x86 for |
21 |
most desktop stuff, as the 64-bit address space and integers simply aren't |
22 |
needed by most software at this point, and doubling the size of parts of |
23 |
your code means less fits in memory, and it takes twice as long to move |
24 |
them around. |
25 |
|
26 |
The extra registers are the big thing that turns this AMD64 into an |
27 |
advantage in nearly all cases, over comparible x86. |
28 |
|
29 |
|
30 |
That's also why I tend to favor -Os and certain other similar |
31 |
optimizations (I add various register re-use and hot/cold function |
32 |
reordering flags as well, as the register optimizations will be very good |
33 |
for amd64, even at the cost of code size, and hot/cold function reordering |
34 |
regroups functions such that the frequently used ones stay in cache |
35 |
better, even at the expense of overall code size). Smaller code, given |
36 |
memory latencies, should be faster code, even if it's less efficient at |
37 |
the CPU itself, because that much more of the code fits in the next closer |
38 |
level of cache, that would otherwise be in far slower memory or cache |
39 |
futher from the CPU. |
40 |
|
41 |
That said, performance is one thing, human frustration is an entirely |
42 |
different thing. Because the (desktop/workstatiion) computer spends most |
43 |
of its time waiting for human input, an efficient human/computer interface |
44 |
is a far more important factor than all the others. Of course, one |
45 |
person's richly efficient interface is another's bloat, making it |
46 |
virtually impossible to benchmark. |
47 |
|
48 |
The reason I suggested going back to regular x86 Gentoo in this case is |
49 |
that it's quite apparent there's a lot of friction in that computer/human |
50 |
interface at present, and for him, x86 may just work best, at the moment. |
51 |
While it makes us geek types cringe at the supposed resource waste, is he |
52 |
actually wasting more /not/ using AMD64 because he's too frustrated with |
53 |
it, or smoothly using x86, which he knows and is comfortable with? There's |
54 |
nothing "wrong" wth using it in x86 mode, and if that's what suits is |
55 |
style best, then more power to him (literally, more power over the |
56 |
computer)! |
57 |
|
58 |
The thing is, it's his decision, not your or mine. He's the one living |
59 |
with the consequences. If he's more comfortable on x86, and all amd64 is |
60 |
giving him is frustration, then x86 is the way he should go. If he |
61 |
believes he can pull it out with the help of a chroot or the like, then |
62 |
let him try, but don't force it on him, and don't make him so despairing |
63 |
he quits Gentoo in frustration, when he's already said he's very |
64 |
comfortable with x86 Gentoo. |
65 |
|
66 |
-- |
67 |
Duncan - List replies preferred. No HTML msgs. |
68 |
"Every nonfree program has a lord, a master -- |
69 |
and if you use the program, he is your master." Richard Stallman in |
70 |
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html |
71 |
|
72 |
|
73 |
-- |
74 |
gentoo-amd64@g.o mailing list |