Re: [boost] [fusion] question

From: dan marsden (danmarsden_at_[hidden])
Date: 2006-05-09 17:27:38

Gennadiy Rozental wrote:
>"dan marsden" <danmarsden_at_[hidden]> wrote in message
>news:20060506075932.96933.qmail_at_web25106.mail.ukl.yahoo.com...
>> Gennadiy Rozental wrote:
>>>I may not have time for review, but just one simple question: what are the
>>>advantages/disadvantages/differences in usage with
>>>stl_container<boost::variant>?
>>
>> Disclaimer: I'm not a regular user of boost::variant.
>>
>> I believe the key differences is what information is available / fixed at
>> compile time
>> rather than run time.
>
>Ok. But I would be more interrested in pratiacal approach. So my questions
>would be:
>
>1. Which tasks require fusion::vector and does not accept vector<variant>?

Tasks where compile time access to the types of the sequence elements. Code
that uses expression templates such as spirit, lambda libraries etc. would benefit
from the ability to manipulate unnamed collections of types.

Code where testing the types of the elements at runtime is inappropriate or too
expensive in terms of runtime or footprint size (see below).

>2. Which tasks require vector<variant> and does not accept fusion::vector?

If the number of elements to be inserted into the sequence cannot be decided until
runtime, then the fixed size nature of fusion sequences will not be suitable for your
programming task.

>3. Which tasks I could prefer fusion::vector for? What practical reasons?

Well anything where you require hetrogenous containers and algorithms to 
manipulate them. A few examples of where this would be useful:

*Expression template heavy libraries - such as spirit, phoenix etc.
*Libraries such as bind that may need to bundle up collections of arguments, and manipulate those collections, this is a natural operation for a tuple lib.
*An iterator adaptor such as a zip iterator would benefit from the ability to return
tuples (fusion sequences) of references to the members of the zipped sequences.
*Anywhere you find yourself needing std::pair, but 2 elements really isn't enough,
std::pairs are really just a tuple type with 2 elements. Contrasting with using
containers of variants, you wouldn't expect to use a 2 element container of variants to
insert into a std::map.

>And if this is performance what is a performance advantage 1%, 10%, 50%?

I've attached a simple performance test to compare using fusion versus a container of
variants, to contrast the 2 approaches. Output below:

VC8.0

Short test ... 
80
80
Fusion vector size                                : 12
Variant vector size (includes vector size + data) : 48
Fusion vector time         : 5.11855e-009
Variant time               : 1.11818e-007
Long test ... 
480
480
Fusion vector time         : 1.76728e-008
Variant time               : 5.51224e-007

//////////////////////////////////
VC7.1

Short test ... 
80
80
Fusion vector size                                : 12
Variant vector size (includes vector size + data) : 48
Fusion vector time         : 1.86265e-008
Variant time               : 1.33991e-007
Long test ... 
480
480
Fusion vector time         : 9.67979e-008
Variant time               : 6.55174e-007

//////////////////////////////////
g++3.4

Short test ... 
80
80
Fusion vector size                                : 16
Variant vector size (includes vector size + data) : 44
Fusion vector time         : 5.49555e-08
Variant time               : 4.74453e-08
Long test ... 
480
480
Fusion vector time         : 2.90394e-07
Variant time               : 2.08855e-07

///////////////////////////////////

Icl 9.0:----------------------------------------------
icl -Ox -Qipo -EHsc -IC:\CVS\fusion-2\spirit -IC:\CVS\Boost
fusion_vs_variant.cpp

Short test ...
80
80
Fusion vector size                                : 12
Variant vector size (includes vector size + data) : 48
Fusion vector time         : 1.16378e-008
Variant time               : 4.09484e-008
Long test ...
480
480
Fusion vector time         : 6.52075e-008
Variant time               : 1.52826e-007

As you can see, footprint size is consistently about 4x smaller for Fusion versus
the variant approach. Performance is signicantly faster in all cases, except the gcc
test, where variant actually outperforms. We've not traced why gcc is failing to
optimize the test case as well as the other compilers.

Of course a benchmark and may not reflect the usage patterns in a specific
application...

>4. Could you compare from usdabiltiy standpoing all the operation shared by
>this two approaches?

That is an extremely broad question, did you have any specific concern in mind?

Hope that was helpful
Cheers
Dan