celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GitBox <...@apache.org>
Subject [GitHub] [celix] Oipo commented on pull request #259: Feature/cxx
Date Fri, 17 Jul 2020 19:33:01 GMT

Oipo commented on pull request #259:
URL: https://github.com/apache/celix/pull/259#issuecomment-660300018

   ### is there any metric data regarding performance, code size etc - compared C and "new"
   The discussions surrounding language X vs language Y are always very difficult, because
are you really comparing apples to apples?
   In terms of C++ vs C performance, there are many huge differences in tiny places, but can
be explained easily if you dive into it. Generally speaking, for each run-time metric you
think of, what you can achieve in C, you can achieve in C++ and vice-versa. For example, C++'s
`std::sort` is faster than C's `qsort`. Not because C++ is faster, but because the underlying
algorithms are different. GCC's`std::sort` uses Musser's introsort where `qsort` uses quicksort
(though I haven't verified that one for GCC specifically). Hence, C++ seemingly has a speed
advantage here, which would disappear if the same algorithms were used.
   But really, for each engineering problem you solve with the same fundamental concepts in
C, you can get an exact assembly output copy with C++. Though that would often mean not using
exceptions, which would preclude many usages of the std library. But even for those situations,
people have made std-like [libraries](https://github.com/electronicarts/EASTL) to give many
of the same benefits, without using exceptions.
   Benchmarking C vs C++ most certainly has been done. See the [Benchmarking Game](https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/cpp.html),
this [C++17 specific paper](https://stellar.cct.lsu.edu/pubs/closing_perf_gap_isc_2016.pdf)
or one of the [many](https://www.r-bloggers.com/the-need-for-speed-part-2-c-vs-fortran-vs-c/),
[many](https://deathbytape.com/articles/2015/01/30/c-vs-c-performance.html) other publicly
available resources. In fact, [here](https://www.viva64.com/en/b/0733/) is one comparing rust
with C++, which comes to pretty much the same conclusion as I have: the same class of languages
perform the same. Rust, C and C++ are all systems-class languages where you manage your own
memory, giving very comparable performance results.
   Note that you'll find resources such as [this 2003 paper](http://citeseerx.ist.psu.edu/viewdoc/download?doi=
on the decrease of performance in C++, but in the 17 years since, C++ and the compilers for
C++ have advanced a lot. Take the constexpr feature of C++17 for example, [Jason Turner's
CppCon presentation](https://www.youtube.com/watch?v=PJwd4JLYJJY) shows that the compiler
can move a lot of computation from run-time to compile-time. I do not know of any C equivalent,
other than the pre-processor which is a partial equivalence at best.
   The questions surrounding run-time performance are therefore (in my not so humble opinion)
the least important surrounding the decision to move away from C.
   The right question should be:
   Which requirements do we have for celix and which language best fulfills those?
   Or alternatively, which requirements do we have for celix and does C still fulfill these
   I had already written a large reply on trying to answer that question, but I don't think
this is the right place to do it. I will say though that it is my strong personal belief that
using C for celix has introduced a lot of difficulty in implementing things bug-free and it
is noticeable by all the bugs we're continuously creating when adding new features.

This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:

View raw message