Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 31 15:06

    ldionne on gh-pages

    Update benchmarks to 490dbf6 fo… (compare)

  • Jan 24 07:47

    ldionne on gh-pages

    Update benchmarks to 490dbf6 fo… (compare)

  • Jan 23 02:04
    pthom commented #432
  • Jan 18 12:46

    ldionne on gh-pages

    Update benchmarks to 490dbf6 fo… (compare)

  • Jan 16 22:27
    ricejasonf commented #434
  • Jan 05 06:22
    ricejasonf commented #330
  • Jan 03 11:40

    ldionne on gh-pages

    Update benchmarks to 490dbf6 fo… (compare)

  • Jan 02 00:33
    ricejasonf closed #434
  • Jan 02 00:33
    ricejasonf commented #434
  • Jan 02 00:04
    ricejasonf opened #434
  • Dec 27 2018 13:11

    ldionne on gh-pages

    Update benchmarks to 490dbf6 fo… (compare)

  • Dec 22 2018 11:56
    pthom commented #432
  • Dec 22 2018 11:55
    pthom commented #432
  • Dec 21 2018 15:48
    pthom synchronize #432
  • Dec 21 2018 09:19
    sdebionne opened #433
  • Dec 21 2018 00:08
    ricejasonf commented #432
  • Dec 21 2018 00:03
    ricejasonf commented #432
  • Dec 20 2018 23:36
    pthom commented #432
  • Dec 20 2018 23:36
    pthom commented #432
  • Dec 20 2018 23:13
    ricejasonf commented #432
Louis Dionne
@ldionne
The solution to this is actually quite easy: normalize all signed IntegralConstants to llong_c<…>, and all unsigned to ullong_c<…>.
Jason Rice
@ricejasonf
Is there a case when ANY IntregralConstant<5> == IntregralConstant<5> ?
Louis Dionne
@ldionne
I think this should work, right?
Jason Rice
@ricejasonf
ahh
Louis Dionne
@ldionne
Or, FWIW, they could also be normalized to some int_c<> and uint_c<…>, and then we’d simply get more collisons but it would still work (I think).
Jason Rice
@ricejasonf
I think the collisions will be few and far between :P
but I get it now
Louis Dionne
@ldionne
Ok. In the meantime, I’ll try to improve the benchmarks we have right now. One big problem is that the size of the maps we’re creating changes, so we’re really measuring the cost of creating the map + looking up, not only the cost of looking up.
Unfortunately, doing compile-time microbenchmarks is very f*cking difficult.
Jason Rice
@ricejasonf
all the benchmarks?
Louis Dionne
@ldionne
Well, basically all benchmarks have this problem, but I think I’ll start by the map ones.
Since we’re trying to improve it and that’ll help us right away.
Jason Rice
@ricejasonf
On a somewhat unrelated note, I made my own append_if function. https://github.com/ricejasonf/nbdl/blob/master/test/mpdef/append_if.cpp
Simon Brand
@TartanLlama
Hi everyone, I have a quick question about hana::when and the associated documentation.
The API states "when is used to control the priority of partial specializations in a finer grained manner than what can be achieved with the usual typename Enable = void and std::enable_if pattern. For example, a partially specialized tag-dispatched method will have a higher priority than an equivalent specialization that uses when."
I'm having trouble visualizing what that example looks like. Is there some corresponding code somewhere I could look at? I would certainly find it useful if the page had such code as it contains just a textual description.
Louis Dionne
@ldionne
@TartanLlama See the end of the tutorial section on tag-dispatching. I’ll add a link to this section in the reference documentation; thanks for the heads up.
Simon Brand
@TartanLlama
That's perfect, thanks!
Louis Dionne
@ldionne
No problem. Don’t hesitate to let me know if you run into something else!
And thanks for trying the library out.
Jason Rice
@ricejasonf
You know it's going to be a glorious day when template template argument has different template parameters than its corresponding template template parameter. :P
Jason Rice
@ricejasonf
I think I'm getting pretty close with the hash map thing. I put a tuple back in the map and the buckets now contain indices of the elements in the tuple.
so bucket<TypeHash, i...>, struct::hash_table : Bucket..., and struct map : build_map_hash_table<Pair...>::type
but for some reason...
/usr/local/src/hana/include/boost/hana/detail/hash_table.hpp:41:5: note: candidate template ignored: could not match 'bucket' against 'map'
    bucket_get(detail::bucket<TypeHash, i...> const&, Storage const& storage, Key const& key) {
    ^
Jason Rice
@ricejasonf
nm was missing ::type
Jason Rice
@ricejasonf
Sooo.. I got test.map.at_key passing and tried the benchmark...
      "name": "hana::map",
      "data": [[1, 1.622708783019334], [6, 1.698097876040265], [11, 1.7645289140054956], [16, 1.8356641859863885], [21, 1.9189587460132316], [26, 1.9401077149668708], [31, 2.0380619899951853], [36, 2.0923994899494573], [41, 2.2050977970357053], [46, 2.224675818986725], [50, 2.319685415015556], [75, 2.6637842769850977], [100, 2.9832630309974775], [125, 3.3718112600035965], [150, 3.7423034759704024], [175, 4.1199305430054665], [200, 4.508533293032087]]
    }
...and I can still write function overloads to handle buckets with one or no elements :D
It appears to be slower up front, but it scales much better.
Jason Rice
@ricejasonf
jason@jason-nuc:~/temp/experiments$ clang++ -std=c++14 -I/usr/local/src/hana/include map_find.cpp 
jason@jason-nuc:~/temp/experiments$ ./a.out 
just(just((1, -1)))
came in handy :grin:
just might be a problem there :laughing:
Louis Dionne
@ldionne
@ricejasonf The bummer right now is that I’m unable to come up with meaningful benchmarks for map lookup. It always seem to either (1) benchmark the creation of the map or (2) have so much noise the results are useless
If we could have a good way to benchmark map lookup, all the PRs related to maps could be closed or at least unblocked.
Jason Rice
@ricejasonf
maybe we could hack clang to make our own profiler :P
doesn't your version of benchmark.at_key.lookup do the trick?
Louis Dionne
@ldionne

maybe we could hack clang to make our own profiler

That would be great, but a lot of work. And perhaps it couldn’t be made to work properly, because we want to benchmark parsing + semantic analysis + optimization for a part of the code, but these are performed in different passes.

doesn't your version of benchmark.at_key.lookup do the trick?

No, not yet. I’m working on it now, but IDK if that will work. The problem is that without a proper benchmark, we could just as well be pessimizing the map implementation, which would be quite bad.

Jason Rice
@ricejasonf
my original intent with that was to show that map was random access whereas tuple was a linear search
Louis Dionne
@ldionne
The problem with your original benchmark.at_key.lookup is that it creates a map/tuple whose size grows as well as searching for the last element in it. However, the cost of creating the data structure itself is not negligible compared to the cost of looking up stuff in it. Basically, we end up measuring the compile-time of make<…> instead of find_if.
We’re really measuring both, but find_if is not isolated this way.
Jason Rice
@ricejasonf
at_key.lookup was originally created to construct a map with a fixed size of 200 elements
maybe its more common to access n-elements in an n-size map
what if the expensive to create hash map was used only when n>50?
Jason Rice
@ricejasonf
just spitballing
Louis Dionne
@ldionne

at_key.lookup was originally created to construct a map with a fixed size of 200 elements

You are right, but it looked up the n-th element in the map, instead of looking up n distinct elements.

I think looking up n distinct elements in a fixed-size map is the most telling benchmark, but I could be wrong.
I’m running one like that right now.
Louis Dionne
@ldionne
No wonder why I had weird results; debug mode was on and hana::make_map was checking for duplicates. I’m re-running now.
Jason Rice
@ricejasonf
lol
I'm lost on the whole common embedding thing. I would expect this to not fail:
        static_assert(hana::is_embedded<
            hana::integral_constant<signed char, 42>
            , hana::integral_constant<signed short, 42>
        >::value, "");
Louis Dionne
@ldionne
This should probably work.
Let me check why it doesn't