3 ms·

Then let's look at C++, which in some areas has a higher abstraction level than C, but in some areas can still be faster than C. (Due to usage of templates, whi

Then let's look at C++, which in some areas has a higher abstraction level than C, but in some areas can still be faster than C. (Due to usage of templates, which then inline the library code, which then can be optimized on actual types, rather than using library functions which use void pointers, which will require a function call and have a not as optimized compiled form. The main thing about python being slower is that in most contexts it is used as an interpreted/interpiled language running on its own VM in cpython.

ryao 1y ago
What you wrote about C versus C++ is largely untrue. C++ is not faster than C, even when “using library functions which use void pointers”. There is nothing about a void pointer that prevents inlining in either C or C++. There is also no “optimized on actual types” for C++ and not C, since everything is compiled into a low level intermediate language in the compiler (typically three-address code). All of the C++ types are absent at that point. The low level intermediate representation is then what receives optimization. For example, GCC will outright inline both bsearch() and the provided comparator in cases where it can see the definition of the comparator, such that there are no function calls done to either bsearch() or the comparator. C compilers will do this for a number of standard library functions and even will do it for non-library functions in the same file since they will inline small functions if allowed to do inlining. When the functions are not in the same file, you need LTO to get the inlining, but the same applies to C++. That said, I have never seen assembly output from a C++ compiler for C++ using C++ specific language features that was more succinct than equivalent C. I am sure it happens, but the C++ language is just full of bloat. C++ templates usually result in more code than less, since the compiler must work much harder to optimize the result and opportunities are often lost. It is also incredibly easy for overhead to be hiding in the abstractions, especially if you have a thread safe class used in a single threaded context as part of a larger multithreaded program. The compiler will not optimize the thread safety overhead away. You might not believe that C++ language features add bloat, so I will leave you with this tidbit: https://twitter.com/TimSweeneyEpic/status/1223077404660371456?s=20 https://twitter.com/TimSweeneyEpic/status/122307740466037145... Tim Sweeney’s team had C++ code that not only did not use exceptions, but explicitly opted out of them with noexcept. They got a 15% performance boost from turning off exceptions in the compiler, for no apparent reason. C, not having exceptions, does not have this phantom overhead.
- AlotOfReading 1y ago
  Noexcept doesn't mean "this function doesn't use exceptions", it means "this function doesn't throw exceptions". The difference being that a child function can throw, but std::terminate will be called once a noexcept function is unwound. There's no standard way to specify the former, only compiler flags. C++ can be used to write code that generates assembly equivalent to pretty much any C. A lot of standards committee work goes into ensuring that's possible. The trade-off is that it's the closest thing humans have ever produced to a lovecraftian programming language.
  - uecker 1y ago
    Yes, but you can not achieve faster code in C++ than you can also achieve in C and the use of templates or dynamic dispatch certainly can come with a cost. I would also argue than you can write similar abstractions also in C with very similar trade-offs. The difference is mostly that C has less syntactic sugar but everything is more obvious.
    - AlotOfReading 1y ago
      I'd love to see any examples you have of compile time metaprogramming libraries like Eigen or CTRE written instead in C. You can do a little of that with _Generic, but I'd generally prefer the nightmare that is templates to most of the hardcore macro magic I've encountered (e.g. Boost.PP), let alone constexpr.
      - uecker 1y ago
        I think this is asking the wrong question. In many case it would be smarter to implement these algorithms using high-level abstractions and then let the optimizer specialize it again. This works very well also in C:https://godbolt.org/z/bohvffd7r https://godbolt.org/z/bohvffd7r I use it a lot, but I am not aware about a public project similar to Eigen. I definitely convinced this could be done and would be very nice. One downside is that one might want to have more precise control. But even then there are solutions which IMHO are better than template metaprogramming.

ryao 1y ago

What you wrote about C versus C++ is largely untrue. C++ is not faster than C, even when “using library functions which use void pointers”. There is nothing about a void pointer that prevents inlining in either C or C++. There is also no “optimized on actual types” for C++ and not C, since everything is compiled into a low level intermediate language in the compiler (typically three-address code). All of the C++ types are absent at that point. The low level intermediate representation is then what receives optimization. For example, GCC will outright inline both bsearch() and the provided comparator in cases where it can see the definition of the comparator, such that there are no function calls done to either bsearch() or the comparator. C compilers will do this for a number of standard library functions and even will do it for non-library functions in the same file since they will inline small functions if allowed to do inlining. When the functions are not in the same file, you need LTO to get the inlining, but the same applies to C++. That said, I have never seen assembly output from a C++ compiler for C++ using C++ specific language features that was more succinct than equivalent C. I am sure it happens, but the C++ language is just full of bloat. C++ templates usually result in more code than less, since the compiler must work much harder to optimize the result and opportunities are often lost. It is also incredibly easy for overhead to be hiding in the abstractions, especially if you have a thread safe class used in a single threaded context as part of a larger multithreaded program. The compiler will not optimize the thread safety overhead away. You might not believe that C++ language features add bloat, so I will leave you with this tidbit: https://twitter.com/TimSweeneyEpic/status/1223077404660371456?s=20 https://twitter.com/TimSweeneyEpic/status/122307740466037145... Tim Sweeney’s team had C++ code that not only did not use exceptions, but explicitly opted out of them with noexcept. They got a 15% performance boost from turning off exceptions in the compiler, for no apparent reason. C, not having exceptions, does not have this phantom overhead.

AlotOfReading 1y ago
Noexcept doesn't mean "this function doesn't use exceptions", it means "this function doesn't throw exceptions". The difference being that a child function can throw, but std::terminate will be called once a noexcept function is unwound. There's no standard way to specify the former, only compiler flags. C++ can be used to write code that generates assembly equivalent to pretty much any C. A lot of standards committee work goes into ensuring that's possible. The trade-off is that it's the closest thing humans have ever produced to a lovecraftian programming language.
- uecker 1y ago
  Yes, but you can not achieve faster code in C++ than you can also achieve in C and the use of templates or dynamic dispatch certainly can come with a cost. I would also argue than you can write similar abstractions also in C with very similar trade-offs. The difference is mostly that C has less syntactic sugar but everything is more obvious.
  - AlotOfReading 1y ago
    I'd love to see any examples you have of compile time metaprogramming libraries like Eigen or CTRE written instead in C. You can do a little of that with _Generic, but I'd generally prefer the nightmare that is templates to most of the hardcore macro magic I've encountered (e.g. Boost.PP), let alone constexpr.
    - uecker 1y ago
      I think this is asking the wrong question. In many case it would be smarter to implement these algorithms using high-level abstractions and then let the optimizer specialize it again. This works very well also in C:https://godbolt.org/z/bohvffd7r https://godbolt.org/z/bohvffd7r I use it a lot, but I am not aware about a public project similar to Eigen. I definitely convinced this could be done and would be very nice. One downside is that one might want to have more precise control. But even then there are solutions which IMHO are better than template metaprogramming.