Date: Mon, 18 Jun 2012 15:12:23 +0200 (CEST) From: Wojciech Puchar <wojtek@wojtek.tensor.gdynia.pl> To: Mark Blackman <mark@exonetric.com> Cc: Mark Felder <feld@feld.me>, freebsd-questions@freebsd.org Subject: Re: Why Clang Message-ID: <alpine.BSF.2.00.1206181440260.11774@wojtek.tensor.gdynia.pl> In-Reply-To: <7B54F8CE-9CA5-4C06-B3D8-F365A67A5300@exonetric.com> References: <4FCF9333.70201@speakeasy.org> <4FCF9C07.2000607@FreeBSD.org> <alpine.BSF.2.00.1206161815550.41364@wojtek.tensor.gdynia.pl> <op.wf0i64pg34t2sn@me-pc> <alpine.BSF.2.00.1206172212440.2506@wojtek.tensor.gdynia.pl> <7B54F8CE-9CA5-4C06-B3D8-F365A67A5300@exonetric.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>>> Clang is consistently faster at compiling than GCC and it is very clean and modular -- not bloated.
>>
>> -r-xr-xr-x 3 root wheel 37025016 12 cze 21:46 /usr/bin/clang
>>
>> well..
>
> hope you just left the debugging symbols in and statically linked it?
standard FreeBSD built, assumed freebsd build system do the right things.
test done with SSD disk so I/O time are insignificant.
/usr/bin/clang: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically linked (uses shared libs), for FreeBSD 9.0 (900506), stripped
/usr/bin/clang:
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x802b58000)
libm.so.5 => /lib/libm.so.5 (0x802e68000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x803089000)
libc.so.7 => /lib/libc.so.7 (0x803296000)
[wojtek@wojtek ~]$ ls -l /usr/libexec/cc1*
-r-xr-xr-x 1 root wheel 6265360 12 cze 21:46 /usr/libexec/cc1
-r-xr-xr-x 1 root wheel 6813856 12 cze 21:46 /usr/libexec/cc1plus
[wojtek@wojtek ~]$ file /usr/libexec/cc1*
/usr/libexec/cc1: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900506), stripped
/usr/libexec/cc1plus: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900506), stripped
[wojtek@wojtek ~]$ ls -l /usr/bin/cc
-r-xr-xr-x 2 root wheel 450184 12 cze 21:46 /usr/bin/cc
[wojtek@wojtek ~]$ ls -l /usr/bin/cpp
-r-xr-xr-x 2 root wheel 199304 12 cze 21:46 /usr/bin/cpp
that's about bloat.
now about speed: compiling time of my custom kernel (just kernel, no modules, -j 2)
gcc:
real 2m2.880s
user 3m35.788s
sys 0m23.799s
makeoptions CC="clang" :
real 2m8.511s
user 3m48.025s
sys 0m22.602s
resulting programs (gzip as example,stripped, dynamic link):
-rwxr-xr-x 1 root wheel 36792 18 cze 14:53 gzip.cc
-rwxr-xr-x 1 root wheel 36728 18 cze 14:53 gzip.clang
speed test (compression -9 to /dev/null of 4GB file - windows XP image in
virtualbox):
gzip.clang:
[root@wojtek ~/NOBACKUP]# time ./gzip.clang -9c
/home/wojtek/NOBACKUP/Winda.part1 >/dev/null
real 9m17.495s
user 8m59.466s
sys 0m5.724s
gzip.cc:
[root@wojtek ~/NOBACKUP]# time ./gzip.cc -9c
/home/wojtek/NOBACKUP/Winda.part1 >/dev/null
real 9m26.206s
user 9m2.700s
sys 0m7.551s
clang is slightly slower (nearly comparable) to gcc, produced similar
sized code, that executes in similar speed (<0.5% difference in CPU time),
while clang itself is 5 times bigger.
sometimes spending just a few minutes to CHECK how things are is far
better than following a hype. I would say not just sometimes, but always.
Don't forget that gcc is result of much over 20 years of constant
patching, modifying, adding and changing the same code which MUST result in bloat
and inefficiency.
Clang written recently with "fresh look" resulted in no faster, but far
more bloated program. quite strange IMHO, think what will be within 5
years.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1206181440260.11774>