Re: [boost] [Hana] Announcing Hana's formal review next week (June 10th)

Subject: Re: [boost] [Hana] Announcing Hana's formal review next week (June 10th)
From: Oleg Grunin (ogrunin_at_[hidden])
Date: 2015-06-09 16:30:01

Louis Dionne <ldionne.2 <at> gmail.com> writes:

> > [...]
> 
> Indeed, you are using a Map when what you really want is a Tuple, 
since
> your keys are integers. Here's the version I would have written:
> 
>     #include <boost/hana/integral_constant.hpp>
>     #include <boost/hana/range.hpp>
>     #include <boost/hana/tuple.hpp>
>     using namespace boost::hana;
> 
>     static constexpr int map_size = 100;
> 
>     void run() {
>       constexpr auto hana_range = range(int_<0>, int_<map_size>);
>       auto hana_tuple = unpack(hana_range, [](auto ...n) {
>         return tuple_t<std::array<char, decltype(n)::value>...>;
>       });
> 
>       auto Array = hana_tuple[int_<69>];
> 
>       // instantiate the array
>       constexpr decltype(Array)::type arr = {{0}};
>       static_assert(sizeof(arr) == 69, "");
>     }
> 
> However, I can easily imagine another example where you actually need 
the
> functionality of a Map. See below for performance comments.
> 
Indeed, I used a range just to compress the code. It could have been:
 typedef mpl::joint_view<mpl::range_c<int, 0, 50>, mpl::range_c<int, 51, 
100> > mpl_range, which would likely not work with a tuple. 
Btw, I couldn't find a way to combine several ranges with hana.

> 
> 1. Clang generates horrible code for your example. I think the fault 
is
>    principally on the compiler, since it generates perfect code for up
>    to ~20 elements, and then starts emitting complete crap. I'll 
follow
>    up with the Clang team about this.
> 

 I hope they'll take it up, since it's the only compiler capable of 
compiling this code. 

> 2. The fault is also partially on the library, which does not compress
>    the storage of empty types right now. Hence, your compile-time map,
>    which contains (int_<...>, type<...>) pairs, actually has a huge
>    sizeof, whereas it should have sizeof(char) since all those pairs
>    are empty.
> 
>    Indeed, I was able to make the runtime performance issue go away by
>    compressing the storage of empty types in Hana pairs. I opened an
>    issue [2] to track the progress of this feature. By the way, I
>    consider this a high priority feature.
> 
>  [...]
> As you can see, only your original Map example is bad, and it starts
> sudenly at about 30 elements, which reinforces my thinking that it's
> a compiler bug or quality of implementation issue. As you can see, my
> version using Hana Tuple is indeed 0 overhead, just like the MPL. I am
> confident that compressing empty types and making the Map 
implementation
> more clever should resolve the issue you presented.

 I wish there was a deterministic, language enforced way, to make sure 
that stuff intended to be compile-time stayed as such. Relying on an 
optimizer isn't all that comforting in this case. Although, it maybe 
that the lack of constexpr lambda's makes it impossible.

> 
> > Also it appears that Hana lets the compiler swallow all kinds of 
code
> > that doesn't appear to have any practical meaning:
> >
> > I understand (maybe erroneously) that a hana::map can have a useful
> > application only if its keys are compile-time constructs, and yet I 
was
> > able to compile:
> > make_map(make_pair(1, "one"), make_pair(2, "two"));
> 
> You are correct when you state that Hana Maps require the keys to be
> comparable at compile-time, i.e. the comparison of two keys must 
return
> an IntegralConstant.
> 
> The above usage, which is generally meaningless, is impossible to 
catch
> at compile-time in general, because the type of the object returned by
> the comparison of 1 with something else may depend on that something
> else. In other words, we can only flag the above usage if there exists
> no 'x' (of any type) such that '1 == x' returns an IntegralConstant.
> However there is no way to assess that in general.
> 

I am probably missing something, but can't you check that the first 
element of every pair going into the map is a compile-time constant. 
Isn't (1 == anything) either a bool or a compile-time error, whereas 
int_<1> == anything is always a bool_<> or error?

Thanks for your more than exhaustive reply.