Re: More kernel performance tests on FreeBSD 10.0-CURRENT

Hello Dimitry.


Am 09/22/12 13:43, schrieb Dimitry Andric:
> On 2012-09-22 09:35, O. Hartmann wrote:
>> Am 09/21/12 23:39, schrieb Dimitry Andric:
> ...
>> At least one can say FreeBSD does not suffer from performance drain
>> using the cutting edge clang 3.2 compared with a gcc 4.2.1 compiler, the
>> echo from the past.
> 
> Well, the main idea of these tests is to prove that we will have no
> regression, or even an improvement in performance, if we make clang
> 3.2 the default compiler for FreeBSD 10.0, instead of gcc 4.2.1.  And
> that seems to be the case, at least for the kernel.
> 
> That said, for one of the earlier tests, it seemed that for runtime
> performance, gcc 4.7.1-compiled programs (in this case clang 3.2
> executables) were slightly faster than clang 3.2-compiled ones.
> 
> In my opinion that result is not bad for such a relatively new
> compiler, against such a well-established one. :)

Aggreed.
You're completely right and said so, there is then, except serious bugs
or miscompilations, no reason to stay with the dinosaur gcc 4.2.1 ;-)

> 
> 
>> Dimirty, are you planning also to benchmark clang 3.2 versus gcc 4.8.0?
>>  From the development point of view, such a benchmark would be more
>> natural, but I do not know whether the kernel sources are gcc
>> 4.8-friendly and would allow such a test.
> 
> The kernel sources are currentely not very friendly to anything but
> our in-tree gcc and clang.  We hacked our version of gcc to recognize
> several non-standard flags, such as -fformat-extensions, and a few
> others.  We also implemented the -fformat-extensions flag for clang,
> since our custom printf format specifiers are used throughout the
> kernel.
> 
> Ideally, we would remove all these non-standard flags and format
> specifiers, which would make it possible to compile the kernel with
> any version of gcc or clang, even external ones installed from ports,
> or by hand.  This is not a trivial task...
> 
> But maybe I'll take a shot, it would be nice to have at least one
> comparison against more modern gcc.  I can't give any serious ETA,
> though. :)

When we used FreeBSD for scientific work, that was around 1998 - 2002,
there were some attempts made to use Intel's icc compiler suite on
FreeBSD in the 32Bit Linuxulator. That time I used that compiler only
for compiling my modelling software, but there where reports of people
made it possible to use the icc compiler also for compiling the FreeBSD
system - with success as far as I know. What happened since then and
more recent days that the sources got "polluted" by those hacks?

No offense to you, but somehow this sounds that the efford has been
placed in the wrong way since people revert with energy that what has
been hacked with energy ;-)

Neverthelesse, something is happeneing ... and this sounds good to me.

> 
> 
>> What is about optimization level "-O3" and architectural recognition via
>> "-march=native"?
> 
> There are only so many things you can test, the possibilities are
> literally endless!
> 
> I have already done a few preliminary tests for -march=native, but at
> least for clang, there seems to be no measureable difference in
> performance.  The tests for gcc are still running.

I was wondering if the organisation and amount of cache present in a
modern CPU is not taken into account when optimising code. Our Core2Duo
CPUs still in use do have different architectural features than the more
recent Core-i7 systems. Latter ones have level 3 caches. How does a
compiler take advantage of those features by not given an explicit hint?



> 
> And indeed, -O3 is also a possibility, but again I think the difference
> will be very marginal, if measurable at all.

Well, speaking of marginality: some of our models rund for a week, some
other long term models run for 4 weeks. Consider now a performce gain of
10% average. I'd like to have it ... it saves me time ;-)

> 
> -Dimitry

Oliver