Re: [boost] [fusion] segmented sequences [ was Re: [fusion] ftag ]

From: Joel de Guzman (joel_at_[hidden])
Date: 2006-09-25 18:58:51

Andy Little wrote:

> OK.  FWIW I found that  creating a sequence by  pushing_back result_types to an
> empty vector is a great way to 'create' a result sequence at compile time.  It
> kind of creates something out of nothing.  At runtime however I found I could
> employ a different approach by using recursive functors(that is still compile
> time rather than runtime recursion, but much faster to compile and using less
> resources, whereas joint_view can be a resource hog)

A resource hog? At compile time? At runtime? I'd like to know how
you arrived at that observation. You can use result_of::push_back to
build your sequence at compile time and that (AFAICT) is quite cheap.

, because now the type of
> the result sequence is known. Basically the compile time and runtime stages are
> doing different jobs. The compile time fold push_back is working out what the
> final sequence will be. Now the runtime's job is to figure out the most
> efficient way to initialise the sequence, that it already knows about. I havent
> yet figured how to create an initialiser so that the compiler will initialise
> the sequence right in the constructor(not that its impossible, just havent got
> round to trying), but I guess that would be ideal. The compiler is seeming to
> optimise away the default ctor, followed by the fill anyway, but it would be
> satisfying if I could express that intent more directly. I guess this might
> involve making a view, where each element contains an individual view of the
> function for initialising that element.

If it helps, you can also use mpl to build your type. Fusion can take in
MPL sequences. Example:

     as_vector(an_mpl_sequence)
> 
> Anyway it might be worth thinking about not copying too slavishly the compile
> time behaviour at runtime, as maybe these are very different situations.

You mean: fusion should not copy the compile time behavior at runtime?
Hmmm... but of course it does not. Let me get this straight: push_back
*IS* cheap. It is the unfolding (iterating over) the push-backed view
that is less than ideal. This can be made efficient by segmented
techniques.

> Second my analysis of copying is based on not too much science. IN VC8 the
> assembler code gets pretty big and later functions tend to join the output of
> earlier functions and with 20 Mb assembler files I tended to have ideas half way
> through reading it and never get to the end of the story to see what the
> compiler finally did! If that makes any sense. However it may well be that the
> compiler does keep track of the stuff its copying. It just gets a bit
> frightening seeing  rep movsd instructions on bigger and bigger joint_views
> (where these might have typically 16 elemnts each with 2 referneces), with
> bigger and bigger arguments, but OTOH I suspect once it has to copy then the
> game is up.
> 
> The other question is whether Fusion scales. My guess is that the compile time
> should flatten out once the compiler starts seeing the same types, but OTOH this
> business of accumulating the result type may be 'interesting', but it requires
> writing some applications to find out, so that is what I'm currently about.

Ok.

Regards,
-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net