1 |
"Mark Knecht" <markknecht@×××××.com> posted |
2 |
5bdc1c8b0609141743y7c5f6042ncd0a596eb290c8ba@××××××××××.com, excerpted |
3 |
below, on Thu, 14 Sep 2006 17:43:19 -0700: |
4 |
|
5 |
> Now, you are very adept at this. You're explanations make sense to |
6 |
> the level I've considered them. (Not very far right now...) Main |
7 |
> questions: |
8 |
|
9 |
Adept, perhaps, but don't take my observations as being from God or |
10 |
anything! =8^) I try to be fairly cautious with my CFLAGS, but if |
11 |
anything quits working, I know how to undo them and try with a more |
12 |
generic set, and in fact do so from time to time on individual packages, |
13 |
before filing bugs on them. Sometimes it's my CFLAGS, tho usually my |
14 |
config doesn't matter a whit to the bug, as I've been reasonably cautious |
15 |
in my choices to begin with and don't tend to enable stuff like the unsafe |
16 |
floating-point math options that give folks problems from time to time. |
17 |
|
18 |
In particular, as you can see from the -ftree-vectorize subthread, I tend |
19 |
to stay with the defaults when I can't explain with some degree of |
20 |
confidence exactly what the effect of a flag might be and why I might or |
21 |
might not want it. I don't know enough about that area to do that, so |
22 |
I've stayed well away from it in my CFLAGS. |
23 |
|
24 |
> 1) What can be done to test this out at my end without making a 2-day |
25 |
> commitment to rebuild the complete machine. Is it possibly to rebuild |
26 |
> only portions of the machine using a different set of flags or is it a |
27 |
> system wide commitment requiring that I rebuild 575 packages as I did |
28 |
> last weekend? |
29 |
|
30 |
In general, you /can/ rebuild only a part of your system and test that, |
31 |
before making further changes. However, it's important to use a bit of |
32 |
(un?)common sense when doing so, or your results won't be worth much. |
33 |
Basically, in ordered to see how an optimization affects something, you |
34 |
must have some awareness of the shared libraries it uses and to what |
35 |
extent it uses them, recompiling enough of the heavily used dependencies |
36 |
that the critical parts of your test applications (including the libraries |
37 |
they load) are using the new optimizations. |
38 |
|
39 |
One lib that all applications make some use of is glibc, so it can be worth |
40 |
recompiling. It's a big recompile on its own, but of course nowhere near |
41 |
as big as recompiling the entire system. =8^) However, glibc is a special |
42 |
case in some aspects for a number of reasons. The glibc ebuild is pretty |
43 |
conservative with the flags it allows, and actually replaces -Os with -O2, |
44 |
due to problems -Os had mainly on x86, back in the gcc-3.2 and 3.3 era. |
45 |
Since the system is pretty horribly broken if glibc breaks, to the point |
46 |
you are likely to have to boot to a backup or liveCD to fix it, this isn't |
47 |
an unreasonable policy at all. |
48 |
|
49 |
None-the-less, after making doubly sure I had tested-working backups, I |
50 |
decided to see just what the effect of taking out that -Os -> -O2 replace |
51 |
in the glibc ebuild might be. For awhile I actually ran a glibc I had |
52 |
built after having removed that replace. The system continued to work |
53 |
just fine with a -Os compiled glibc, it didn't break or anything, but it |
54 |
didn't seem to be much better either and in some cases seemed worse. It |
55 |
turns out that glibc is built in a much more modular fashion than many |
56 |
libraries, so an app will only load the parts of it it needs, not the |
57 |
parts it doesn't, and that -Os doesn't work so well with this rather |
58 |
extreme (compared to most libs) modularization. As well, as I said, glibc |
59 |
is used by everything on the system, which meant that having bypassed one |
60 |
of the safeties in the glibc ebuild, I could never be sure whether a bug I |
61 |
was experiencing was due to my strange glibc, or to some problem with the |
62 |
package the bug was showing up in or one of its other dependencies. I |
63 |
concluded that it simply wasn't worth bypassing the safeties in the |
64 |
ebuild, and since then, have left them there. |
65 |
|
66 |
Thus, with glibc anyway, simply switching to -Os in your CFLAGS won't make |
67 |
any difference, since the ebuild replaces that with -O2 anyway. The |
68 |
/other/ CFLAGS might make a difference, but -Os it self won't, unless you |
69 |
bypass the replace in the ebuild, and as my experimentation demonstrated |
70 |
well enough for me, that's really not worth the trouble. As I said, the |
71 |
other CFLAGS may make a bit of difference tho, so you might consider it |
72 |
anyway, if you decide to try them. |
73 |
|
74 |
For X users, another library that's going to be commonly used is libX11. |
75 |
You'll probably want to recompile xorg-server (assuming modular-X) as |
76 |
well, plus whatever xf86-video-* driver you use, and libXcomposite if you |
77 |
use the composite extension (transparent windows and the like). Together, |
78 |
those will be pretty critical for performance of any X app. For OpenGL |
79 |
accelerated apps, mesa is likely to be critical to performance as well, |
80 |
for any functions not handled by hardware. |
81 |
|
82 |
For anything written in C++, almost anything KDE among other packages, gcc |
83 |
libstdc++, a part of gcc, will be critical. Other than for C++ |
84 |
apps/libraries, recompiling gcc with new CFLAGS shouldn't make that much |
85 |
difference in how the app runs, tho it might make some difference in how |
86 |
fast compiles the app. (Of course, note that compile speed can be |
87 |
dramatically affected by the optimizations being compiled, since many of |
88 |
them cause additional passes in the process, to catch that little bit of |
89 |
extra optimization you are telling gcc to enable. Tell gcc to do more |
90 |
work and of course it'll take longer doing it!) |
91 |
|
92 |
You mentioned gnome. For anything gnome related, you'll want to recompile |
93 |
glib, gtk, libgnome, possibly orbit, and maybe others (your window |
94 |
manager). I don't know enough about gnome internals to go further with it. |
95 |
With KDE, it'd be qt and kdelibs (plus as I mentioned gcc, for libstdc++), |
96 |
kwin, probably kicker and konqueror, etc, plus the packages behind various |
97 |
kparts as used in whatever app you are testing, as well as the app itself. |
98 |
|
99 |
> 2) What about building the kernel? How do the standard |
100 |
> |
101 |
> make && make modules_install |
102 |
> |
103 |
> command make any use of the flags in /etc/make.conf? |
104 |
|
105 |
They normally don't. However, as is commonly the case with manually |
106 |
compiled packages, the kernel build process makes use of CFLAGS if it |
107 |
finds that environment variable set. Thus, you can source make.conf, |
108 |
export the desired variables, and go from there. In fact, I have a small |
109 |
utility script installed as /usr/local/bin/buildflags.sh that contains the |
110 |
following: |
111 |
|
112 |
# Source this previous to doing a manual build to import portage buildflags |
113 |
|
114 |
[ -z "$CFLAGS" ] && CFLAGS="`. /etc/make.conf 2>/dev/null; echo $CFLAGS`" |
115 |
[ -z "$CXXFLAGS" ] && CXXFLAGS="`. /etc/make.conf 2>/dev/null; echo $CXXFLAGS`" |
116 |
[ -z "$LDFLAGS" ] && LDFLAGS="`. /etc/make.conf 2>/dev/null; echo $LDFLAGS`" |
117 |
export CFLAGS CXXFLAGS LDFLAGS |
118 |
|
119 |
As you can see, that gathers and exports the three build variables CFLAGS, |
120 |
CXXFLAGS, and LDFLAGS. If I source that into my running shell before I |
121 |
build anything (including the kernel) manually, the build should see my |
122 |
existing environment and compile accordingly. |
123 |
|
124 |
As it happens, I use a script to compile and install the kernel, as well, |
125 |
and it sources buildflags.sh before it does the kernel compile. |
126 |
|
127 |
/usr/local/sbin/ki (for kernel install: |
128 |
|
129 |
#!/bin/bash |
130 |
# kernel compile and install |
131 |
echo |
132 |
echo sourcing buildflags |
133 |
ki_buildflagfile=/usr/local/bin/buildflags.sh |
134 |
if [ -f $ki_buildflagfile ] ; then |
135 |
. $ki_buildflagfile |
136 |
else |
137 |
pause 10 x \\a$ki_buildflagfile doesn\'t exist |
138 |
fi |
139 |
unset buildflagfile |
140 |
|
141 |
echo |
142 |
echo cd-ing to /usr/src/linux |
143 |
cd /usr/src/linux |
144 |
echo Next: make |
145 |
sleep 1 |
146 |
echo |
147 |
make || exit 1 |
148 |
echo |
149 |
echo Next: make modules_install |
150 |
sleep 1 |
151 |
echo |
152 |
make modules_install || exit 2 |
153 |
echo |
154 |
echo Next: mount /boot |
155 |
sleep 1 |
156 |
echo |
157 |
mount /boot &>/dev/null |
158 |
echo |
159 |
echo Next: make install |
160 |
sleep 1 |
161 |
echo |
162 |
make install || exit 3 |
163 |
echo |
164 |
echo Next: umount /boot |
165 |
sleep 1 |
166 |
echo |
167 |
umount /boot &>/dev/null |
168 |
echo Done. |
169 |
echo |
170 |
|
171 |
In addition to using buildflags.sh, that script also uses a utility script |
172 |
I've written called pause, installed as /usr/local/bin/pause (and also as |
173 |
/bin/pause here, so I can use it to debug initscripts before /usr/local is |
174 |
mounted). |
175 |
|
176 |
#!/bin/bash |
177 |
|
178 |
# putting everything in a function to allow local scoped vars |
179 |
function doit { |
180 |
echo |
181 |
local PROMPT="Pause for char" |
182 |
case $# in |
183 |
0) read -n1 -p "$PROMPT:";; |
184 |
1) if [ $1 == "--help" -o $1 == "-h" -o $1 == "-?" ] |
185 |
then |
186 |
echo $PROMPT script utility. |
187 |
echo |
188 |
echo Usage: pause [timeoutsec [defaultchar [promptstring]]] |
189 |
echo \ \ \ \ \ \ \ pause \(--help\|-h\|-?\) |
190 |
echo |
191 |
echo Source pause to have \$REPLY set to the returned char. |
192 |
echo |
193 |
echo A timeoutsec of 0 indicates no timeout. Otherwise, |
194 |
echo on timeout, defaultchar if provided is returned in \$REPLY. |
195 |
echo |
196 |
echo With timeout and defaultchar, promptstring defaults to: |
197 |
echo $PROMPT \(default defaultchar in timeoutsec\): |
198 |
echo With just a timeout, prompt default is: |
199 |
echo $PROMPT \(timeout timeoutsec\): |
200 |
echo Without a timeout, the default is: |
201 |
echo $PROMPT: |
202 |
echo |
203 |
echo |
204 |
elif [ $1 == 0 ] |
205 |
then read -n1 -p "$PROMPT:" |
206 |
else read -n1 -t$1 -p "$PROMPT (timeout $1):"; echo |
207 |
fi;; |
208 |
2) if [ $1 == 0 ] |
209 |
then read -n1 -p "$PROMPT:" |
210 |
else |
211 |
read -n1 -t$1 -p "$PROMPT (default $2 in $1):"; echo |
212 |
REPLY=${REPLY:-$2} |
213 |
fi;; |
214 |
*) if [ $1 == 0 ] |
215 |
then |
216 |
shift 2 |
217 |
echo -e $* |
218 |
read -n1 |
219 |
else |
220 |
local TIMEOUT=$1 DEFAULTCHAR=$2; shift 2 |
221 |
echo -e $* |
222 |
read -n1 -t$TIMEOUT; echo |
223 |
REPLY=${REPLY:-$DEFAULTCHAR} |
224 |
fi;; |
225 |
esac |
226 |
echo |
227 |
} |
228 |
|
229 |
doit $* |
230 |
|
231 |
Obviously, I've taken a bit more time to properly document pause, so you |
232 |
can run pause -h or --help to get the usual usage summary. The other two |
233 |
scripts aren't so nicely --help equipped; you have to look at the source |
234 |
to see what they are doing. I've found pause to be very useful over the |
235 |
years. =8^) |
236 |
|
237 |
As you can see, I routinely compile the kernel with my chosen CFLAGS, and |
238 |
it works fine here. Of course, your kernel config will be different and I |
239 |
can't vouch for every single driver, but the concept is sane and my CFLAGS |
240 |
are demonstrated to work with the core kernel and the drivers I use, |
241 |
anyway. |
242 |
|
243 |
As Greg mentions, there's also a compile for size option in the kernel |
244 |
config, and I have it enabled as well. It enables -Os, but I think it |
245 |
does a few other kernel specific things as well. I've never looked into |
246 |
it in detail, but I know I've had it enabled every since its introduction |
247 |
some kernels ago, with the accompanying coverage in LWN. That coverage in |
248 |
fact was what got me started on the whole -Os thing, before I'd even |
249 |
switched to Gentoo with 2004.1 and was still on Mandrake IIRC, so it has |
250 |
been a kernel option and I've been using it for over two years now. |
251 |
|
252 |
-- |
253 |
Duncan - List replies preferred. No HTML msgs. |
254 |
"Every nonfree program has a lord, a master -- |
255 |
and if you use the program, he is your master." Richard Stallman |
256 |
|
257 |
-- |
258 |
gentoo-amd64@g.o mailing list |