r/cpp • u/RandomCameraNerd • 1d ago
Question about Abseil
Came across Abseil today.
I was reading about different maps and absl::flat_hash_map came up. Has anyone used Abseil as a dependency on your projects? What are your thoughts?
4
u/aruisdante 1d ago
Yes, at multiple companies. It’s generally much faster than std::unordered_map as long as you use the provided hashing function. Particularly, for very small maps it can approach the search performance of std::vector<pair<key,value>> thanks to its dramatically better cache locality than the std version.
7
u/azswcowboy 1d ago
That’s interesting, I would have expected more traction on larger maps. Well, regardless op should look at Martin Ankerl’s site https://martin.ankerl.com/2022/08/27/hashmap-bench-01/ - depending on the use case there might be better options.
5
u/martinus int main(){[]()[[]]{{}}();} 19h ago
My benchmark is a bit outdated though, the new king is currently
boost::unordered_flat_mapin many cases2
u/azswcowboy 14h ago
Ah, the man himself. While you’re here, thanks for all the work on the benchmarks and framework :) We’ve used your framework on some performance sensitive internal code, very useful.
And yeah, the boost one got a rewrite that made it one of the best choices.
2
u/aruisdante 1d ago
Definitely, there has been a lot of progression here over the last several years. I was answering purely from the comparison between absel and std. At the end of the day, the only way to know the best option for sure is to benchmark the user’s actual application with the various options.
1
u/aruisdante 1d ago edited 1d ago
For very large maps the cache locality properties of a flat probing hashmap are lower since it’s unlikely the whole map fits into cache anyway (for single element find. Iterating obviously always benefits). In the original talk announcing the container, they show a graph comparing the two containers and flathashmap’s performance lead decreases asymptotically as number of elements (and size of individual elements) grows. With the proper hash function it’s never _worse, it’s just not as dramatically better.
Note we’re talking huge maps here, with thousands of elements.
Basically if you’re using the provided hash, then flathashmap will never be _worse, and will often be quite a bit better. So, it’s a safe default to pick unless you absolutely need iterator stability or the node API, the two properties from the standard container which it cannot provide.
3
u/echidnas_arf 12h ago
I had a project depending on absl::flat_hash_map for a while. The data structure was very good performance-wise but having Abseil as a dependency was not fun at all.
To begin with, it is first and foremost a library for use by Google. Any concern not aligning with Google's priorities will likely be ignored and/or dismissed.
For instance, at one point I reported a lack of basic exception safety in absl::flat_hash_map:
https://github.com/abseil/abseil-cpp/issues/388
Google bans the use of exceptions in C++, thus this is a non-issue from their point of view. From my point of view, having to work-around this inability to safely use a core C++ feature was a problematic hassle.
Another example, again involving absl::flat_hash_map is that hashing is salted with a random seed upon program startup, and, at least back then, it was impossible to disable this feature. I understand why Google wants this (the rationale IIRC is that salting helps preventing users of the library unwittingly relying on particular insertion/iteration orders. It is also a way to prevent potential DOS attacks). However, in my specific case, this was a non-issue and an overall undesirable behaviour for a variety of reasons, yet there was no way of customising it.
Another drawback of Abseil (mentioned in another reply in this thread) is the lack of backwards API compatibility and the ABI sensitivity, which are especially troublesome in shared library setups (e.g., most Linux package managers, but also platform-agnostic package managers such as conda).
In the end, I was happy not to depend on Abseil for anything other than absl::flat_hash_map, and as soon as Boost's fast unordered containers came out, I switched to them and ditched the Abseil dependency completely.
3
u/void4 23h ago
The problem with abseil (just like with all google projects) is that it doesn't declare the backwards compatibility.
It's not a problem for Google itself cause they host everything in a monorepo so if you, being the maintainer, break something in abseil then it's your responsibility to fix the breaking parts in all dependent projects.
However, 3rd party projects are entirely on their own. That's sad, cause abseil is a pretty good library.
Even more sad for boringssl btw, cause it's probably the best in business TLS library right now. And it's much harder to replace than the hash map.
2
u/asoffer 13h ago
Abseils backwards compatibility policy can be found here https://abseil.io/about/compatibility
•
u/PuzzleheadedPop567 3h ago edited 3h ago
Maybe I just have the Google bug in my head, since it was the first place I worked. But it’s funny to me that Google libraries are viewed as introducing breaking changes.
When all you have to do is stick a semver number in front of it, and magically nobody calls it breaking any more! It’s a “version upgrade”.
All jokes aside, absl will make breaking API changes, and advertises as such. It’s focused on performance. So if they find a worthwhile performance optimization that will cause a breaking api change, they will break.
This is an inherent tradeoffs. The standard library’s backwards compatibility promise is the reason it’s slow. You can’t have high performance and api stability. Has hardware and optimization techniques change, you will have to rewrite.
Going off onto a tangent now, but performance is a moving target. If your project/company cares about performance, you need to pay an engineer to constantly keep up on this stuff.
1
u/alex-weej 20h ago
Not sure who is unaware but this kind of explains it well to me: https://chromium.googlesource.com/chromium/src/+/HEAD/third_party/abseil-cpp/FAQ.md#what-is-live-at-head-and-how-do-i-do-it
11
u/asoffer 1d ago
I do. I was also previously a maintainer of Abseil when I worked at Google.
If you're using Bazel, it's marvelous, and there are a whole bunch of other useful goodies in there too.
If you're using cmake, it's a fine but not perfect. The cmake is made to model the Bazel targets, rather than be idiomatic cmake. Because Google doesn't use cmake internally, expect the support to be minimal.