Hacker News Reader

  > Continue being the fastest systems language possible.

If you want to be pedantic -- in theory C++ can never be the fastest systems language possible because of the language's rules about aliasing.

You'd need to smatter "_restrict" everywhere to skirt this.

This is not pedantic at all. Aliasing issues are really subtle and hinder so many optimizations. It's not clear that there is a way to even fix this without substantially breaking backwards compatibility.

Yeah the number of cases where otherwise really trivial optimizations are prevented because of soundness concerns regarding aliasing is simply enormous.

> If you want to be pedantic -- in theory C++ can never be the fastest systems language possible because of the language's rules about aliasing.

True but the only practical competitor is Rust, and they gain some alias information (mut) and lose other aliasing information (type punning is fully allowed in unsafe code all the time).

Not so, unsafe code still has restrictions in Rust due to pointer provenance. You can override these restrictions but it's very much an explicit operation, the default is that pointers with incompatible provenance will not alias. This is how Rust models its equivalent to TBAA, and the concept is spreading to C/C++ as well.

> Not so, unsafe code still has restrictions in Rust due to pointer provenance.

That's separate from what I'm referring to. In C++ a float* and an int* can never alias. In Rust f32* and u32* are allowed to. Meaning in a situation where whether they can alias can't be established by provenance (e.g. in a separately compiled function where the compiler at compilation time can't tell where the float and int came from) then C++ is able to use types to rule out aliasing, but Rust cannot.

Your specific gripes seem reasonable (I suspect design-by-committee plays a big part), but:

> I really wish the std would drop this pretense and focus on C++'s strong point: Continue being the fastest systems language possible.

You've essentially described C, not C++. C++ has a different philosophy and makes different trade-offs.

C++ is at least still pretty committed to the you only pay for what you use principle. As far as I know RTTI is the only real exception (corrections welcome), but even RTTI can be disabled in many compilers.

Some of your gripes with the standard library can be addressed with libraries, perhaps from the Boost project.

> C++ is at least still pretty committed to the you only pay for what you use principle. As far as I know RTTI is the only real exception (corrections welcome), but even RTTI can be disabled in many compilers.

Compile time would also be an exception.

I had a program that had to parse a lot of integers like "12345". The std way to do it was an order of magnitude slower than writing my own simple parsing code. I have no idea what the std version was doing, but it was crazy to see my program's execution time (measured in hours) dominated by int parsing. The handwritten version eliminated that.

You didn't say which std function you were using that was slow. But std::from_chars performs a lot faster than std::stoi et al due to many reasons.

Yeah I don't remember what I originally used. It might have been stoi but it might have been iostream.

Even there, you can use a subset of C++ and get pretty good compile times. Worse than C, as you're still dragging around the full weight of a C++ compiler, but still.

> You've essentially described C

I'd disagree pretty strongly with that. C is more focused on being relatively simple to implement and backwards compatibility with the past 50 years. (I read a blog post by a C committee member talking about that recently, wish I could find the link)

Just look at the garbage fire which is the standard library. qsort. strtok. rand.

C++ should (in theory at least) be able to match or surpass C for _any_ performance benchmark, because it simply gives you more tools in your toolbox. For example, C is never going to be able to beat std::sort because it can't monomorphize in the compare function.

I'm not saying C++ is perfect either (looking at you unordered_map and regex). But I am saying people look at C with rose colored glasses.

Yeah, I think a degree of complexity is required to achieve being the fastest compiled language.

To achieve that, you need stuff like monomorphized templates, actual arrays and slices being distinguished from pointers, well-defined rules on pointers (like Rust's rules about references and mutable references, or strict aliasing in C++), and the freedom to let the compiler reorder structure fields for better alignment and space usage. Runtime polymorphism, like virtual functions in C++, are better as a core language feature rather than something implemented as a struct of function pointers, because that way the compiler can devirtualize some calls.

All of these things, I think most C programmers would be against adding to C. And pointer rules are historically controversial; for example, Dennis Ritchie was against adding noalias to C in 1988[1].

[1]: https://www.yodaiken.com/2021/03/19/dennis-ritchie-on-alias-...

No, C is not the same as it is less expressive.

C++ templates allow for declarative nested inlining into a single compilation unit that is extremely difficult to achieve with C macros.

See elsewhere in this thread for discussion of boost, it's not applicable.

In this thread: all the people that have never looked at C++ disassembly. Maybe the C++ "language server" of your choice should have a mode where it prints all the constructors destructors copy constructors and what not on top of your code?

"Zero cost abstraction" is a big fantasy. C++ is the king of hidden control flow and the costs are everywhere.

Thanks for the shitty attitude but it sounds more like you're looking at the disassembly of debug builds or don't understand how constexpr/consteval work.

> In this thread: all the people that have never looked at C++ disassembly. Maybe the C++ "language server" of your choice should have a mode where it prints all the constructors destructors copy constructors and what not on top of your code?

That tool is called Godbolt at gcc.godbolt.org. This is common enough that Godbolt is a verb with a lot of C++ programmers.

As someone who reads C++ disassembly/decompilation for a living... Yeah kinda. It depends.

If the target code is full of virtual function calls, yeah it gets gross. But if you need dynamic dispatch, C isn't going to be any better, you'll just be reinventing vtables by hand. Similarly, resource acquisition and release happens in C too, you just have to do it by hand instead of letting the destructor do it for you.

One ultra gross thing I see all the time in C++ disassembly though: constantly creating copies of a std::string, using them once for a comparison or something trivial, and then throwing them away. Multiple times in the same function. Its the developers fault, they shouldn't be creating new objects, they should be passing a pointer or a string_view or something. Unfortunately, C++ is copy rather than move by default, so its too easy to do this by accident.

Another gross thing? (Not C++ specific) 20 functions in a row that are just a single return instruction. Since functions have to have distinct addresses (that's my understanding at least) the compiler/linker can't easily fold identical functions together. Implementations can optimize as long as everything still works (the "as-if" rule). And I know some compilers do. But in practice, it seems they suck at it. So I get to look at 20 lines of assembly in a row that are just `bl`.

In practice the Sufficiently Smart Compiler will have a hard time optimizing all these layers.

C macros are way simpler as they are only text. I still use them alot in C++.

the only pay what you use thing is bullshit. because everything you want to use actually costs something. the point being that a better implementation would give you the same things without a cost...

"only pay for what you use" means that you do not pay for things you do not use. You are absolutely correct that everything has a cost, but that is not what this slogan is about. The "only" is load-bearing.

From my understanding exceptions are also an exception, adding overhead even when not used.

Why does this have to be part of the standard library? Isn't that the whole point of Boost, that one is not limited to what's in std?

It depends on the contributors, but boost also almost always fails to consider performance implications.

For me it mostly looks like a reject pile for a stdlib that I must also reject most of the time.

The alignment of incentives between these library authors and people that use C++ for high performance applications is just off.

> For me it mostly looks like a reject pile for a stdlib that I must also reject most of the time.

It’s also the opposite: a place where possible candidates for the standard get tried out first.

But like you, I rarely use it.

I have never once seen Boost seriously considered in performance environments.

Boost has its uses and in many cases it's an improvement over the standard library, but performance isn't one of its key properties. Some parts of boost are about as fast as they can be, but that's the exception.

Even if somebody put such a thing, or two, in the standard library there would be again someone showing that they managed to come up with a better solution. For their workload. And under constraints that are only valid under their use-case and constraints that only they would know. Not standard library developers. And that's the thing - the premise that "one size fits all" even exists is wrong. I used to think that way as well but generic solutions to high-performance algorithms do not really exist.

It was my understanding that one can easily add their own allocator to any STL container, though as you point out you have to write that allocator yourself

> one can easily add their own allocator to any STL container,

You and I must have a different definition of "easily "

How about this?

  template<typename T>
  struct Foo {
    using value_type = T;
    Foo() = default;
 
    template<typename U>
    constexpr Foo(const Foo <U>&) noexcept {}
 
    T* allocate(std::size_t n) {
        if (n > std::numeric_limits<std::size_t>::max() / sizeof(T))
          throw std::bad_array_new_length();
        auto p = static_cast<T*>(std::malloc(n * sizeof(T)));
        if (!p) throw std::bad_alloc();
        return p;
    }
 
    void deallocate(T* p, std::size_t n) noexcept {
        std::free(p);
    }
  };

And then you go and use it as

  std::vector<int, Foo<int>> v;

So the complexity is not really in writing the "C++ allocator" but in writing a sufficiently complex memory management logic that will actually make your application/algorithm run faster. And that only you can know given that you're familiar with the memory allocation patterns in your code. C++ allocator is only an interface that allows you to capture that logic and makes it feasible to apply through the code.

If you're in a position where you know you need a different allocator, and you have your own allocator, plugging it in should be relatively easy in comparison.

You can but it's definitely not easy to do correctly.

There's also a lack of traits that can describe what's required of a specialized allocator. For example, std::map only needs to allocate 1 object at a time in practice while std::vector needs to allocate a contiguous count of objects.

Allocators have an inherently broken design, tying them to types. See this CppCon talk by the (engaging and funny) Andrei Alexandrescu:

https://www.youtube.com/watch?v=LIb3L4vKZ7U

std::allocator is to allocation what std::vector is to vexation (or: designing allocators that don't not-work)

If the allocator is unaware of your type, how do you initialize the underlying object? That is - how do you invoke the default or non-default constructor of type T over the memory region you just allocated?

That's not the allocator's job, is it? It's up to the allocator's user to call one of the several available varieties of placement new on the block of memory allocated.

> That's not the allocator's job, is it?

I don't see that point because this is not a technical argument, is it?

> It's up to the allocator's user to call one of the several available varieties of placement new on the block of memory allocated.

This would have been a point if that's the control you don't have with the allocator interface. But you do.

I imagine that you're not suggesting invoking placement-new oneself all over the place whenever one allocates the backing storage?

It is a technical argument. Allocator's responsibility is to allocate memory. Constructing objects in that memory is not (and must not be) its responsibility.

> This would have been a point if that's the control you don't have with the allocator interface. But you do.

Well, std::allocator::construct() has been removed in C++20. You still have std::allocator_traits::construct but it just calls std::construct_at().

> you're not suggesting invoking placement-new oneself all over the place whenever one allocates the backing storage

Well, that's what all the standard containers do (vector, list, map, etc). Or you can use std::construct_at() instead but that effectively is a variant of the placement new. Of course, you'd better use std::make_unique()/make_shared() (which normally still devolves to placement new IIRC) instead of manipulating raw pointers and invoking constructors manually.

>std::string allocating

You mean you want string_view? It still calls strlen when you instantiate it with a literal though.