Personal opinion here but I know it is also held by many developers I
know and work with. I'd rather have a compiler that produces correct
and fast code but ran slow than one that produces slow or bad code and
runs fast. Remember compilation is done far less often than run time
execution. Yes I too noticed a difference when I switched over to 3.2
but I also noticed some of my code speed up.
>>>People keep extolling the virtues of gcc 3.2 to me, which I'm
>>>reluctant to switch to, since it compiles so much slower. But
>>>it supposedly generates better code, so I thought I'd compile
>>>the kernel with both and compare the results. This is gcc 2.95
>>>and 3.2.1 from debian unstable on a 16-way NUMA-Q. The kernbench
>>>tests still use 2.95 for the compile-time stuff.
>>
>>[SNIPPED tests...]
>
>
> What was the size of uncompressed kernel binaries?
> This is a simple (and somewhat inaccurate) measure of compiler
> improvement ;)
While I too like smaller tighter output code, I'd trade it for code that
runs faster in real world situations. As an example identifying the
most likely execution path through a routine and keeping it contiguous
in memory will do more for average execution speed than optimizing to
use the smallest number of bytes. If the compiler could tell which
blocks of code are for handling exceptions it then can place them ouside
of the main execution path. This makes the normal code execution path
smaller and more compact. In doing so it also reduces the number of
memory fetch operations and cache space needed to run the code. With
cache misses being 100+ clock cycles and page faults well into the
millions, keeping that normal execution path short means alot.
>>Don't let this get out, but egcs-2.91.66 compiled FFT code
>>works about 50 percent of the speed of whatever M$ uses for
>>Visual C++ Version 6.0 I was awfully disheartened when I
>
> Yes. M$ (and some other compilers) beat GCC badly.
But can M$'s compiler produce code for many radically different CPU
architectures? Most people only work with gcc on one type of CPU so
they never think about just how flexible and good GCC really is. I see
it often compaired against compilers that are dedicated to a single CPU
where the development team only has to worry about one CPU type. GCC's
development team needs to worry about many different arcitectures. Some
are radically different in their fundamental structure. This really
complicates the job of producing a compiler that works correctly.
- Bryan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Feb 07 2003 - 22:00:14 EST