tessil / sparse-map Goto Github PK

Hi,

Thanks for the great (suite of) hash libraries. They cover a range of impressive performance characteristics! I was wondering if it would be possible to provide some sort of serialization support so that a constructed hash could be serialized to disk and then deserialized in another application. I tend to use hash tables a lot in such a scenario, where I build an index (usually over some genomic sequence) once, but then want to deserialize and use that index many times.

Thanks!
rob

Hi there,

I'm using your tsl::sparse_map with its default settings (growth policy, etc) in the memory cache subsystem of our P2P proxy.
In the last two or three weeks I observed two times that one thread of the proxy was looping in some functionality consuming 100% CPU and when I provoked the process to print stacktrace it was in the
sparse_map::find function both times.
I'm still investigating if the bug is related to the tsl::sparse_map or to some other functionality from the upper levels. However, I was looking at sparse_hash::find_impl and I was wondering if it's possible for this function to loop forever in some edge case. For example, if every checked sparse_ibucket has some value but the keys are not equal to the searched key?
As I said we use the sparse_map with the default growth policy, which I think is power of two and with default search policy, which is linear, as far as I checked.
The count of the entries in the map reaches 262144 (this is the max allowed value) and then usually stays there minus 10-20-50 entries but it doesn't go beyond the set limit.

Regards,
Pavel.

I'm using the sparse_map in scenario where the lower memory consumption is more important than the slightly increased CPU.
My current usage is like this:

tsl::sparse_map<
    some_key
    some_value,
    boost::hash<some_key>,
    std::equal_to<some_key>,
    std::allocator<std::pair<some_key, some_value>>,
    tsl::sh::prime_growth_policy,
    tsl::sh::exception_safety::basic,
    tsl::sh::sparsity::high> map;

And then in the parent object constructor I set

map.max_load_factor(0.8f);

This seems to be working fine when the sparse_map needs to grow.

However, I'm not sure how the sparse_map behaves when it shrinks and if it shrinks?
Here are my observations from the source code of the sparse_map.
Please, correct me if I'm wrong.

1. The sparse_array doesn't seem to have shrinking logic unless it's explicitly cleared which only happens at sparse_map.clear where all buckets are cleared. Is this correct?
2. The sparse_map/hash seems to clear_deleted_buckets upon insertion if the m_load_threshold_clear_deleted is reached. However, clear_deleted_buckets calls rehash_impl with the current buckets count m_bucket_count. So, it seems to me that the bucket array also doesn't shrink back?

Do you see any chance to implement extract() in the sparse-map efficiently? It is especially handy, when one wants to change the key of a entry where the value is expensive to copy.

Hello,

Im trying to support both tsl and std in a single class as follows:

template<template<class...> class Container>
class Map {
	private:
		Container<uint64_t, char *> data;
}

// Map<std::unordered_map>()
// Map<tsl::sparse_map>()

However this gives me:

the template parameter list for class template 'tsl::sparse_map' does not match the template parameter list for template parameter

Apparently because of two non-class parameters at the end of tsl's template. Is there a workaround for this? sparse_pg_map works but not sparse_map.

When compiling with g++ 13.1.0 with -Wall -Wextra (the warning does not occur for g++-12 and g++-11) I obtained some compilation warnings:

../sparse-map/include/tsl/sparse_hash.h:2050:21: warning: possibly dangling reference to a temporary [-Wdangling-reference]
 2050 |     const key_type &key = KeySelect()(key_value);
      |                     ^~~
../sparse-map/include/tsl/sparse_hash.h:2050:38: note: the temporary was destroyed at the end of the full expression <E2><80><98>tsl::sparse_map<int, int>::KeySelect().tsl::sparse_map<int, int>::KeySelect::operator()((* & key_value))<E2><80><99>
 2050 |     const key_type &key = KeySelect()(key_value);

If the warnings are not justified, then it would be nice to have a way to disable that specific warning.

There are 3 places in sparse_hash.h where MSVC gives the aforementioned warning (with /W4 level which is my default). All the conditions are indeed purely compile-time and should be replaced with constexpr. Will you accept a pull request if I fix this?

For example: if (sizeof(unsigned int) == sizeof(std::uint32_t))

Some systems, such as the homebrew Xbox xndk, do not implement exceptions.

It'd be great if tsl::sparse_map had an option to compile without exceptions.

I'll look into it and send a PR shortly

In tsl::sparse_map, iterator->first/second result is always const regardless of the underlying constness.
This is different from std::unordered_map, where iterator->first/second result is const only if the map is const.

This is documented in README.md but there doesn't seem to be anything making this impossible in principle.

The code

auto fctHash=[](size_t val) -> size_t {
  return val;
};
auto fctEqual=[](size_t val1, size_t val2) -> bool {
  return val1 == val2;
};
tsl::sparse_map<size_t, int, decltype(fctHash), decltype(fctEqual)> V({}, fctHash, fctEqual);

does not compile. This is not dramatic as the following does:

std::function<size_t(size_t)> fctHash=[](size_t val) -> size_t {
  return val;
};
std::function<bool(size_t,size_t)> fctEqual=[](size_t val1, size_t val2) -> bool {
  return val1 == val2;
};
tsl::sparse_map<size_t, int, std::function<size_t(size_t)>, std::function<bool(size_t,size_t)>> V({}, fctHash, fctEqual);

but could this be addressed? This would allow better compatibility with the std::unordered_map for which tsl::sparse_map is a replacement.

tsl::sparse_map<int, std::string> m;
for (auto &it : m) {
	std::string &value = it.second;
}

This fails with tsl but works with std::unordered_map.

This is documented in README.md but there doesn't seem to be anything making this impossible in principle.

If we have precalculated hash, emplace/insert might be helpful as well?

Do you have any plans to make a conan package for this project?
I think it is as great as your other projects you publish as conan packages already. ;)

Hi，The current sparse hash table employs bucket-level probing to handle conflicts, ensuring that the fill factor doesn't become too high. Is it possible to use internal probing within a specific "bucket," meaning probing downwards in a bitmap to find an unused bit, in order to locate an available slot for resolving hash collisions?
Apart from that, when determining the rehash threshold, should we consider the number of unoccupied "buckets" rather than the number of "groups"?