Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 22 Sep 2012 13:43:03 +0200
From:      Dimitry Andric <dimitry@andric.com>
To:        "O. Hartmann" <ohartman@zedat.fu-berlin.de>
Cc:        freebsd-current@FreeBSD.org, freebsd-toolchain@FreeBSD.org
Subject:   Re: More kernel performance tests on FreeBSD 10.0-CURRENT
Message-ID:  <505DA447.40601@andric.com>
In-Reply-To: <505D6A51.7090808@zedat.fu-berlin.de>
References:  <505CDE9C.3060504@andric.com> <505D6A51.7090808@zedat.fu-berlin.de>

next in thread | previous in thread | raw e-mail | index | archive | help
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. :)


> 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. :)


> 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.

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

-Dimitry



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?505DA447.40601>