[cfe-dev] Clang and libc++ in FreeBSD 10

[Dimitry Andric]

On Oct 18, 2013, at 13:53, C. Bergström <cbergstrom at pathscale.com> wrote:
> Was any performance measurement or code size done? I realize this may be a lot of flat userland code without much critical sections, but still would be interesting. Last time anyone commented on it -they said ~1% for mysql 

Last year I did some performance testing on FreeBSD, comparing various versions of gcc (4.2.1 and 4.7.1) and clang (3.1 and 3.2).  These tests were mostly about performance of the compiler itself, and of the operating system.  One of the first things I did was to compare the performance of the compilers themselves:

http://lists.freebsd.org/pipermail/freebsd-current/2012-September/036380.html

It showed quite clearly that the stories (mostly spread on the FreeBSD mailing lists and/or IRC channels) about clang supposedly taking much more memory and CPU than gcc were not only overblown, but it was actually the other way around, in most cases.  (Of course I am sure it is possible to find code on which clang performs very horribly against gcc, but that would not be 'regular' code in any sense. :)

The next test I did was to compile the FreeBSD kernel with gcc 4.2 and clang 3.2, and compare the run-time performance of the resulting kernel binaries:

http://lists.freebsd.org/pipermail/freebsd-current/2012-September/036618.html

This showed a slight speed advantage (~4%) for the clang-compiled kernel binary.  Because this test was done on a slightly older Xeon machine, some people asked me to repeat it on a newer Core architecture machine:

http://lists.freebsd.org/pipermail/freebsd-current/2012-September/036756.html

This last test showed an even greater speed advantage (~10%) for the clang-compiled kernel.

Note these last tests were not comparing gcc 4.7 (the then-current stable version) against clang, because nobody has yet done the work to make the FreeBSD kernel compile with newer gcc versions.


> I'm curious why libunwind wasn't used... ?

Somebody just needed to commit to doing the grunt-work, and it apparently did not happen. :)

-Dimitry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20131018/fec35eed/attachment.sig>