Re: [proto] Grouping expressions
On Mon, Jan 2, 2012 at 8:57 AM, Joel Falcou wrote: > Compiles in C++11 mode : --std=c++0x Just tried this on boost 1.48, no change in time or memory usage. Or is this even newer than 1.48? > type erasure allow your template class to inherit from a single, > non-template base class that forward its evaluation to its actual > derived class via a single virtual member function entry-point. > > At some point, you need to do this or your CT just explode. And for your > performance matter, I think it need to be benched, type erased calls usually > are no more than some cycles slower to call. Yes, in a way we are already doing this, only the virtual call is a "loop" function that executes the inner loop, so beaking things up further would be possible, but this would incur redundant loops over the mesh. Moving the virtual call down further, i.e. inside the inner loop, would not only be costly because of the virtual call, but also because we would need to use dynamic-size matrices in that case. Right now, all matrix operations use fixed-size matrices (from the Eigen library) and I would guess that losing those would be a bigger hit than the virtual call alone. That said, you did give me a new idea: having a low-level type-erased expression would allow the addition of dynamic "hooks" on our algorithms, where we can add extra equations more dynamically. I'll have to think of a way to do this in practice, at first sight passing the data (as in the proto "data" argument) might pose problems, since this is strongly typed. Many thanks for the answers, as always it's been very helpful! Cheers, -- Bart ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Grouping expressions
On 30/12/2011 17:34, Bart Janssens wrote: On Fri, Dec 30, 2011 at 7:01 AM, Eric Niebler wrote: Are you certain your problem is caused by using operator() for grouping? I think this is just a very big expression template, and any syntax you choose for grouping will result in long compile times and heavy memory usage. Yes, that's what I mean, the way grouping works now always creates a huge expression. You cant really do anything else. ET captures the whole AST and this AST has to be stored somehow. Can I ask, what version of Boost are you using? I see you #define BOOST_PROTO_MAX_ARITY to 10 at the top. In recent versions of Proto, 10 is the default. And newer Proto versions already make use of variadic templates for operator() if available. I'm using 1.46.1 for now. Good to hear variadic templates are already available for this, do I need to do anything explicit to enable them, such as add a compile option? Compiles in C++11 mode : --std=c++0x Other things to think about: does this really need to be all one big expression, or can parts of it be broken up and type-erased, as with spirit::qi::rule? Not sure how this type-erased method works, but all of the expressions are ran in a tight loop, so I'd like to avoid the overhead of having to go through a virtual call. Also, I use some introspection across the whole expression to determine which variables exist. type erasure allow your template class to inherit from a single, non-template base class that forward its evaluation to its actual derived class via a single virtual member function entry-point. At some point, you need to do this or your CT just explode. And for your performance matter, I think it need to be benched, type erased calls usually are no more than some cycles slower to call. On the front of introspection, we found out in NT2 that performing some introspecting tasks in the expression generator (when it made sense) helped keep the CT madness low as the resulting AST can be trimmed as soon as it is built. Not sure if it applies here. ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Grouping expressions
On Fri, Dec 30, 2011 at 7:01 AM, Eric Niebler wrote: > Are you certain your problem is caused by using operator() for grouping? > I think this is just a very big expression template, and any syntax you > choose for grouping will result in long compile times and heavy memory > usage. Yes, that's what I mean, the way grouping works now always creates a huge expression. > Can I ask, what version of Boost are you using? I see you #define > BOOST_PROTO_MAX_ARITY to 10 at the top. In recent versions of Proto, 10 > is the default. And newer Proto versions already make use of variadic > templates for operator() if available. I'm using 1.46.1 for now. Good to hear variadic templates are already available for this, do I need to do anything explicit to enable them, such as add a compile option? > Other things to think about: does this really need to be all one big > expression, or can parts of it be broken up and type-erased, as with > spirit::qi::rule? Not sure how this type-erased method works, but all of the expressions are ran in a tight loop, so I'd like to avoid the overhead of having to go through a virtual call. Also, I use some introspection across the whole expression to determine which variables exist. Cheers, -- Bart ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Grouping expressions
On 12/29/2011 10:07 AM, Bart Janssens wrote: > Hi guys, > > Currently, we are using the proto operator() overload and grammars to > "group" expressions together. The result is one big expression that > consists of several sub-expressions. An example can be found here: > https://github.com/coolfluid/coolfluid3/blob/master/plugins/UFEM/src/UFEM/NavierStokes.cpp#L93 > > The problem with this approach is that for example the file above > takes over 2GB of RAM to compile. I think this is due to the size of > the expression (the group(...) call starting on line 93 is a single > expression). > > I was wondering if it would be useful to find some other way to treat > a group of expressions, maybe by using a fusion vector of expressions, > or even using the new variadic templates of C++11? Could this have a > significant impact in reducing the compiler memory usage? An extra > complication is that the groups may be nested. In the example, there > is a second sort of group inside the element_quadrature call. Are you certain your problem is caused by using operator() for grouping? I think this is just a very big expression template, and any syntax you choose for grouping will result in long compile times and heavy memory usage. Can I ask, what version of Boost are you using? I see you #define BOOST_PROTO_MAX_ARITY to 10 at the top. In recent versions of Proto, 10 is the default. And newer Proto versions already make use of variadic templates for operator() if available. Other things to think about: does this really need to be all one big expression, or can parts of it be broken up and type-erased, as with spirit::qi::rule? -- Eric Niebler BoostPro Computing http://www.boostpro.com ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
