Date: Sat, 22 Sep 2012 15:52:25 +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: <505DC299.4090407@andric.com> In-Reply-To: <505DB49B.1090304@zedat.fu-berlin.de> References: <505CDE9C.3060504@andric.com> <505D6A51.7090808@zedat.fu-berlin.de> <505DA447.40601@andric.com> <505DB49B.1090304@zedat.fu-berlin.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?505DC299.4090407>