https://cor3ntin.github.io/posts/abi/
the C++ committee took a series of polls on whether to break ABI, and decided not to.
There was no applause.
[…]Why do we want to break ABI
- Making associative container (much) faster
- Making
std::regexfaster (it is currently faster to launch PHP to execute a regex than it is to usestd::regex- Small tweaks to
string,vector, and other container layouts- Adding UTF-8 support to
regexis an ABI break
[…]What is C++ and what is the standard library?
The words touted around are “performance” “zero-cost abstractions” and “don’t pay for what you don’t use”. ABI stability goes directly against all of that.
Far-reaching consequences
I believe, quite strongly, that not breaking ABI in 23 is the worst mistake the committee ever made. And I’m sure some people are convinced of the exact opposite.
Loss of interest in the standard library
The estimated performance loss due to our unwillingness to break ABI is estimated to be 5-10% This number will grow over time. To put that in perspective
- If you are a Big Tech company, you can buy a new data center or pay a team to maintain a library […]
- If you are a game company, it might be the difference between your game being great or your user vomiting in their VR headset
- If you are in trading, it might be the difference between a successful transaction or not.
I think in any case it’s the difference between “I should use C++!” and “I should use the standard library” and “Maybe I should not use the standard library”, up to “Maybe I should not use C++? Maybe I should use .net, julia, rust?”.
Note, this is about the ABI (not the same as API). Julia wants to be stable and have a stable API. I’m not sure there’s any analogy to an ABI in Julia (at least in the default non-binary/PackageCompiler scenario), I believe Julia can and does change internals between major versions, benefiting users (with no downside?).
Does Julia somehow indirectly pay for this (e.g. LLVM, then only for speed of code generation, not at runtime?), or for CxxWrap.jl (or Cxx.jl)?
I’m not entirely sure what this part is about “It is clear that the standard’s associative container failed to be relevant for more than a decade” and “This is the obvious solution If we cannot fix unordered_map , maybe we can add std::fast_map ?” It’s probably related to Google’s Abseil replacement (that the standard can’t adopt?!): abseil / Swiss Tables and <code>absl::Hash</code>
Many game developers are notoriously skeptical of the standard library, they developed alternatives, for example, EASTL. Facebook has folly, Google has Abseil, etc.
This can snowball. If people don’t use the standard library, they have no interest in improving it. Performance is what keeps the standard library alive. Without performance, a lot less energy is going to be pored into it.
https://www.reddit.com/r/cpp/comments/p2gyji/intel_cc_compilers_complete_adoption_of_llvm/
Google withdrew from active participation after the infamous ABI vote.
i.e. from LLVM, why I was looking into this issue I wasn’t familiar with.