Re: [boost] [proto] Looong compile times and other issues

Subject: Re: [boost] [proto] Looong compile times and other issues
From: Joel de Guzman (joel_at_[hidden])
Date: 2011-09-12 06:50:08

On 9/12/2011 4:06 PM, Thomas Heller wrote:
> On Monday, September 12, 2011 02:57:21 PM Joel de Guzman wrote:
>>
>> The one you show above is also a very simple tweak. I welcome any CT
>> improvements we can do as long as the code is kept in a reasonably
>> comprehensible state. I applaud what you and Heller are doing.
> 
> I am trying to come up with a patch today. The changes Joel Falcou suggests 
> are really easy to do. And already promise to show significant CT 
> improvements.

Awesome! Looking forward to it.

>> Let me make it clear though that it is an unfair characterization
>> to say that Fusion is the cause of CT slowdown for Proto.
>> First, as Eric says, Proto avoids Fusion and Second, there's a
>> clear indication that a library without Proto is still faster,
>> regardless of the intense CT perf tweaks done thus far.
>>
>> For example, here is the current CT status of Phoenix2 vs
>> Phoenix3 comparing the elapsed (CT) time for the phoenix2 vs.
>> phoenix3 lambda_tests.cpp (**):
>>
>> MSVC 10:
>>   Phoenix2: 00:04.5
>>   Phoenix3: 00:29.9
>>
>> G++ 4.5:
>>   Phoenix2: 00:02.6
>>   Phoenix3: 00:04.7
> 
> I wasn't aware that Phoenix3 was so bad under MSVC 10.

Yes. A solution for compiler X does not necessarily work for
compiler Y.

>> You all know that Phoenix2 uses Fusion exclusively. Phoenix3
>> uses proto, which according to Eric does not use Fusion,
>> although IIRC the core of Phoenix3 uses some Fusion still
>> (quick check: Thomas uses an optimized-PP version of fusion::
>> vector for phoenix3).
>>
>> Heller did a helluva perf-tweaks for Phx3 to get that number
>> for g++ (alas, not MSVC). In fairness, I did absolutely no
>> CT perf-tweaks for both Phoenix2 and Fusion.
>>
>> (** I made sure both tests have exactly the same code, so I
>> removed the last test. I can post the exact code if need be)
> 
> FWIW, there are some unit tests that outperform the compile times of Phoenix2 
> (with gcc), the current bad hit on compile times seem to only occur with let, 
> lambda and switch/case expressions.

Fair enough, but:

1) You are comparing (CT) optimized code (Phx3) with unoptimized
   code (Phx2). Apply the same optimizations for Phx2 then it
   will again leave Phx3 in the dust.

2) It is these more complex expressions that's purportedly where Proto
   should shine. Otherwise, an easy hand-written ET such as that of
   Phx2, with less CT overhead, would suffice.

Regards,
-- 
Joel de Guzman
http://www.boostpro.com
http://boost-spirit.com