Re: More kernel performance tests on FreeBSD 10.0-CURRENT

On 2012-09-22 14:52, O. Hartmann wrote:
...
> 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?

The Intel compiler support has been largely removed, because it was not
maintained.  There are still remnants in cdefs.h though, and in theory
it could be revived, if there was enough interest.

However, Intel simply does not support anything else besides Windows and
Linux for its compiler suite, and even on the Linux side you are best
off if you use Red Hat or a Red Hat-based distribution such as CentOS or
Scientific Linux.

Some time ago I attempted to get a fairly recent Intel compiler version
working on FreeBSD, but it was very tricky, and I remember I did not get
everything working correctly.

So unless either Intel starts supporting FreeBSD (or other BSDs), which
is very unlikely, or somebody manages to get the Linux version working
perfectly as a port, I don't see much sense in restoring the Intel
compiler support.


> 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 ;-)

I think you see this incorrectly; when I removed the Intel compiler
support from the tree, it was unmaintained for several years already.
Apparently there was very little interest for it.


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

I don't think the amount of CPU cache, or the number of levels, is taken
into account, really.  When you select a certain CPU type with -march,
the compiler will just enable several features that are supported on
that CPU, e.g. MMX, SSE, AVX and so on.  It can also enable extra CPU
registers, and/or switch to slightly different instruction scheduling.

But since we are compiling the kernel with -mno-mmx, -mno-sse and even
floating point disabled, apparently there is no real gain from
specifying higher CPU types.

-Dimitry