[cfe-dev] some notes about templates

[Larry Evans]

On 06/29/13 13:59, Nick Lewycky wrote:
> On 29 June 2013 11:00, Larry Evans
> <cppljevans at suddenlink.net
> <mailto:cppljevans at suddenlink.net>> wrote:
> 
>     On 06/28/13 19:07, Nick Lewycky wrote:
>     [snip]
>     > ActiveTemplateInstantiations shouldn't be a SmallVector in Sema, they
>     > should be allocated by a BumpPtrAllocator in ASTContext. Then we
>     can put
>     > ActiveTemplateInstantions in the AST, which will requiring
>     changing it a
>     > bit (no pointers to sema:: objects), but we also want to add a
>     template
>     > depth, correct point-of-instantiation SourceLocation and add missing
>     > instantiation records (such as instantiation due to overload
>     > resolution). An awesome outcome of this will be that we'll be able to
>     > produce template stack traces even when we aren't actively doing
>     > template instantiation. That would in turn allow us to do other things
>     > like flatten instantiation instead of making it recursive.
>     >
>     Would this flattening speed compile times?  Long compile times
>     is one strong reason why boost preprocessor is used to implement tuples:
> 
>     http://article.gmane.org/gmane.comp.lib.boost.devel/235386
> 
> 
> Not really, maybe only a tiny bit. What it means is that the depth of
> templates we can instantiate wouldn't be limited by our stack space, but
> by heap space.
> 
> I would be very surprised if clang has bad compile-time performance
> building tuples. Without thinking about it too hard, this sounds like
> something we should already be good at.
> 
> Nick
clang3.3 does much better than gcc4.8, at least according to the
attached timings.

The test driver is also attached.

The .hpp file was python generated during each run to generate
the tuple_t.  It had the form:

  typedef lib_container::vector
  < int_value< 0 >
  , int_value< 1 >
  , int_value< 2 >
.
.
.
  , int_value< 498 >
  , int_value< 499 >
  >
tuple_t;

The slim library was cloned from:

http://ch.ristopher.com/r/slim

sometime around June 2012.

HTH.

-regards,
Larry

last run it

-------------- next part --------------
10 2.36user 24inputs+168outputs (0text+0data 338752max)k (1major+33402minor)pagefaults 0swaps
50 2.81user 0inputs+1288outputs (0text+0data 355568max)k (0major+36701minor)pagefaults 0swaps
100 3.53user 0inputs+3872outputs (0text+0data 437632max)k (0major+42021minor)pagefaults 0swaps
200 5.95user 0inputs+13560outputs (0text+0data 661296max)k (0major+56467minor)pagefaults 0swaps
300 9.66user 0inputs+29112outputs (0text+0data 982592max)k (0major+76816minor)pagefaults 0swaps
400 14.66user 0inputs+50336outputs (0text+0data 1401728max)k (0major+103686minor)pagefaults 0swaps
500 20.75user 0inputs+77432outputs (0text+0data 1880384max)k (0major+133892minor)pagefaults 0swaps
-------------- next part --------------
10 2.24user 28032inputs+1944outputs (0text+0data 553488max)k (135major+37936minor)pagefaults 0swaps
50 3.26user 0inputs+15304outputs (0text+0data 699024max)k (0major+51567minor)pagefaults 0swaps
100 5.99user 0inputs+48376outputs (0text+0data 942848max)k (0major+71840minor)pagefaults 0swaps
200 18.01user 0inputs+176432outputs (0text+0data 1441296max)k (0major+122792minor)pagefaults 0swaps
300 47.67user 32inputs+385080outputs (0text+0data 2093952max)k (0major+191204minor)pagefaults 0swaps
400 97.58user 157272inputs+671640outputs (0text+0data 3350656max)k (12major+311332minor)pagefaults 0swaps
500 184.40user 470520inputs+1039144outputs (0text+0data 4175888max)k (20major+449712minor)pagefaults 0swaps
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tuple.benchmark.simple.cpp
Type: text/x-c++src
Size: 1439 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130702/18c253b4/attachment.cpp>