Hash_map: Implemented a flat_map backend using unordered_flat_map

[GilesBathgate]

Summary of Changes

• Added unorderd_flat_map_adaptor.h based on CGAL::unordered_flat_map
• Patched Unique_hash_map.h to use this map as its default backend.
• Original chained_map can be re-enabled via CGAL_USE_CHAINED_MAP define.

The map when using boost::unordered_flat_map uses cache friendly memory layout. The mulx mixing uses Fibonacci hashing, leading to a ~6-7% performance boost in the Nef_3_benchmark.

Release Management

• Affected package(s): Hash_map, Nef_3...
• Issue(s) solved (if any): performance
• License and copyright ownership: CGAL, (I added Adreas Fabri and Myself as authors in the new file. Can be changed on request.)

[mglisse]

The name flat_map is used by Boost, and now by the standard, to mean basically a sorted vector with the same interface as std::map. Using it for a hash table here is going to be confusing.

[GilesBathgate]

@mglisse I will rename the header file and class to different name. one of the following:

unordered_flat_map_adaptor
map_adaptor
unique_hash_map_backend

or some other variation of the above?

[afabri]

I asked in PR #9427, but the question should go here: Why does it not become CGAL::unordered_flat_map? @MaelRL @sloriot

[GilesBathgate]

@afabri I am not sure what the question is.

I introduce an adaptor that matches the interface of chained_map providing lookup access methods that wrap CGAL::unordered_flat_map. Do you mean it should become CGAL::unordered_flat_map by name, (despite adding a new interface), or do you mean that we should replace Unique_hash_map backend directly with CGAL::unordered_flat_map, and drop backward compatibility with chained_map?

I created an adaptor to migrate incrementally with a view to reduce the unnecessary indirection in future.