Re: [boost] Hana Views and References

Subject: Re: [boost] Hana Views and References
From: Joel de Guzman (djowel_at_[hidden])
Date: 2015-06-26 19:39:52

On 6/26/15 10:57 PM, Lorenzo Caminiti wrote:
> On Thu, Jun 25, 2015 at 5:41 PM, Joel de Guzman <djowel_at_[hidden]> 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/