Re: [proto] The proper way to compose function returning expressions
On 4/25/2012 1:41 PM, Mathias Gaunard wrote: On 24/04/12 22:31, Eric Niebler wrote: On 4/23/2012 10:17 PM, Joel Falcou wrote: On 04/24/2012 12:15 AM, Eric Niebler wrote: I think this is an important issues to solve as far as Proto grokability does. Agreed. It would be very nice to have. But you still have to know when to use it. One of my coworker on NT2 tried to do just this (the norm2 thingy) and he get puzzled by the random crash. [...] The implicit_expr code lived in a detail namespace in past versions of proto. You can find it if you dig through subversion history. I'm not going to do that work for you because the code was broken in subtle ways having to do with the consistency of terminal handling. Repeated attempts to close the holes just opened new ones. It really should be left for dead. I'd rather see what you come up with on your own. The issue Joel had in NT2 was probably unrelated to this. In NT2 we hold all expressions by value unless the tag is boost::proto::tag::terminal. This was done by modifying as_child in our domain. I strongly recommend doing this for most proto-based DSLs. It makes auto foo = some_proto_expression work as expected, and allows expression rewriting of the style that was shown in the thread without any problem. There is probably a slight compile-time cost associated to it, though. Interesting. I avoided this design because I was uncertain whether the compiler would be able to optimize out all the copies of the intermediate nodes. You're saying NT2 does it this way and doesn't suffer performance problems? And you've hand-checked the generated code and found it to be optimal? That would certainly change things. -- Eric Niebler BoostPro Computing http://www.boostpro.com ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] The proper way to compose function returning expressions
On 26/04/12 18:02, Eric Niebler wrote: Interesting. I avoided this design because I was uncertain whether the compiler would be able to optimize out all the copies of the intermediate nodes. You're saying NT2 does it this way and doesn't suffer performance problems? And you've hand-checked the generated code and found it to be optimal? That would certainly change things. NT2 treats large amounts of data per expression, so construction time is not very important. It's the time to evaluate the tree in a given position that matters (which only really depends on proto::value and proto::child_cN, which are always inlined now). We also have another domain that does register-level computation, where construction overhead could be a problem. The last tests we did with this was a while ago and was with the default Proto behaviour. That particular domain didn't get sufficient testing to give real conclusions about the Proto overhead. ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] The proper way to compose function returning expressions
On 4/26/2012 9:35 AM, Mathias Gaunard wrote: On 26/04/12 18:02, Eric Niebler wrote: Interesting. I avoided this design because I was uncertain whether the compiler would be able to optimize out all the copies of the intermediate nodes. You're saying NT2 does it this way and doesn't suffer performance problems? And you've hand-checked the generated code and found it to be optimal? That would certainly change things. NT2 treats large amounts of data per expression, so construction time is not very important. It's the time to evaluate the tree in a given position that matters (which only really depends on proto::value and proto::child_cN, which are always inlined now). We also have another domain that does register-level computation, where construction overhead could be a problem. The last tests we did with this was a while ago and was with the default Proto behaviour. That particular domain didn't get sufficient testing to give real conclusions about the Proto overhead. In that case, I will hold off making any core changes to Proto until I have some evidence that it won't cause performance regressions. Thanks, -- Eric Niebler BoostPro Computing http://www.boostpro.com ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
