Building cpp-netlib

Hi Everyone,

I've just now tested the latest clang trunk on Ubuntu Linux 10.4 and
pitted it against gcc 4.4.3 and tried building the latest in
cpp-netlib [0] master (represents the stable releasable branch) and
head-to-head clang is able to compile the template-heavy library test
suite in:

real 3m4.589s
user 2m42.898s
sys 0m8.385s

Compared to the GCC 4.4.3's performance of

real 4m51.581s
user 4m42.038s
sys 0m5.796s

That's amost a full two minutes faster!

One observation though is that clang tends to require a lot of memory
-- almost 2:1 as far as virtual memory usage compared to GCC.

I am running this test in the same VirtualBox VM running 32-bit Ubuntu
Linux 10.4 with 1024MB RAM allocated, running on a 32-bit Windows 7
host installed on a Dell Vostro 3700 (Intel Core i7).

cpp-netlib depends heavily on Boost's MPL and Boost Spirit, which
really stresses out the compilers I've been developing with. Now
though I'm happy to say I'll be using clang as the primary compiler
for development now as it catches more standards compliance issues
than the others, as well as compiles things faster.

Keep up the great work guys and I definitely hope this helps!

[0] http://github.com/mikhailberis/cpp-netlib

Hi Everyone,

I've just now tested the latest clang trunk on Ubuntu Linux 10.4 and
pitted it against gcc 4.4.3 and tried building the latest in
cpp-netlib [0] master (represents the stable releasable branch) and
head-to-head clang is able to compile the template-heavy library test
suite in:

real 3m4.589s
user 2m42.898s
sys 0m8.385s

Compared to the GCC 4.4.3's performance of

real 4m51.581s
user 4m42.038s
sys 0m5.796s

That's amost a full two minutes faster!

One observation though is that clang tends to require a lot of memory
-- almost 2:1 as far as virtual memory usage compared to GCC.

I've also seen this with programs that use a lot of template metaprogramming and deep template instantiations (as your mention of Boost.MPL and Boost.Spirit would imply), and we're hoping to dig into it in the near future. I suspect it's the fact that we try to keep around a ton of source-location information when instantiating.

cpp-netlib depends heavily on Boost's MPL and Boost Spirit, which
really stresses out the compilers I've been developing with. Now
though I'm happy to say I'll be using clang as the primary compiler
for development now as it catches more standards compliance issues
than the others, as well as compiles things faster.

Glad to hear it!

  - Doug

One observation though is that clang tends to require a lot of memory
-- almost 2:1 as far as virtual memory usage compared to GCC.

I've also seen this with programs that use a lot of template metaprogramming and deep template instantiations (as your mention of Boost.MPL and Boost.Spirit would imply), and we're hoping to dig into it in the near future. I suspect it's the fact that we try to keep around a ton of source-location information when instantiating.

That's great news, at least I'm not alone in noticing this. :wink:

Would it have something to do with the GCC optimization on using hash
tables for template specialization resolution?

cpp-netlib depends heavily on Boost's MPL and Boost Spirit, which
really stresses out the compilers I've been developing with. Now
though I'm happy to say I'll be using clang as the primary compiler
for development now as it catches more standards compliance issues
than the others, as well as compiles things faster.

Glad to hear it!

Glad to report success! :slight_smile:

No. Clang has implemented that optimization from the beginning. More likely, it's because we keep precise source-location information for nearly every important token inside a template definition, and we make copies of that information each time we instantiate that template. Thus, an explosion in the number of template instantiations causes us to use too much memory. We know that we can share that source-location information, but we're not there yet :slight_smile:

But, this needs far more investigation.

  - Doug

One observation though is that clang tends to require a lot of memory
-- almost 2:1 as far as virtual memory usage compared to GCC.

I've also seen this with programs that use a lot of template metaprogramming and deep template instantiations (as your mention of Boost.MPL and Boost.Spirit would imply), and we're hoping to dig into it in the near future. I suspect it's the fact that we try to keep around a ton of source-location information when instantiating.

That's great news, at least I'm not alone in noticing this. :wink:

Would it have something to do with the GCC optimization on using hash
tables for template specialization resolution?

No. Clang has implemented that optimization from the beginning. More likely, it's because we keep precise source-location information for nearly every important token inside a template definition, and we make copies of that information each time we instantiate that template. Thus, an explosion in the number of template instantiations causes us to use too much memory. We know that we can share that source-location information, but we're not there yet :slight_smile:

Ah yes, copies can explain it. :slight_smile:

But, this needs far more investigation.

At least it's in the radar, which is great news to me. :slight_smile:

Thanks for the insights Doug! :smiley: