Date: Sat, 22 Sep 2012 14:52:43 +0200 From: "O. Hartmann" <ohartman@zedat.fu-berlin.de> To: Dimitry Andric <dimitry@andric.com> Cc: freebsd-current@FreeBSD.org, freebsd-toolchain@FreeBSD.org Subject: Re: More kernel performance tests on FreeBSD 10.0-CURRENT Message-ID: <505DB49B.1090304@zedat.fu-berlin.de> In-Reply-To: <505DA447.40601@andric.com> References: <505CDE9C.3060504@andric.com> <505D6A51.7090808@zedat.fu-berlin.de> <505DA447.40601@andric.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig07897D17442F9B3244FF88FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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, t= he >> echo from the past. >=20 > 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. >=20 > 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. >=20 > 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 ;-) >=20 >=20 >> 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. >=20 > 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. >=20 > 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... >=20 > 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. >=20 >=20 >> What is about optimization level "-O3" and architectural recognition v= ia >> "-march=3Dnative"? >=20 > There are only so many things you can test, the possibilities are > literally endless! >=20 > I have already done a few preliminary tests for -march=3Dnative, 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? >=20 > 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 ;-) >=20 > -Dimitry Oliver --------------enig07897D17442F9B3244FF88FB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEbBAEBAgAGBQJQXbSgAAoJEOgBcD7A/5N8vlgH93GukRrmw0n+zBapKx0706Io Lb16BI64iUagseIuy94zQKPdEDPqWSJTt5JMTRBqXNi2LR8G8ntpJ1LAmhtdYNK+ xED+uesHYf3CITur085RHWfoMB5v95PMSkHPDtIaALpa+VZqFEfF2B2pG4W2ybkw CYELcUTMtz7C71hiPvFI6oQG2sDj3Zm479C2JMxW4JLCHPtx6H6gIGvEV6TjsGQ/ 3LI4CrgIovLBkoBRfUAi6qA1GPZ1l8aPRVDVvXrkV30jDU2pQD5708kNrcpK3XG7 NP0Bz7No6N1E7QuLrQ5EXqbN6XFcKYPBVheQXBNExNlc8efu9R8R+uA9+KFuLw== =lvvv -----END PGP SIGNATURE----- --------------enig07897D17442F9B3244FF88FB--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?505DB49B.1090304>