<div dir="ltr">On Thu, Nov 7, 2013 at 2:53 PM, Igor Vagulin <span dir="ltr"><<a href="mailto:igor.vagulin@gmail.com" target="_blank">igor.vagulin@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Richard,<br>
<br>
I've spend few days tweaking all possible flags on clang to make it<br>
work close to gcc. At best found combination clang was only about 30%<br>
worse than gcc(4.4 from rhel-6). Maybe you can give me another hint? I<br>
really want to switch :).<br>
<br>
I've create 100 copies of RemoveClusterObserver.cpp, below is test<br>
results of "time g++|clang++ -c RemoveClusterObserver-*cpp"<br>
g++: 0m58.510s<br>
clang++ default opts: 2m4.065s<br>
+ march=core2: 1m43.729s<br>
+ BUILD_SHARED_LIBS=NO: 1m27.216s<br>
+ by-clang-build-by-clang++: 1m18.816s<br>
<br>
I've also trying measure compile time of clang sources, I thought this<br>
case should be comfortable for clang. No luck, clang still worse in<br>
every scenario. BTW here I also measured intel c compiler.<br>
- gcc-4.4:<br>
real    7m7.759s<br>
user    45m53.622s<br>
sys    2m3.657s<br>
- icc 2013-sp1:<br>
real    8m4.175s<br>
user    54m39.116s<br>
sys    2m35.159s<br>
- clang compiled by gcc:<br>
real    8m42.278s<br>
user    60m19.175s<br>
sys    0m51.341s<br>
- clang compiled by icc (who is paying for this compiler? :-/):<br>
real    8m2.399s<br>
user    57m31.185s<br>
sys    0m57.272s<br></blockquote><div><br></div><div>Thanks for putting together these numbers! I would guess clang-compiled-by-clang would clock in at a little under 8 minutes.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Then I thought maybe problem is x86 architecture and lack of register<br>
and switched to x86_64. Looks like that's the case, and people<br>
claiming "clang compiles faster than gcc" mean "on x86_64".<br>
- gcc:<br>
real    8m8.230s<br>
user    50m1.458s<br>
sys    3m44.313s<br>
- clang compiled by gcc:<br>
real    7m57.747s<br>
user    55m16.080s<br>
sys    1m27.786s<br>
- clang compiled by clang:<br>
real    6m41.412s<br>
user    44m53.298s<br>
sys    1m27.715s<br>
<span class="HOEnZb"><font color="#888888">Igor Vagulin<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
On Fri, Nov 1, 2013 at 3:49 AM, Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>> wrote:<br>
> Looks like your clang is built with shared libraries enabled. That will be<br>
> hurting your performance somewhat, but I don't know how much. Try without<br>
> -DBUILD_SHARED_LIBS=YES.<br>
><br>
> Other than that, the only abnormally high cpu usage is within<br>
> Sema::BuildBinOp, which will probably be due to the large number of<br>
> overloads of operator<< etc that I observed earlier.<br></div></div></blockquote><div><br></div><div>I still think it'd be worth us working on the performance here; there's some obvious redundancy.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
> On Thu, Oct 31, 2013 at 4:24 PM, Igor Vagulin <<a href="mailto:igor.vagulin@gmail.com">igor.vagulin@gmail.com</a>><br>
> wrote:<br>
>><br>
>> I've created sysprof profile of compilation (attached, better open<br>
>> with sysprof it show nice tree). Doesn't look like there are any<br>
>> obvious bottleneck to me. Time in<br>
>> clang::Parser::ParseExternalDeclaration distributed pretty equaly<br>
>> between parts. Maybe I miss something?<br>
>><br>
>> Igor Vagulin<br>
>><br>
>><br>
>> On Thu, Oct 31, 2013 at 11:20 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>><br>
>> wrote:<br>
>> > We may also be able to pick out an 'obvious winner' (perhaps looking for<br>
>> > one<br>
>> > that only requires standard conversions) before trying to build<br>
>> > conversion<br>
>> > sequences for all candidates.<br>
>> ><br>
>> ><br>
>> > On Thu, Oct 31, 2013 at 12:19 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>><br>
>> > wrote:<br>
>> >><br>
>> >> I suspect the problem is overload resolution for the several hundred<br>
>> >> overloads of each of 'operator<<', 'operator<<=', 'operator>>', and<br>
>> >> 'operator>>=' that are present here. Many of these have the same LHS<br>
>> >> parameter type; we could probably improve performance here by caching<br>
>> >> the<br>
>> >> computation of an implicit conversion sequence for a given (argument,<br>
>> >> parameter type) pair.<br>
>> >><br>
>> >><br>
>> >> On Thu, Oct 31, 2013 at 10:05 AM, David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>><br>
>> >> wrote:<br>
>> >>><br>
>> >>><br>
>> >>><br>
>> >>><br>
>> >>> On Wed, Oct 30, 2013 at 11:59 PM, Igor Vagulin<br>
>> >>> <<a href="mailto:igor.vagulin@gmail.com">igor.vagulin@gmail.com</a>><br>
>> >>> wrote:<br>
>> >>>><br>
>> >>>> Hi All,<br>
>> >>>><br>
>> >>>> We are evaluating switch to clang from gcc for our c++ application.<br>
>> >>>> Main focus is compilation speed, but we also look at address/memory<br>
>> >>>> sanitizer, c++11 support and c++ modules. I've tried to compile our<br>
>> >>>> project with clang++ but resulting compilation time is more than with<br>
>> >>>> gcc. Can someone give me a hint where might be a problem?<br>
>> >>>><br>
>> >>>> Our project is bunch of ace-tao corba servants. Overall time with<br>
>> >>>> clang++ is about twice more than with gcc. To reproduce problem I<br>
>> >>>> preprocesssed one file and then compile it, result same - twice<br>
>> >>>> longer<br>
>> >>>> compilation. Don't know where to look further.<br>
>> >>><br>
>> >>><br>
>> >>> If you're lucky, someone might look for you if you attach (or link to,<br>
>> >>> if<br>
>> >>> it's too big to attach) an example of the problem.<br>
>> >>><br>
>> >>> Otherwise, you might want to get started with a profiler and see where<br>
>> >>> the hot parts of Clang/LLVM are in your example.<br>
>> >>><br>
>> >>> (also, consider trying with Clang top of tree (straight from svn/git)<br>
>> >>> -<br>
>> >>> the project moves fairly quickly)<br>
>> >>><br>
>> >>>><br>
>> >>>> [root@ivagulin-pc ~]# time clang++ -c RemoveClusterObserverClang.cpp<br>
>> >>>> real    0m1.283s<br>
>> >>>> user    0m1.254s<br>
>> >>>> sys    0m0.024s<br>
>> >>>> [root@ivagulin-pc ~]# time g++ -c RemoveClusterObserverGcc.cpp<br>
>> >>>> real    0m0.576s<br>
>> >>>> user    0m0.524s<br>
>> >>>> sys    0m0.048s<br>
>> >>>><br>
>> >>>> I use llvm-3.3 and cfe-3.3 compiled with folowing options. Sources of<br>
>> >>>> RemoveClusterObserver*cpp attached.<br>
>> >>>> + cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Release<br>
>> >>>> '-DCMAKE_CXX_FLAGS_RELEASE=-O3 -g -mtune=amdfam10 -march=i686'<br>
>> >>>> '-DCMAKE_C_FLAGS_RELEASE=-O3 -g -mtune=amdfam10 -march=i686'<br>
>> >>>> -DCMAKE_EXE_LINKER_FLAGS_RELEASE=-Wl,--as-needed -Wl,--strip-all'<br>
>> >>>> '-DCMAKE_MODULE_LINKER_FLAGS_RELEASE=-Wl,--as-needed -Wl,--strip-all'<br>
>> >>>> '-DCMAKE_SHARED_LINKER_FLAGS_RELEASE=-Wl,--as-needed -Wl,--strip-all<br>
>> >>>> -shared' -DCMAKE_SKIP_RPATH=YES -DBUILD_SHARED_LIBS=YES<br>
>> >>>> -DLLVM_ENABLE_TIMESTAMPS=NO ..<br>
>> >>>><br>
>> >>>> Igor Vagulin<br>
>> >>>><br>
>> >>>> _______________________________________________<br>
>> >>>> cfe-dev mailing list<br>
>> >>>> <a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
>> >>>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
>> >>>><br>
>> >>><br>
>> >>><br>
>> >>> _______________________________________________<br>
>> >>> cfe-dev mailing list<br>
>> >>> <a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
>> >>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
>> >>><br>
>> >><br>
>> ><br>
><br>
><br>
</div></div></blockquote></div><br></div></div>