3 ms·

Is C++ more performant than C? I find this hard to believe. C++ does not have any construct that cannot be replicated, or is not common, in C. The only candidat

Is C++ more performant than C? I find this hard to believe. C++ does not have any construct that cannot be replicated, or is not common, in C. The only candidate is using virtualization and void* pointers instead of monomorphized generics which some C code does for the lack of better options, but that's not a problem in Rust as well. If anything, Rust has the potential to be more performant than C due to its aliasing rules (C has `restrict` but it's rarely used, standard C++ does not have even that). The current perf stats show it does make Rust code faster but just a little bit, although we don't utilize the full optimization potential currently (LLVM does not do many possible optimizations here, and `noalias` is weaker than Rust's aliasing rules). It can also affect autovectorization, and if it does the effect could be dramatic.

loeg 5mo ago
C++ you get templated generic algorithms that in practice no one really does with C because macros suck too much. So in C typically you'd have a runtime generic routine that doesn't inline. A classic example here is qsort() vs std::sort().
- afdbcreid 5mo ago
  I explicitly acknowledged that: > The only candidate is using virtualization and void* pointers instead of monomorphized generics which some C code does for the lack of better options, but that's not a problem in Rust as well. But in fact, if speed is a concern to you, even in C you will use "templated" sorting (via macros or code generation).
  - 20k 5mo ago
    The problem is that the implementation burden with C is so high, that people tend not to do it even in relatively performance constrained situations
  - fluffybucktsnek 5mo ago
    Neither codegen nor macros (they are a part of the preprocessor) are really a part of C. For the latter, the lack of integration becomes more noticeable if you try writing a macro in which the compare param can accept a function identifier. As the preprocessor doesn't have the knowledge of the contents of the referred function, it can't inline it. In C++ and Rust, their compilers do, so they can. A codegen tool could overcome this, but you could also make a codegen tool to write Zig/D/C#/Swift in C, or any other language for that matter :). By this point, one could say you are programming in a superset of C, not strict C.
  - loeg 5mo ago
    > in practice no one really does with C because macros [and codegen] suck too much
- flohofwoe 5mo ago
  > So in C typically you'd have a runtime generic routine that doesn't inline. With LTO you get many of the same advantages as C++ template code, there's nothing magic about C++ template optimizations, it's all about whether the compiler can see all function bodies in a call hierarchy.
  - simonask 5mo ago
    LTO cannot change the layout of structs. For something like a hash map implementation, it matters whether inner nodes store a pointer to the key and value, or whether it stores a pointer to each. To achieve this in C, you have no other options than emulating templates using macros.
    - flohofwoe 5mo ago
      The question is whether a hash-map implementation that works on a general `[key, index]` item and where index references at separate array of values isn't actually better for some access patterns ;) And of course the other alternative to macros is code-generation (but macros are actually often fine). But this also only matters for actually reusable generic code. If I'd implement a super-hot-path hashmap in C, I would stamp out a specialized version by hand instead of relying on a generic implementation. But for 90% of cases, a solution like in stb_ds.h is probably good enough.
      - simonask 5mo ago
        Sure, but now you're actually moving the goal posts. We're talking about the practicalities - you can always achieve the same by doing more work, but it makes a difference that Rust gives you `HashMap` in the standard library that you can just use and get best-in-class performance, every time, with zero work, zero maintenance. The only choice you have to make is which hash function you want to plug into it, and since it is generic, that gets optimized and inlined as well (even with LTO disabled).
- nicoburns 5mo ago
  Rust also has these advantages of course
  - tialaramex 5mo ago
    Indeed Rust's standard library provides much better sorts both in terms of performance and in terms of resistance to abuse than those provided in the big three C++ implementations.
  - loeg 5mo ago
    Right. I'm mostly addressing GP's first question about C and C++.
fithisux 5mo ago
You can write C style C++ and enjoy the same benefits. In Twitter a user explained me that it is common in embedded space. You do not need the OOP, RTTI, exceptions. Like C with most use cases of preprocessor replaced by generic programming.
- afdbcreid 5mo ago
  So? How is that an argument that C++ is more performant than C? It's only an argument that it's not less performant.
  - pjmlp 5mo ago
    Because you can write C like code, while taking advantage of templates, compile time code execution, and eventually static reflection, that prepare work ahead of time, while at the same time giving more information to optimiser passes.
  - fithisux 5mo ago
    It is an argument that you can make a faster C-like if you like out of C++
smallstepforman 5mo ago
c++ uses rich type system to avoid aliasing when it can, as well as template meta programming. Eg: delete_scene(void *arg) vs delete_scene<T>(T *arg)
jandrewrogers 5mo ago
Modern C++ metaprogramming materially impacts performance in practice. I’ve done performance engineering for decades in both C and modern C++ and I would assert that the difference isn’t arguable. The poor applicability of auto-vectorization is another area where C++ is strong. You can transparently codegen e.g. AVX512 from intrinsics directly in C++ in contexts that would be opaque to auto-vectorization and difficult to generalize in C. This allows you to get some degree of “auto-vectorization” where the compiler can’t see it because it works at the wrong level of abstraction. With sufficiently heroic efforts you can write C that matches the performance of C++. I’m not arguing that. Virtually no one writes C to that standard, including myself when I was writing high-performance C because the effort was too high, so it is a bit of a strawman. It is the difference between theory and practice. All code bases have a finite budget. C++ can do a lot more optimization in the same budget as C.
- globalnode 5mo ago
  So youre saying the metaprogramming facilities of C++ allow the compiler to better optimise high level human readable code more effectively than C. Thats a fair point and one I'd never even thought of before, I always thought C was faster because of things like v-tables and all that stuff.
  - adrian_b 5mo ago
    In C++, nobody would want or need to use virtual functions in high-performance computational applications, while in the C language structures with virtual function tables that are accessed explicitly by the programmer are in widespread use wherever suitable, for instance in many popular open-source C programs, like the Linux kernel or the debugger gdb. So the existence of virtual function tables is not a differentiator between C++ and C. The data types with virtual function tables are just the implementation method for sum types that is dual to tagged unions. Both virtual function tables and tagged unions can be implemented in C and in most other programming languages that do not have intrinsic support for them, but they require explicit boilerplate code for invoking the virtual functions or for testing the union tags. Which is the better of these 2 variants depends on the application. In high-performance computations, one does not use ambiguous data types, so normally none of these 2 is used. There are a few object-oriented programming languages where "everything is an object", i.e. any kind of data includes a virtual table pointer, but those are just incomplete programming languages, which do not have all the data types needed in practice, like also many early programming languages that had a unique data type, e.g. the original LISP I, which had only linked lists and no arrays, etc. C++ at least is a complete language, in which any kind of data type can be implemented, without overheads. As you said previously, C has few restrictions in what it can do, so in theory it is almost always possible to write a C program almost exactly equivalent with any program written in another language, matching its speed, even if that may require a significant reorganization of the code, not a line to line translation. Nevertheless, as the other poster said, the effort needed to write that equivalent program may be so high that it is not a realistic solution. So in practice it is not unusual that at similar programming efforts a higher-level language like C++ frequently allows writing a faster program than C.
amelius 5mo ago
> I find this hard to believe. C++ does not have any construct that cannot be replicated, or is not common, in C. But this is not a valid argument, as all languages are Turing complete, and most modern languages can do low level stuff at optimum speeds. As an extreme example, in Java, you could just allocate a large chunk of memory and run an allocator inside of it and sidestep the GC entirely. With a programming language the question is thus not what can you do with it and how fast can it run with infinite effort, but what are the ergonomics, and what performance will you get in practice.
dwaite 5mo ago
> Is C++ more performant than C? I find this hard to believe. At the compiler level, no. But as you write projects, you will for instance run into things you can do with templates which are infeasible to attempt with macros. One example might be qsort() - a C compiler _could_ catch cases where it could create an intrinsic qsort based on the data type and function pointer being passed. However, in C++ you have the facilities to create a type safe, genericized sort that will be inlined based on the data structure.
deleted 5mo ago
[deleted]
bluGill 5mo ago
It is not uncommon to realize your C program is valid C++ and get a performance improvement just by building with a C++ compiler no other change. The difference is small but C++ has a stronger type system which allows the compiler a few more optimizations. Of course it is possible that resulting program no longer does what you want but actually needing weaker types is rare. Restrict could make things go different but I've never heard someone say otherwise. Note that we are talking about differences that are tiny here. They can be measured if you are careful but they are almost guaranteed to not be something anyone would notice if they were not measuring

loeg 5mo ago

C++ you get templated generic algorithms that in practice no one really does with C because macros suck too much. So in C typically you'd have a runtime generic routine that doesn't inline. A classic example here is qsort() vs std::sort().

afdbcreid 5mo ago
I explicitly acknowledged that: > The only candidate is using virtualization and void* pointers instead of monomorphized generics which some C code does for the lack of better options, but that's not a problem in Rust as well. But in fact, if speed is a concern to you, even in C you will use "templated" sorting (via macros or code generation).
- 20k 5mo ago
  The problem is that the implementation burden with C is so high, that people tend not to do it even in relatively performance constrained situations
- fluffybucktsnek 5mo ago
  Neither codegen nor macros (they are a part of the preprocessor) are really a part of C. For the latter, the lack of integration becomes more noticeable if you try writing a macro in which the compare param can accept a function identifier. As the preprocessor doesn't have the knowledge of the contents of the referred function, it can't inline it. In C++ and Rust, their compilers do, so they can. A codegen tool could overcome this, but you could also make a codegen tool to write Zig/D/C#/Swift in C, or any other language for that matter :). By this point, one could say you are programming in a superset of C, not strict C.
- loeg 5mo ago
  > in practice no one really does with C because macros [and codegen] suck too much
flohofwoe 5mo ago
> So in C typically you'd have a runtime generic routine that doesn't inline. With LTO you get many of the same advantages as C++ template code, there's nothing magic about C++ template optimizations, it's all about whether the compiler can see all function bodies in a call hierarchy.
- simonask 5mo ago
  LTO cannot change the layout of structs. For something like a hash map implementation, it matters whether inner nodes store a pointer to the key and value, or whether it stores a pointer to each. To achieve this in C, you have no other options than emulating templates using macros.
  - flohofwoe 5mo ago
    The question is whether a hash-map implementation that works on a general `[key, index]` item and where index references at separate array of values isn't actually better for some access patterns ;) And of course the other alternative to macros is code-generation (but macros are actually often fine). But this also only matters for actually reusable generic code. If I'd implement a super-hot-path hashmap in C, I would stamp out a specialized version by hand instead of relying on a generic implementation. But for 90% of cases, a solution like in stb_ds.h is probably good enough.
    - simonask 5mo ago
      Sure, but now you're actually moving the goal posts. We're talking about the practicalities - you can always achieve the same by doing more work, but it makes a difference that Rust gives you `HashMap` in the standard library that you can just use and get best-in-class performance, every time, with zero work, zero maintenance. The only choice you have to make is which hash function you want to plug into it, and since it is generic, that gets optimized and inlined as well (even with LTO disabled).
nicoburns 5mo ago
Rust also has these advantages of course
- tialaramex 5mo ago
  Indeed Rust's standard library provides much better sorts both in terms of performance and in terms of resistance to abuse than those provided in the big three C++ implementations.
- loeg 5mo ago
  Right. I'm mostly addressing GP's first question about C and C++.

fithisux 5mo ago

You can write C style C++ and enjoy the same benefits. In Twitter a user explained me that it is common in embedded space. You do not need the OOP, RTTI, exceptions. Like C with most use cases of preprocessor replaced by generic programming.

afdbcreid 5mo ago
So? How is that an argument that C++ is more performant than C? It's only an argument that it's not less performant.
- pjmlp 5mo ago
  Because you can write C like code, while taking advantage of templates, compile time code execution, and eventually static reflection, that prepare work ahead of time, while at the same time giving more information to optimiser passes.
- fithisux 5mo ago
  It is an argument that you can make a faster C-like if you like out of C++

smallstepforman 5mo ago

c++ uses rich type system to avoid aliasing when it can, as well as template meta programming. Eg: delete_scene(void *arg) vs delete_scene<T>(T *arg)

jandrewrogers 5mo ago

Modern C++ metaprogramming materially impacts performance in practice. I’ve done performance engineering for decades in both C and modern C++ and I would assert that the difference isn’t arguable. The poor applicability of auto-vectorization is another area where C++ is strong. You can transparently codegen e.g. AVX512 from intrinsics directly in C++ in contexts that would be opaque to auto-vectorization and difficult to generalize in C. This allows you to get some degree of “auto-vectorization” where the compiler can’t see it because it works at the wrong level of abstraction. With sufficiently heroic efforts you can write C that matches the performance of C++. I’m not arguing that. Virtually no one writes C to that standard, including myself when I was writing high-performance C because the effort was too high, so it is a bit of a strawman. It is the difference between theory and practice. All code bases have a finite budget. C++ can do a lot more optimization in the same budget as C.

globalnode 5mo ago
So youre saying the metaprogramming facilities of C++ allow the compiler to better optimise high level human readable code more effectively than C. Thats a fair point and one I'd never even thought of before, I always thought C was faster because of things like v-tables and all that stuff.
- adrian_b 5mo ago
  In C++, nobody would want or need to use virtual functions in high-performance computational applications, while in the C language structures with virtual function tables that are accessed explicitly by the programmer are in widespread use wherever suitable, for instance in many popular open-source C programs, like the Linux kernel or the debugger gdb. So the existence of virtual function tables is not a differentiator between C++ and C. The data types with virtual function tables are just the implementation method for sum types that is dual to tagged unions. Both virtual function tables and tagged unions can be implemented in C and in most other programming languages that do not have intrinsic support for them, but they require explicit boilerplate code for invoking the virtual functions or for testing the union tags. Which is the better of these 2 variants depends on the application. In high-performance computations, one does not use ambiguous data types, so normally none of these 2 is used. There are a few object-oriented programming languages where "everything is an object", i.e. any kind of data includes a virtual table pointer, but those are just incomplete programming languages, which do not have all the data types needed in practice, like also many early programming languages that had a unique data type, e.g. the original LISP I, which had only linked lists and no arrays, etc. C++ at least is a complete language, in which any kind of data type can be implemented, without overheads. As you said previously, C has few restrictions in what it can do, so in theory it is almost always possible to write a C program almost exactly equivalent with any program written in another language, matching its speed, even if that may require a significant reorganization of the code, not a line to line translation. Nevertheless, as the other poster said, the effort needed to write that equivalent program may be so high that it is not a realistic solution. So in practice it is not unusual that at similar programming efforts a higher-level language like C++ frequently allows writing a faster program than C.

amelius 5mo ago

> I find this hard to believe. C++ does not have any construct that cannot be replicated, or is not common, in C. But this is not a valid argument, as all languages are Turing complete, and most modern languages can do low level stuff at optimum speeds. As an extreme example, in Java, you could just allocate a large chunk of memory and run an allocator inside of it and sidestep the GC entirely. With a programming language the question is thus not what can you do with it and how fast can it run with infinite effort, but what are the ergonomics, and what performance will you get in practice.

dwaite 5mo ago

> Is C++ more performant than C? I find this hard to believe. At the compiler level, no. But as you write projects, you will for instance run into things you can do with templates which are infeasible to attempt with macros. One example might be qsort() - a C compiler _could_ catch cases where it could create an intrinsic qsort based on the data type and function pointer being passed. However, in C++ you have the facilities to create a type safe, genericized sort that will be inlined based on the data structure.

deleted 5mo ago

[deleted]

bluGill 5mo ago

It is not uncommon to realize your C program is valid C++ and get a performance improvement just by building with a C++ compiler no other change. The difference is small but C++ has a stronger type system which allows the compiler a few more optimizations. Of course it is possible that resulting program no longer does what you want but actually needing weaker types is rare. Restrict could make things go different but I've never heard someone say otherwise. Note that we are talking about differences that are tiny here. They can be measured if you are careful but they are almost guaranteed to not be something anyone would notice if they were not measuring