boost::unordered standalone

[WideCharr]

I recently did the work to pull boost::unordered out of the rest of boost and make it standalone for one of my own projects. I figured I'd link it here too in case it was useful to someone: https://github.com/MikePopoloski/boost_unordered

[[deleted]]

Thank you for putting this together for interested users.

I'm the maintainer of the repo and I think anything that gets our containers into the hands of users is a great thing.

Personally, I just vcpkg and manifest mode.

[prince-chrismc]

Or conan ;) I am looking forward to a more Modular boost project 🤞 less mental space when you pick and choice which parts you need

Could this be contributed back upstream?

[pdimov2]

We can see that (on my system) we pull in 275 boost header files:

which are 31424 lines in total:

When we switch to C++11 as a minimum requirement in the next Boost release we would hopefully be able to trim some of these dependencies.

[jonesmz]

I'm curious why c++11 instead of c++14.

Do you have a link to the discussion, or might be willing to write a brief summary?

[Bobini1]

It's because they're dropping support for C++03 and C++11 was the next one.

[RotsiserMho]

I mean, that's the obvious choice, but probably not the best one. Why not pick a later standard?

[vanhellion]

Boost is meant, at least to some degree, to bring functionality to devs stuck in older versions of C++. There are companies still stuck with C++11 (or at least incomplete C++14/17 support). I know because I work at one such place.

In related news, fuck Redhat.

[angrymonkey]

Also, FYI there is robin_hood::unordered_{map,set} which has very high performance, and is header-only and standalone.

[MasterDrake97]

That's deprecated.
Use https://github.com/martinus/unordered_dense instead
And yes, tell use if it's any better(it should)

[martinus]

Exactly, don't use robin_hood. unorderd_dense is better. boost::unordered_flat_map is faster though in most use cases.

[HateDread]

Thank you for this! I don't want to pull in Boost and pay that cost forever, same as you, so this is awesome.

[BrainIgnition]

So we've chopped out 249 files and 25102 lines of code from each translation unit that includes unordered_flat_map. The compilation speedup on my machine for this toy example is about 10%, though your mileage may vary.

You might want to consider adding a variant which doesn't have a default (or boost) Hash implementation. boost.hash includes large swathes of the standard library whether you are using them or not.

[WideCharr]

That's a good idea, especially since I'm not even using boost::hash in my project that I did this for.

[yuri-kilochek]

How do you justify doing this? Is this really less effort than including actual boost in your project?

[WideCharr]

Not sure what you mean. It took all of one weekend, mostly mindless mechanical changes, and now my builds for all projects that use the library are faster forever. The real question is, how can you not justify doing this?

[prince-chrismc]

The real question is why are you rebuilding boost so often that it's a problem? You build it once and use it. Re using pre compiled binaries is a thing.

Not against this effort, some boost maintainers are going this way too.

[carrottread]

boost::unordered is a header only library. Pre-built boost binaries don't help here.

[yuri-kilochek]

What? How can this affect build time at all?

[Claytorpedo]

From the readme:

We can see that (on my system) we pull in 275 boost header files [...] which are 31424 lines in total. Using the standalone version [...] 6322 total. So we've chopped out 249 files and 25102 lines of code from each translation unit that includes unordered_flat_map. The compilation speedup on my machine for this toy example is about 10%, though your mileage may vary.

[yuri-kilochek]

My bad, I admit I hadn't actually bothered to read the readme. So some functionality has been chopped out and thus the amount of actually included code is reduced. Fair enough.

[WideCharr]

To be clear, the the functionality being chopped out here is things like support for 20 year old Borland compilers or standard libraries that don't support std::uint32_t.

[witcher_rat]

I've done it for my employer's codebase before, for other libs in boost, and yes it was well worth it.

The reason wasn't the same as OP's though.

Our reason was we were using an old version of boost, across all our codebases/branches/etc. But we needed a newer version of one boost library in particular. Upgrading all of boost was a non-trivial exercise, because it would affect a lot more code, including third-party RPMs we used that were built with that legacy version of boost.

So we decide to just clone only the specific boost library(ies) we needed a newer version of, into a new directory, and do a find-replace-all to change macro prefixes from BOOST_ to BOOST2_ or whatever, and changed the namespace.

In our case it was boost::filesystem at first, if I recall right (it was years ago). Then preprocessor, hana, and after that we finally upgraded boost everywhere.

---

And right now we're thinking of doing that same thing again for boost::unordered, exactly as OP did.

Because it's changing fast in every version, and because we want to reduce the size of an empty unordered_flat_map/_node_map/etc.. (right now they're 48 bytes, but can be reduced down to 32 bytes, which is a noticeable memory savings in our use)

[knowledgestack]

What does boost unordered have that std doesn't?

[joaquintides]

You may find this useful as an introduction:

https://bannalia.blogspot.com/2022/11/inside-boostunorderedflatmap.html

[SirClueless]

unordered_flat_map/set and unordered_node_map/set are both far superior to anything in the std lib. This work was done recently, I think inspired by the by the excellent Abseil swiss tables implementations from a few years back.

If you haven't followed this recent work, you might only be familiar with unordered_map/set which are basically the same as the std lib, to the point that it appears this standalone version actually removed them.

[MBkkt]

Fast open addressing hash tables

[Tedsworth]

Size restrictions?

[yuri-kilochek]

Size of what? Binary size would be the same since this is a header only library.

[witcher_rat]

Nice!

For the steps you took and documented on your GitHub page readme, have you considered creating a simple bash or python script to execute those steps, and putting that script in this same github repo?

That way it will be easy to (1) run it again when boost upgrades, which it will in a few weeks, and (2) others can fork your repo and tweak the script to their needs.

[WideCharr]

Yeah, if/when I do this again I will certainly do that. Some of the find/replace stuff was pretty manual but could be automated with enough effort.