Re: Fusion-ifying proto parse trees

Frank Birbacher wrote:
> Hi!
>
> David Abrahams schrieb:
>
> > Among other things, this approach makes the most of the compiler's
> > inherent inlining depth limitations.
>
>
> As I understand it, the collapse of associative operators (as in Joel's
> example, the operator +) would allow for a parse function which calls
> into say 10 subparsers:
>
> //something like:
> void parse(T t) //support up to N subparsers
> {
>         parse(t.get<0>());
>         parse(t.get<1>());
>         ...
>         parse(t.get<N>());
> }
>
> Here we relax the compiler. It can do inlining much better than in the
> recursive version. Any of the unused subparsers are optimized away
> easily, I think.
>
> Am I totally wrong here, Joel? Eric?


You're not wrong, that's true. At least, it's true if the parsers are 
stored in a Fusion RandomAccessSequence (which they won't be, because 
they'll be stored in a cons<> list, but that's another matter). But what 
Dave is saying is that the loop unrolling should be happening at a lower 
level, and for the *all* Fusion sequences. It should be baked into 
Fusion, so that nobody should have to hard-code their own unrolled loops 
as you're doing above. They'll just call the appropriate Fusion algorithm.

--
Eric Niebler
Boost Consulting
www.boost-consulting.com


-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642