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

From: Andy Little (andy_at_[hidden])
Date: 2006-09-25 19:26:53

"Joel de Guzman" <joel_at_[hidden]> wrote in message
news:ef9mui$nhb$1_at_sea.gmane.org...
> 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.

FWIW the whole story is available in Quan CVS In the same directory with the
following files, (though much of it is tedious to wade through)

Here is v5:

http://tinyurl.com/g3xlf

In that I basically follow at runtime what I did at compile time with Fusion.
>From memory it Blew VC7.1 to 'compiler out of resources" in debug mode.

In V6 I figured I'd try a different apprioach:

http://tinyurl.com/l5q6t

Here I use my own homerolled recursion at runtime and compiled much faster and
completed and ran.

Final version is not much different, but did some experiments on the evaluation
order in homerolled version, which makes a huge difference toi the output.

http://tinyurl.com/gkbbt

But yeah. Don't take it too seriously. To analyse it properly would take a long
time and I was having too much "fun with Fusion" at that time. :-)

regards
Andy Little

 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
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>