libcxx VS abseil-cpp

If you are comparing hoops that library authors need to jump through in both languages, you can easily make the real-world comparison in the other direction, by comparing Rust's Option with C++'s std::optional (an exercise left for the reader): Rust std: https://github.com/rust-lang/rust/blob/master/library/core/src/option.rs libcxx: https://github.com/llvm-mirror/libcxx/blob/master/include/optional

My favorite prime number generator is the undocumented __next_prime():

https://github.com/llvm-mirror/libcxx/blob/78d6a7767ed57b501...

There is no good reason to use this one except in a code golf environment that includes all headers by default, which is where I learned about it.

I once read a Strousroup quote amounting to "If you understand std::vector, then you understand C++". I thought surely he couldn't have meant the interface but the implentation, googled that llvm's implementation is considered nice and clean, had a look, and noped straight out of there.

C++'s STL linked list for comparison (libcxx).

https://github.com/llvm-mirror/libcxx/blob/master/include/li...

> For example, accessing a std::span or a std::vector outside of its bounds would abort the program, and so would accessing an empty std::optional.

I don't really understand the difference with libc++, libstdc++ and msvc stl's respective debug modes, they already do exactly these checks :

- https://github.com/llvm-mirror/libcxx/blob/78d6a7767ed57b501...

- https://github.com/gcc-mirror/gcc/blob/966010b2eb4a4c52f139b...

I mean it's not hard to read the source for your platform. On Linux/x86_64/libc++ it's roughly:

- https://github.com/llvm-mirror/libcxx/blob/master/include/__...

- https://sourceware.org/git/?p=glibc.git;a=blob_plain;f=nptl/...

I don't particularly care to comb through it to see if anything has changed, but historically it was a a little spin-CAS to make the non-contended path fast and then dropping into a https://en.wikipedia.org/wiki/Futex, which is about as good as it gets for staying mostly in userspace but still letting it be scheduler aware so you're not burning up a core busy-polling, which is what often happens when people try to roll their own shit.

Google wants a bit more latitude on the heuristics and degrees of freedom around read/write ownership, so they did it like this: https://github.com/abseil/abseil-cpp/blob/master/absl/synchr... which is quite a bit better commented/legible.

If anyone reading this can do better than the `abseil-cpp` folks, not only would Google take their PR, they'd probably offer them a job.

Yeah, it's nice! And Abseil does it, IFF you use LLVM libc++.

https://github.com/abseil/abseil-cpp/blob/master/absl/string...

The standard adopted it as resize_and_overwrite. Which I think is a little clunky.

This may be confusing to those familiar with Google's libraries. The baseline is the Go BTree, which I personally never heard of until just now, not the C++ absl::btree_set. The benchmarks aren't directly comparable, but the C++ version also comes with good microbenchmark coverage.

https://github.com/google/btree

https://github.com/abseil/abseil-cpp/blob/master/absl/contai...

An implementation of call_once that accommodates callbacks that throw: https://github.com/abseil/abseil-cpp/blob/master/absl/base/c...

I wouldn't say it's that cryptic. It's just a few bitwise rotations/shifts/xor operations.

You can see hashing optimizations as well https://www.deepmind.com/blog/alphadev-discovers-faster-sort..., https://github.com/abseil/abseil-cpp/commit/74eee2aff683cc7d...

I was one of the members who reviewed expertly what has been done both in sorting and hashing. Overall it's more about assembly, finding missed compiler optimizations and balancing between correctness and distribution (in hashing in particular).

It was not revolutionary in a sense it hasn't found completely new approaches but converged to something incomprehensible for humans but relatively good for performance which proves the point that optimal programs are very inhuman.

Note that for instructions in sorting, removing them does not always lead to better performance, for example, instructions can run in parallel and the effect can be less profound. Benchmarks can lie and compiler could do something differently when recompiling the sort3 function which was changed. There was some evidence that the effect can come from the other side.

For hashing it was even funnier, very small strings up to 64 bit already used 3 instructions like add some constant -> multiply 64x64 -> xor upper/lower. For bigger ones the question becomes more complicated, that's why 9-16 was a better spot and it simplified from 2 multiplications to just one and a rotation. Distribution on real workloads was good, it almost passed smhasher and we decided it was good enough to try out in prod. We did not rollback as you can see from abseil :)

But even given all that, it was fascinating to watch how this system was searching and was able to find particular programs can be further simplified. Kudos to everyone involved, it's a great incremental change that can bring more results in the future.

Check out https://abseil.io. It offers absl::optional, which is a backport of std::optional.