Erase Functionality for static_map

[Nicolas-Iskos]

Erase functionality is now supported for static_map via the use of an additional sentinel value. Erased slots can be reused during future insertions. Users can specify that they want erase functionality by providing an erased_key_sentinel during construction. Included below are some plots showing the performance of erase and demonstrating that neither insert nor find incur a performance regression as a result of adding erase support. For each plot, num_keys=1E8.

[GPUtester]

Can one of the admins verify this patch?

[jrhemstad]

add to whitelist

[jrhemstad]

ok to test

[jrhemstad]

@Nicolas-Iskos could you include some of the performance graphs in the PR description?

[jrhemstad]

Can you update the summary documentation above the static_map class to include a discussion of erase? Include:

• Limitations about concurrent insert/find/erase
• Limitations for erase when a erased sentinel was not provided
  • Enforced for bulk API, but not device API

[PointKernel]

First commit from auto formatter! 🎉

[sleeepyjack]

Thanks for implementing this feature!
I've stepped through the core functionality and compared it to WarpCore's SingleValueHashTable implementation. tl;dr: looks good. 👍

[PointKernel]

We can eliminate the stride parameter by directly inferring the optimal grid_size for a given architecture:

Depending on the use case, one way is not always better than the other. If I remember correctly, detail::get_grid_size is really efficient when map occupancy is low. cudaOccupancyMaxActiveBlocksPerMultiprocessor tends to return a relatively small grid size so one thread will handle multiple input elements as opposed to one per thread in manual calculations.

[PointKernel]

@Nicolas-Iskos Thanks for your care and persistency being put into this PR! Looks great to me! Depending on how you see it, we can leave the benchmark refactoring to a separate PR.

[Nicolas-Iskos]

@Nicolas-Iskos Thanks for your care and persistency being put into this PR! Looks great to me! Depending on how you see it, we can leave the benchmark refactoring to a separate PR.

Of course, and thank you guys for all the feedback! I'd be fine leaving the benchmark refactoring to a separate PR. I could even do that with the PR for dynamic_map::erase, where we could refactor the dynamic map benchmark as well.

[PointKernel]

I could even do that with the PR for dynamic_map::erase, where we could refactor the dynamic map benchmark as well.

We can do this once NVIDIA/nvbench#80 is merged. zip_axes can simplify the code a lot.