Is C++ fast ?
| A library that I work on often these days, meshoptimizer, has changed over time to use fewer and fewer C++ library features, up until the current state where the code closely resembles C even though it uses some C++ features. |
https://zeuxcg.org/2019/01/17/is-c-fast/
I wonder what the experts here say about this approach.
Last edited on
It seems most of the performance improvement came from using a different hash table implementation and from omitting the vector pre-initialization. You can always improve performance by going from a more general to a less-general solution, because the special-purpose code will not do nothing you don't need. The particular language is incidental, as is the fact that the general-purpose solution came from the language's standard library.
/r/cpp discussed that link recently https://www.reddit.com/r/cpp/comments/aha5nn/is_c_fast/
The statement in that post that was closest to being right was "drawing more things on the screen changes how long things take, especially in 3D", and it still wasn't quite right.
I especially enjoyed that you used the word "change", like there might be a chance that drawing more things would take less time than drawing fewer things.
I especially enjoyed that you used the word "change", like there might be a chance that drawing more things would take less time than drawing fewer things.
closed account (367kGNh0)
i mean the more complex assets on the screen. the longer actions can take. Due to size
That's not necessarily true. What if there's vsync and you're doing everything within 10% of the frame time? Then you could multiply the complexity by 8 and the speed of the program would not change.
Is C++ fast ? |
It certainly can be. You can write "close to the hardware" code that runs about as fast as the CPU is capable of running.
It can also be used to create plodding dinosaurs of inefficiency.
It all depends on who's writing the code.
C++ *** is one of the fastest languages. Assembly is considerably faster but today's software is mostly too big to code in assembly, costs too much time/money/effort/etc. I can't think of anything higher level than assembly that is significantly faster in general. C is a mixed bag, with some things being faster and some slower, depending on what exactly it is you are doing. It is generally understood that C can be faster, at the cost of not having a large number of language tools that make large projects easier to write and maintain. Graphics is not a good test of the language, as graphics rely on hardware and third party libraries and there are a lot of weird things that happen in those outside the language wrapper.
***C++ to me means the whole language, arrays, pointers, c-strings, anything we can compile with a standard compiler is fair game, and personally I am not above nonstandard extensions that work (eg the union hack that works on all compilers but is technically undefined). I am not including inline assembly here, though that should be used in critical inner loops if proven necessary.
***C++ to me means the whole language, arrays, pointers, c-strings, anything we can compile with a standard compiler is fair game, and personally I am not above nonstandard extensions that work (eg the union hack that works on all compilers but is technically undefined). I am not including inline assembly here, though that should be used in critical inner loops if proven necessary.
Last edited on
| I can't think of anything higher level than assembly that is significantly faster in general. |
| ***C++ to me means the whole language, arrays, pointers, c-strings, anything we can compile with a standard compiler is fair game, and personally I am not above nonstandard extensions that work (eg the union hack that works on all compilers but is technically undefined). I am not including inline assembly here, though that should be used in critical inner loops if proven necessary. |
several languages can be faster in some scenarios, but generally, overall, consistently faster? that is what I meant. There are likely scenarios where most any compiled language has a shot at beating C++ for that specific thing. But when you go for general/overall, that falls way down.
---------
What about SIMD intrinsics?
Well, those are not terribly portable. I think I would classify them like the assembly. Use it, sure, but its a bit outside of the question.
---------
What about SIMD intrinsics?
Well, those are not terribly portable. I think I would classify them like the assembly. Use it, sure, but its a bit outside of the question.
| several languages can be faster in some scenarios, but generally, overall, consistently faster? |
I would agree with that.
It was designed for tight number crunching loops, after all.
I will honestly say I have no idea how well it can handle other kinds of tasks. I didn't use it much, and only for numerical work, and only old F77 style. I couldn't even give it a fair test, as I doubt I could squeeze the speed from the code like a pro in the language could. I would probably give it the C rating... slightly faster than c++ in places (esp object or stl heavy c++) at the cost of fewer built in tools.
It was designed for tight number crunching loops, after all.
I will honestly say I have no idea how well it can handle other kinds of tasks. I didn't use it much, and only for numerical work, and only old F77 style. I couldn't even give it a fair test, as I doubt I could squeeze the speed from the code like a pro in the language could. I would probably give it the C rating... slightly faster than c++ in places (esp object or stl heavy c++) at the cost of fewer built in tools.
Last edited on
I'm a novice when it comes to SIMD but I'm excited about the SIMD wrapper library that's part of the Parallelism 2 TS. It looks like it would make it easy to write portable SIMD code.
https://en.cppreference.com/w/cpp/experimental/simd
https://en.cppreference.com/w/cpp/experimental/simd
Topic archived. No new replies allowed.