1 |
Duncan wrote: |
2 |
>>Athlon64 something (forgot what, but shouldn't matter anyway) with 1 MB |
3 |
>>L2-cache is 4% faster than an Athlon64 of the same frequency but with only 512kB |
4 |
>>L2-cache. The bigger the cache sizes you compare get, the smaller the |
5 |
>>performance increase. Since you run a dual Opteron system with 1 MB L2 |
6 |
>>cache per CPU I tend to say that the actual performance increase you |
7 |
>>experience is about 3%. But then I didn't take into account that -Os |
8 |
>>leaves out a few optimizations which would be included by -O2, the |
9 |
>>default optimization level, which actually makes the code a bit slower |
10 |
>>when compared to -O2. So, the performance increase you really experience |
11 |
>>shrinks to about 0-2%. I'd tend to proclaim that -O2 is even faster for |
12 |
>>most of the code, but that's only my feeling. |
13 |
> |
14 |
> |
15 |
> Interesting, indeed. I'd counter that it likely has to do with how many |
16 |
> tasks are being juggled as well, plus the number of kernel/user context |
17 |
> switches, of course. I wonder under what load, and with what task-type, |
18 |
> the above 4% difference was measured. |
19 |
> |
20 |
> Of course, the definitive way to end the argument would be to do some |
21 |
> profiling and get some hard numbers, but I don't think either you or I |
22 |
> consider it an important enough factor in our lives to go to /that/ sort |
23 |
> of trouble. <g> |
24 |
|
25 |
Indeed, I'd rather say I have no clue than go and perform tests :D |
26 |
|
27 |
>>You are referring a lot to the gcc manpage, but obviously you missed |
28 |
>>this part: |
29 |
>> |
30 |
>> -fomit-frame-pointer |
31 |
>> Don't keep the frame pointer in a register for functions that |
32 |
>> don't need one. This avoids the instructions to save, set up |
33 |
>> and restore frame pointers; it also makes an extra register |
34 |
>> available in many functions. It also makes debugging |
35 |
>> impossible on some machines. |
36 |
>> |
37 |
>> On some machines, such as the VAX, this flag has no effect, |
38 |
>> because the standard calling sequence automatically handles |
39 |
>> the frame pointer and nothing is saved by pretending it |
40 |
>> doesn't exist. The machine-description macro |
41 |
>> "FRAME_POINTER_REQUIRED" controls whether a target machine |
42 |
>> supports this flag. |
43 |
>> |
44 |
>> Enabled at levels -O, -O2, -O3, -Os. |
45 |
>> |
46 |
>>I have to say that I am a bit disappointed now. You seemed to be one of |
47 |
>>those people who actually inform themselves before sticking new flags |
48 |
>>into their CFLAGS. |
49 |
> |
50 |
> |
51 |
> ?? |
52 |
> |
53 |
> I'm not sure which way you mean this. It was in my CFLAGS list, but I |
54 |
> didn't discuss it as it's fairly common (from my observation, nearly as |
55 |
> common as -pipe) and seems fairly non-controversial on Gentoo. Did you |
56 |
> miss it in my CFLAGS and are saying I should be using it, or did you see |
57 |
> it and are saying its unnecessary and redundant because it's enabled by |
58 |
> the -Os? |
59 |
> |
60 |
|
61 |
|
62 |
> If the latter, yes, but as mentioned above in the context of glibc, -Os is |
63 |
> sometimes stripped. In that case, the redundancy of having the basic |
64 |
> -fomit-frame-pointer is useful, unless it's also stripped, but as I said, |
65 |
> it seems much less controversial than some flags and is often |
66 |
> specifically allowed where most are stripped. |
67 |
|
68 |
> Or, are you saying I should avoid it due to the debugging implications? I |
69 |
> don't quite get it. |
70 |
|
71 |
On amd64 frame-pointers aren't needed to do debugging, so that's |
72 |
|
73 |
> |
74 |
>>>!!! Relying on the shell to locate gcc, this may break !!! DISTCC, |
75 |
>>>installing gcc-config and setting your current gcc !!! profile will fix |
76 |
>>>this |
77 |
>>> |
78 |
>>>Another warning, likewise to stderr and thus not in the eis output. |
79 |
>>>This one is due to the fact that eselect, the eventual systemwide |
80 |
>>>replacement for gcc-config and a number of other commands, uses a |
81 |
>>>different method to set the compiler than gcc-config did, and portage |
82 |
>>>hasn't been adjusted to full compatibility just yet. Portage finds the |
83 |
>>>proper gcc just fine for itself, but there'd be problems if distcc was |
84 |
>>>involved, thus the warning. |
85 |
>> |
86 |
>>Didn't know about this. Have you filed a bug yet on the topic? Or is |
87 |
>>there already one? |
88 |
> |
89 |
> |
90 |
> There is one. I don't recall if I filed it or if it was already there, |
91 |
> but both JH and the portage folks know about the issue. IIRC, the portage |
92 |
> folks decided it was their side that needed changed, but that required |
93 |
> changes to the distcc package, and I don't know how that has gone since I |
94 |
> don't use distcc, except that I was slightly surprised to see the warning |
95 |
> in portage 2.1 still. |
96 |
> |
97 |
> |
98 |
>>>MAKEOPTS="-j4" |
99 |
>>> |
100 |
>>>The four jobs is nice for a dual-CPU system -- when it works. |
101 |
>>>Unfortunately, the unpack and configure steps are serialized, so the |
102 |
>>>jobs option does little good, there. To make most efficient use of the |
103 |
>>>available cycles when I have a lot to merge, therefore, I'll run as |
104 |
>>>many as five merges in parallel. I do this quite regularly with KDE |
105 |
>>>upgrades like the one to 3.5.1, where I use the split KDE ebuilds and |
106 |
>>>have something north of 100 packages to merge before KDE is fully |
107 |
>>>upgraded. |
108 |
>> |
109 |
>>I really wonder how you would paralellize unpacking and configuring a |
110 |
>>package. |
111 |
> |
112 |
> |
113 |
> That's what was nice about configcache, which was supposed to be in the |
114 |
> next portage, but I haven't seen or heard anything about it for awhile, |
115 |
> and the next portage, 2.1, is what I'm using. configcache seriously |
116 |
> shortened that stage of the build, leaving more of it parallelized, but... |
117 |
> |
118 |
> I was using it for awhile, patching successive versions of portage, but it |
119 |
> broke about the time sandbox split, the dev said he wasn't maintaining the |
120 |
> old version since it was going in the new portage, and I tried updating |
121 |
> the patch but eventually ran into what I think were unrelated issues but |
122 |
> decided to drop that in one of my troubleshooting steps and never picked |
123 |
> it up again. |
124 |
> |
125 |
> I'd certainly like to have it back again, tho. If it's working in 2.1, |
126 |
> I've not seen it documented or seen any hints in the emerge output, as |
127 |
> were there before. You seen or heard anything? |
128 |
> |
129 |
> BTW, what is your opinion on -ftracer? Several devs I've noticed use it, |
130 |
> but the manpage says it's not that useful without active profiling, which |
131 |
> means compiling, profiling, and recompiling, AFAIK. It's possible the |
132 |
> devs running it do that, but I doubt it, and otherwise, I don't see that |
133 |
> it should be that useful? I don't know if you run it, but since I've got |
134 |
> your attention, I thought I'd ask what you think about it. Is there |
135 |
> something of significance I'm missing, or are they, or are they actually |
136 |
> doing that compile/profile/recompile thing? It just doesn't make sense to |
137 |
> me. I've seen it in several user posted CFLAGS as well, but I'll bet a |
138 |
> good portion of them are simply because they saw it in a dev's CFLAGS and |
139 |
> decided it looked useful, not because they understand any implications |
140 |
> stated in the manpage. (Not that I always do either, but... <g>) |
141 |
> |
142 |
|
143 |
|
144 |
-- |
145 |
Simon Stelling |
146 |
Gentoo/AMD64 Operational Co-Lead |
147 |
blubb@g.o |
148 |
-- |
149 |
gentoo-amd64@g.o mailing list |