Boost logo

Boost Users :

Subject: Re: [Boost-users] Max Boost Fusion tuple parameters
From: Larry Evans (cppljevans_at_[hidden])
Date: 2013-06-14 14:38:12


On 06/14/13 09:08, Larry Evans wrote:
> On 06/14/13 04:39, Slava wrote:
>> On Thu, 13 Jun 2013 14:27:30 +0200, Larry Evans
>> <cppljevans_at_[hidden]> wrote:
>>
>>> It also appears that when TUPLE_SIZE >=100,
>>> compile time goes up linearly.
>
> I think that linear remark was wrong. It goes up
> by a factor of about 2 between 100 and 200 and
> then by another factor of 2 between 200 and 300.
> That's exponential IIRC :( Of course I could be
> misunderstanding again. It happens :(
>
>>
>>
>> Take a look at memory usage either, as soon as it starts swapping, it's
>> far from linear. Your peers will curse you for this code. CDT indexer

Yes. Looking at the performance monitor as it was compiling
TUPLE_SiZE=500 showed almost all the memory was used and, IIRC,
about 40% of swap.

>> (eclipse) takes a lot time and memory on such constructs.
>> The size of the produced binary (due to debug info for all these small
>> inlined internal helper functions) must not be forgotten. It's hard to
>> justify half-Gb executable to the colleagues.
>>
>> -- Slava
[snip]

Using the slim::accumulate template instead of using
python to generate the summation code doesn't make
much difference:

tuple_size compile_time
  10 2.01
  50 3.37
 100 6.26
 200 18.51
 300 43.79
 400 109.28
 500 195.42

Attached is the driver.

I did try to eyeball a fit with qtiplot which showed:

  compile_time = 12*2^(max(0,tuple_size-100)/100)

looked quite similar at tuple_size>=100.

--Larry




Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net