Re: [boost] Hana Views and References

On 6/26/15 10:57 PM, Lorenzo Caminiti wrote:

On Thu, Jun 25, 2015 at 5:41 PM, Joel de Guzman wrote:

...

On 6/26/15 5:24 AM, Louis Dionne wrote:

...

...

Faster runtime performance is also questionable, when lightweight views and reference members come into play.

Hana claims to be at least as good as Fusion runtime-wise, which is backed by the benchmarks presented in the tutorial. It is possible that idiomatic usage of Hana leads to worse runtime performance than with Fusion, in which case the library and its idioms will have to be adjusted. Like I said a few times, Hana is a new library with a new paradigm, and I think we're only starting to discover how it can be used (and used efficiently).

Your tests focused on a mere subset of Fusion which is the least optimized: fusion::vector. Your tests do not cover other areas such as views, and other containers. I can imagine a case, when say you push_back or insert where views should shine. It's the difference between copy by value and pass by reference. Try doing that with large tuple elements (those without resources and are not efficiently moved). Actually, have you tried reverse with large tuples like bitmaps and stuff?

</snip>

Hi Joel and Louis,

How about a similar analysis but for the Hana vs. Fusion compile-times? In my experience compile-times are much (much!) more of a problem than run-times with TMP in production code (because I can always do something "smart" to optimize run-times, while such optimizations are much more difficult, and much more compile-dependent for compile-times).

I'd be nice to confirm/check Hana's compile-time improvements over Fusion shown by the Tutorial graphs, and also to be able to guess if we'll see similar numbers on MSVC, not just Clang (Louis already commented that should be the case...).

Thanks. --Lorenzo

P.S. As I said in my review, I think Hana has its place in Boost regardless of the promised performance improvements (because of its easier/new TMP, great SFINAE facilities, etc.). But the the improved compile-times will essentially "force" me to use Hana if it becomes available on MSVC, so that's a lot of extra motivation.

Hi Lorenzo, Two things. 1) Hana's tests focuses on the least optimized aspect of Fusion: vector. I won't be surprised tough if Hana is still faster with the other containers at the moment. because 2) It is undergoing a C++11, C++14 transformation right now, which should level the playing field somewhat, except probably for the abstraction penalties of the underlying Iterator interface. There's some talk about getting rid of the fancy Iterator concepts of Fusion in favor of a simpler (CT friendly) interface. maybe for Fusion V3. It might also be possible to have a Fusion-lite, with 95+% of the functionality but with a very lightweight interface. For runtime, there are things that a library's design limitation imposes that you can't do anything about. So you can't simply say: "I can always do something "smart" to optimize run-times". The example I presented are views. If you use views (properly!) you can have zero copies/moves. If you have seen Eric's presentation on the ranges V3 library, that is a compelling example using lazy views. For example, imagine a complex algorithm chain f1 | f2 | f3 | f4. If all these algos compute eagerly, you will have four(!) temporary results. With views, you have zero. Most of Fusion algorithms return views. Hana's algorithms on the other hand are always eagerly evaluated. Regards, -- Joel de Guzman http://www.ciere.com http://boost-spirit.com http://www.cycfi.com/