Re: [boost] Constrained genericity at last? (any interest inanoperator traits/concept traits library?)

From: Terje Slettebø (tslettebo_at_[hidden])
Date: 2004-09-18 11:08:59

>From: "John Torjo" <john.lists_at_[hidden]>

> > Ok, I haven't timed "typical use"; the only tests I've done in this
respect
> > is running the unit tests, but much of the time involved in that may
well be
> > taken by the test framework, as it uses mpl::for_each to iterate in two
> > dimensions, taking a list of traits, and a list of types to test for
each
> > trait, which generates thousands of tests.
> >
> > The unit tests take a rather long time to compile on Intel C++
(typically
> > several minutes), but shorter on on MSVC, or g++.
>
> that's a bit of a turn-off for me.
> I'm getting more and more annoyied by the fact that every time something
> *really cool* is discovered, it hits the compiler-time barrier.
>
> As I've said in posts to c.l.c++.m, maybe it's time for a new language...

Or compilers optimised for heavy template use. :)

There might be ways of optimising compilation time, but it may be very
compiler-specific
(http://users.rcn.com/abrahams/instantiation_speed/index.html).

I've done some benchmarks, using the unit tests. The results are given
below.

System specification
-----------------------------
Pentium II 350 MHz
384 MB 100 MHz RAM

operator_traits_test.cpp
---------------------------------

Intel C++ 7.1 - No debug info, optimisations off
----------------------------------------------------------------
21 traits, 925 tests - 5 min
46 traits, 1981 tests - 21 min

MSVC 7.1 - No debug info, optimisations off
-------------------------------------------------------------
21 traits, 925 tests - 2 min
46 traits, 1981 tests - N/A - fatal error C1204: compiler limit : internal
structure overflow

g++ 3.2 - No debug info, optimisations off
---------------------------------------------------------
21 traits, 925 tests - 7 min
46 traits, 1981 tests - > 30 min (*)

(*) This used a lot of memory, > 330 MB, apparently leading to virtual
memory trashing, and dramatic drop in processor utilisation, so in the end I
stopped the compilation.

Note that, as mentioned above, much of the overhead may be due to the test
setup - it builds a long instantiation stack with mpl::for_each in two
dimensions, and as you can see, on Intel C++ (EDG), the time taken doesn't
grow linearly with the number of tests, but rather quadratic, or something
like it.

The traits are rather simple in structure - there's no recursion in the
library itself, although it might be in the mpl::and_<>, mpl::or_<> and
mpl::not_<> components that are used, and/or use of the PP-lib.

Before doing any optimisation, I think one should first determine if there
_is_ a problem, by benchmarking a real-life program with and without concept
checking.

Regards,

Terje