As Robert pointed out, we've talked through all of this on the dev lists
(and here, as well, I think) in the past.
The benefits of extreme optimizations are barely measurable, and
sometimes negative. Somewhere in the range of 2-3% with the best
possible combination. Because of a history of Squid tickling certain
compiler bugs in GCC, it is probably most wise to use a straight -O2
compile, perhaps with architecture specific options (i.e. your choice of
-march is fine, as is -fomit-frame-pointers--these are both configured
in my package build environment).
And speaking of my RPMS, you have forgotten about the rpmrc. When I do
use optimizations, they are not in the spec file, they are in the rpmrc
of my build environment. But nothing sneaky going on with my Squid
RPMs...they are just what they seem, very standard -O2 optimizations,
with a few possible target=arch options, and fomit-frame-pointers, and
maybe one or two others--I haven't looked in my rpmrc in months).
GCC has gotten much better, but I've still run into some interesting
Squid crashers which were GCC related. So I'd say avoid anything edgy
in the compiler. Squid isn't really the type of code that benefits from
such optimizations anyway--it doesn't have any tight loops where CPU
cache hits can make a big difference, it has large datasets, with little
room for micro-optimizations to do their job.
Steve Snyder wrote:
> Every once in a while I re-examine the way I'm configuring and building
> Squid, including the compiler optimizations used to build the code.
>
> I understand that I/O will always be the bottleneck in Squid performance,
> but surely improving in-memory object searches merits at least looking at
> CPU optimizations. On my Pentium3 box (RedHat v7.2, Linux kernel
> v2.4.18) I've been building with GCC compiler switches "-march=i686 -O3
> -fomit-frame-pointers". I'm wondering if Squid would benefit from more
> esoteric optimizations, like more stringent variable alignment or less
> stringent examination of floating-point values.
>
> Curious as to how the professionals are doing it, I examined the latest
> Squid SRPM package (squid-2.4.STABLE4-2.src.rpm) on Swell Technology's
> Web site. I was suprised to see no compiler optimization flags at all in
> the build (at least not in the squid.spec file). Are the benefits of CPU
> optimization in Squid really so trivial that they don't bear examination?
>
> Anyway, is there any consensus on how best to compile Squid on a Linux
> i686 system?
>
> Thanks.
-- Joe Cooper <joe@swelltech.com> http://www.swelltech.com Web Caching Appliances and SupportReceived on Sun Mar 17 2002 - 11:46:31 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 17:06:57 MST