[libcxx-commits] [PATCH] D61878: Use is_permutation when comparing containers

[Zoe Carver via Phabricator via libcxx-commits]

zoecarver updated this revision to Diff 199745.
zoecarver added a comment.

I played around with this a bit and (thanks for @mclow.lists) discovered that there are issues with using `is_permutation`. I tried to take the best of both of these implementations by adding `is_permutation`'s loop which chops off any identical parts and by removing the unneeded call to `is_permutation` while keeping the `equal_range` check. Here is the result:

  -------------------------------------------------------------------------------------
  Benchmark                                          Time             CPU   Iterations
  -------------------------------------------------------------------------------------
  initialize_data                                0.000 ns        0.000 ns            0
  test_old/OLD_compare_small_set                 62502 ns        62483 ns        11055
  test_new/NEW_compare_small_set                 26598 ns        26591 ns        27834
  test_old/OLD_compare_similar_set               97684 ns        97492 ns         8014
  test_new/NEW_compare_similar_set               22088 ns        22080 ns        33696
  test_old/OLD_compare_big_set                79731796 ns     79664100 ns           10
  test_new/NEW_compare_big_set                74296876 ns     74245222 ns            9
  test_old/OLD_compare_big_set_different      71916394 ns     71878300 ns           10
  test_new/NEW_compare_big_set_different     147169839 ns    147085200 ns            5
  test_old/OLD_compare_oposite_order_set     306415935 ns    305943000 ns            2
  test_new/NEW_compare_oposite_order_set     329123963 ns    329029500 ns            2
  test_old/OLD_compare_random_set             12786696 ns     12763356 ns           45
  test_new/NEW_compare_random_set              3610982 ns      3605559 ns          211
  test_old/OLD_compare_random_set_different       2888 ns         2883 ns       250692
  test_new/NEW_compare_random_set_different       2882 ns         2868 ns       234480
  test_old/OLD_compare_short_string             241644 ns       241291 ns         2902
  test_new/NEW_compare_short_string              61157 ns        60933 ns         8343
  test_old/OLD_compare_long_string             1369126 ns      1366185 ns          509
  test_new/NEW_compare_long_string              142631 ns       142461 ns         6213
  test_old/OLD_compare_different_strings           311 ns          310 ns      2278497
  test_new/NEW_compare_different_strings           319 ns          318 ns      2245367

Let's break this down. You will notice that in every one of these bencharks, `NEW_*` is faster or equally as fast as `OLD_*`  with two exceptions: `compare_different_strings` and `compare_big_set_different`. The first one is similar enough that I won't worry about it, but the second one is what worries me. For some reason, the new implementation is **twice** as slow as the old one. However, when I look at the number of times values are compared the new implementation compares `4999507` values while the old one compares `4999505` values. Two comparisons should not make that big a difference. Additionally, when I run this outside of the benchmark enviorment the comparisons take almost the same amount of time. Any thoughts on why this might be?

Note: careful when running these benchmarks, it takes almost 5GB of memory.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D61878/new/

https://reviews.llvm.org/D61878

Files:
  benchmarks/unordered_set_comp.bench.cpp
  include/unordered_map
  include/unordered_set

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D61878.199745.patch
Type: text/x-patch
Size: 20196 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/libcxx-commits/attachments/20190516/dafe2548/attachment-0001.bin>