6 ms·

C, D, C++, rust, and nim should all have comparable performance; they all go through gcc|llvm, and all have the same optimizations. Rust and c++ may be slower

C, D, C++, rust, and nim should all have comparable performance; they all go through gcc|llvm, and all have the same optimizations. Rust and c++ may be slower in debug mode than their other-language counterparts, but the cost of abstractions goes away when optimizations are turned on (in exchange for drastically increased compile times). Java is not significantly more OO than C++; global-scope variables and functions in c++ are analogous to static ones in java. D's interop story is similar to nim. I don't know rust, but I believe it is said to be more expressive than c++. Honestly, I think all the judgements of dev time are a little bit misleading; iirc there were some studies showing that productivity is not significantly different across languages. Worth noting, though, is that D and Go compile really quickly.

totalperspectiv 7y ago
Your comment on dev time is something I intuitively agree with. And there are the future costs of dev time to add new features later / debug code etc. It's a poor measure at the end of they day. As to C/D/C++/Rust/Nim, what I think is interesting to see, is which ones lead you to the performant path naturally, vs having to really dig into the bowels of the language or go against the grain of the language, so to speak. I have not written enough of any of them to say which do this. I would hazard that Rust does the best job, due to its explicitness / very nature.
- earenndil 7y ago
  > I would hazard that Rust does the best job, due to its explicitness / very nature I might say the same about c, except even more so. As for 'the performant path', something to watch for there is jai, probably coming out later this year. It has clever things there, like dynamically switching between SOA and AOS, or doing small dynamic allocations on the stack.
  - totalperspectiv 7y ago
    I haven't looked at Jai. I'll have to check it out. I have looked at Zig, which seems to inhabit a similar space. They both seem a little too early days for me at the moment (I at least want a chance at using it $work), but I like the general idea of better C.
    - vips7L 7y ago
      D has a betterC flag [0]. Though at that point I'm not sure why you wouldn't just write c++17. [0] https://dlang.org/blog/2017/08/23/d-as-a-better-c/ https://dlang.org/blog/2017/08/23/d-as-a-better-c/
      - WalterBright 7y ago
        D's betterC includes the metaprogramming facilities.
        vips7L 7y ago
        And at the very least it has dub right? I've thought about it alot.
      - skocznymroczny 7y ago
        I'd love to use betterC more if it had dynamic arrays and assoc arrays. BetterC opens up opportunities such as WebAssembly too.
        earenndil 7y ago
        Webassembly is slowly (but carefully) deciding on a garbage collection spec of its own; once that's available, you should see a whole new slew of languages targeting it, including full-fledged d.
  - nicoburns 7y ago
    C does, until you start making things multithreaded, at which point you either start defensively copying things, or dev times slows massively due to having to maintain complex locking invariants in your head.
- WalterBright 7y ago
  > which ones lead you to the performant path naturally D's big advantage is the plasticity of the code, meaning it's much easier to try out different data structures and algorithms to compare speed. My experience with C and C++ is they're hard to change data structures, meaning one tends to stick with the initial design. For a smallish example, in C one uses s.f when s is a value of a struct, and s->f when s is a pointer to a struct. If you're switching from one to the other, you have to go through all your code swapping . and ->. With D, both are .
  - totalperspectiv 7y ago
    That's an excellent point. There was a neat paper a few years back where they were making the point that Java could actually lead to better performance in complex scenarios than c or c++ because the team could iterate on the algorithm faster and explore different paths.
    - riffraff 7y ago
      This is also the same claim that gets mentioned when k comes up: the shortness of programs leads to finding better solutions.
6thaccount2 7y ago
That doesn't make sense to me. You might not save much time when going from C++ to Rust, but what about C++ to Ruby or Python? There are things I can do with a few lines of code in Python that when I looked at how to do in lower level languages I just decided I could live with slower performance.
- jbay808 7y ago
  I do 95% of my dev work in Python so I'm quite biased in its favour. But I've seen literally 1000x speedups from transferring the numerical heavy lifting to C++, which paid back the time it took to rewrite that code in very short order and enabled us to do something that wasn't previously close to practical. I was pretty sure that the benefit would be closer 10x, but nope!
  - sametmax 7y ago
    1000x faster than numpy / scipy ?
    - 6thaccount2 7y ago
      Yea...were you using Numpy or just trying to do someyin base Python?
      - jbay808 7y ago
        I use numpy/scipy for everything I do by default, but not all operations can leverage it unfortunately. So what I mean is that the python program leveraged numpy to the greatest possible extent (that I know how), but was nonetheless 1000x slower than the C++ program that produced the same output. I am not making any claim that particular operations like summing up an array or doing an FFT is 1000x faster in C++ than in numpy. Of course it's not. In this case, numpy calls were certainly not the bottleneck, so it would be wrong to say "1000x faster than numpy". But it was, on the whole, 1000x faster than Python leveraging numpy.
petascale 7y ago
> iirc there were some studies showing that productivity is not significantly different across languages If it's the same studies I'm thinking of, the result was that productivity was about the same in all languages _when measured in lines of code per day_. So say 1k lines of assembler took the same time as 1k lines of Python. However, the higher level languages can _do_ more for the same number of lines.
- anfilt 7y ago
  there things were its the reverse though. Like if you maniplating things at the byte level you have play with packing and unpacking the data unless its a binary format aready undertood by python. Like for instance common steing encoding like utf8. Also if your calling native functions from python that expects structs as arguments its a bit annoying.
interfixus 7y ago
> Worth noting, though, is that D and Go compile really quickly In my experience, so does Nim. Yes, it's at two-step process, but the translation to c-code is blazingly fast, and the generated c is of the clean and straightforward kind which gcc or clang can handle in a highly efficient way.
nicwilson 7y ago
> C, D, C++, rust, and nim should all have comparable performance; For the same design; what sets fast code apart from slow code is the availability of designs enabled by the language. Compile time computation is a huge win for D (IIRC nim has similar capabilities).
xhgdvjky 7y ago
d is just such a pleasure. it's like it was designed to make the programmer happy. maybe that's not a reason to choose it, but it's a huge perk
- dvfjsdhgfv 7y ago
  My thoughts exactly. If I want to build something, I just do it, and I really enjoy it.
- vram22 7y ago
  >d is just such a pleasure. it's like it was designed to make the programmer happy. IIRC, Walter has said somewhere (likely on the D site or on his site or one of his articles for DDJ) that it was designed for that, actually, or something to that effect [1]. I've felt that myself while using it. I think he also said something like the code should look good on the page. I agree. [1] Or at least, make him happy :)
  - vram22 7y ago
    This subfeed of my blog has all my D language posts, about a dozen of them (apart from a few videos of D or related confs): https://jugad2.blogspot.com/search/label/DLang https://jugad2.blogspot.com/search/label/DLang They may be of interest to beginners or others wanting to get a bit of a feel for some of the kinds of things D can do, via simple command-line programs, along with checking the D site and tour at dlang.org .
- acehreli 7y ago
  It's a very important point that is often underrated. Programming is a human activity; the tool should make the human happy.
rahimiali 7y ago
Note that nim compiles to C, c++, objective C, or javascript, and not to llvm IR directly. Just because gcc or llvm are involved in the compilation process doesn't mean nim is as fast as C. cython, for example, compiles python to C but doesn't always match the performance of writing the code in native C.
- earenndil 7y ago
  Nim and cython are not analogous. Most notably, nim is statically typed, and identifiers are statically determinable. I don't say nim is as fast as (those other languages) because it compiles to c, but rather because that's what benchmarks show.
Sean1708 7y ago
> C, D, C++, rust, and nim should all have comparable performance; they all go through gcc|llvm, and all have the same optimizations. That's not necessarily true. For example language semantics (essentially how much information the optimiser has) such as whether mutable pointers are allowed to alias (or even the existence of non-mutable pointers) can play a huge role in what optimisations can be applied in a given situation and even how effective certain optimisations are. Also default behaviours like D, rust, and nim doing bounds-check can change the practical speed (although not necessarily theoretical speed) of a language. And finally things like garbage collectors can make certain languages faster in some cases but slower in others (again there's a practical vs theoretical argument here, since you could get similar speed-ups using other techniques). So no they don't necessarily have to have comparable performance, at least not in all situations.
- mhh__ 7y ago
  It's a completely meaningless comparison in practice. D's contract mechanism (i.e. in/out, and invariant blocks) can provide very strong guarantees to the compiler (as a specified part of the language as opposed to a GCC pragma/builtin), which the LLVM D compiler definitely uses. All of the on by defaults that D has are usually there for a reason, i.e. floats are NaN initialized and bounds checking is on by default: These are very good idiot-proofing which can often be ignored unless profiling suggests there is a tangible issue.
  - EvenThisAcronym 7y ago
    > D's contract mechanism [...] can provide very strong guarantees to the compiler... which the LLVM D compiler definitely uses. That's awesome. I didn't know LDC uses contracts like that. It'd be nice to have similar functionality across all D compilers.
nimmer 7y ago
> C, D, C++, rust, and nim should all have comparable performance No, Nim is often among the fastests, sometimes surpassing C. This is because it targets C by default and uses data structures and code paths that GCC can optimize very well.

totalperspectiv 7y ago

Your comment on dev time is something I intuitively agree with. And there are the future costs of dev time to add new features later / debug code etc. It's a poor measure at the end of they day. As to C/D/C++/Rust/Nim, what I think is interesting to see, is which ones lead you to the performant path naturally, vs having to really dig into the bowels of the language or go against the grain of the language, so to speak. I have not written enough of any of them to say which do this. I would hazard that Rust does the best job, due to its explicitness / very nature.

earenndil 7y ago
> I would hazard that Rust does the best job, due to its explicitness / very nature I might say the same about c, except even more so. As for 'the performant path', something to watch for there is jai, probably coming out later this year. It has clever things there, like dynamically switching between SOA and AOS, or doing small dynamic allocations on the stack.
- totalperspectiv 7y ago
  I haven't looked at Jai. I'll have to check it out. I have looked at Zig, which seems to inhabit a similar space. They both seem a little too early days for me at the moment (I at least want a chance at using it $work), but I like the general idea of better C.
  - vips7L 7y ago
    D has a betterC flag [0]. Though at that point I'm not sure why you wouldn't just write c++17. [0] https://dlang.org/blog/2017/08/23/d-as-a-better-c/ https://dlang.org/blog/2017/08/23/d-as-a-better-c/
    - WalterBright 7y ago
      D's betterC includes the metaprogramming facilities.
      - vips7L 7y ago
        And at the very least it has dub right? I've thought about it alot.
    - skocznymroczny 7y ago
      I'd love to use betterC more if it had dynamic arrays and assoc arrays. BetterC opens up opportunities such as WebAssembly too.
      - earenndil 7y ago
        Webassembly is slowly (but carefully) deciding on a garbage collection spec of its own; once that's available, you should see a whole new slew of languages targeting it, including full-fledged d.
- nicoburns 7y ago
  C does, until you start making things multithreaded, at which point you either start defensively copying things, or dev times slows massively due to having to maintain complex locking invariants in your head.
WalterBright 7y ago
> which ones lead you to the performant path naturally D's big advantage is the plasticity of the code, meaning it's much easier to try out different data structures and algorithms to compare speed. My experience with C and C++ is they're hard to change data structures, meaning one tends to stick with the initial design. For a smallish example, in C one uses s.f when s is a value of a struct, and s->f when s is a pointer to a struct. If you're switching from one to the other, you have to go through all your code swapping . and ->. With D, both are .
- totalperspectiv 7y ago
  That's an excellent point. There was a neat paper a few years back where they were making the point that Java could actually lead to better performance in complex scenarios than c or c++ because the team could iterate on the algorithm faster and explore different paths.
  - riffraff 7y ago
    This is also the same claim that gets mentioned when k comes up: the shortness of programs leads to finding better solutions.

6thaccount2 7y ago

That doesn't make sense to me. You might not save much time when going from C++ to Rust, but what about C++ to Ruby or Python? There are things I can do with a few lines of code in Python that when I looked at how to do in lower level languages I just decided I could live with slower performance.

jbay808 7y ago
I do 95% of my dev work in Python so I'm quite biased in its favour. But I've seen literally 1000x speedups from transferring the numerical heavy lifting to C++, which paid back the time it took to rewrite that code in very short order and enabled us to do something that wasn't previously close to practical. I was pretty sure that the benefit would be closer 10x, but nope!
- sametmax 7y ago
  1000x faster than numpy / scipy ?
  - 6thaccount2 7y ago
    Yea...were you using Numpy or just trying to do someyin base Python?
    - jbay808 7y ago
      I use numpy/scipy for everything I do by default, but not all operations can leverage it unfortunately. So what I mean is that the python program leveraged numpy to the greatest possible extent (that I know how), but was nonetheless 1000x slower than the C++ program that produced the same output. I am not making any claim that particular operations like summing up an array or doing an FFT is 1000x faster in C++ than in numpy. Of course it's not. In this case, numpy calls were certainly not the bottleneck, so it would be wrong to say "1000x faster than numpy". But it was, on the whole, 1000x faster than Python leveraging numpy.

petascale 7y ago

> iirc there were some studies showing that productivity is not significantly different across languages If it's the same studies I'm thinking of, the result was that productivity was about the same in all languages _when measured in lines of code per day_. So say 1k lines of assembler took the same time as 1k lines of Python. However, the higher level languages can _do_ more for the same number of lines.

anfilt 7y ago
there things were its the reverse though. Like if you maniplating things at the byte level you have play with packing and unpacking the data unless its a binary format aready undertood by python. Like for instance common steing encoding like utf8. Also if your calling native functions from python that expects structs as arguments its a bit annoying.

interfixus 7y ago

> Worth noting, though, is that D and Go compile really quickly In my experience, so does Nim. Yes, it's at two-step process, but the translation to c-code is blazingly fast, and the generated c is of the clean and straightforward kind which gcc or clang can handle in a highly efficient way.

nicwilson 7y ago

> C, D, C++, rust, and nim should all have comparable performance; For the same design; what sets fast code apart from slow code is the availability of designs enabled by the language. Compile time computation is a huge win for D (IIRC nim has similar capabilities).

xhgdvjky 7y ago

d is just such a pleasure. it's like it was designed to make the programmer happy. maybe that's not a reason to choose it, but it's a huge perk

dvfjsdhgfv 7y ago
My thoughts exactly. If I want to build something, I just do it, and I really enjoy it.
vram22 7y ago
>d is just such a pleasure. it's like it was designed to make the programmer happy. IIRC, Walter has said somewhere (likely on the D site or on his site or one of his articles for DDJ) that it was designed for that, actually, or something to that effect [1]. I've felt that myself while using it. I think he also said something like the code should look good on the page. I agree. [1] Or at least, make him happy :)
- vram22 7y ago
  This subfeed of my blog has all my D language posts, about a dozen of them (apart from a few videos of D or related confs): https://jugad2.blogspot.com/search/label/DLang https://jugad2.blogspot.com/search/label/DLang They may be of interest to beginners or others wanting to get a bit of a feel for some of the kinds of things D can do, via simple command-line programs, along with checking the D site and tour at dlang.org .
acehreli 7y ago
It's a very important point that is often underrated. Programming is a human activity; the tool should make the human happy.

rahimiali 7y ago

Note that nim compiles to C, c++, objective C, or javascript, and not to llvm IR directly. Just because gcc or llvm are involved in the compilation process doesn't mean nim is as fast as C. cython, for example, compiles python to C but doesn't always match the performance of writing the code in native C.

earenndil 7y ago
Nim and cython are not analogous. Most notably, nim is statically typed, and identifiers are statically determinable. I don't say nim is as fast as (those other languages) because it compiles to c, but rather because that's what benchmarks show.

Sean1708 7y ago

> C, D, C++, rust, and nim should all have comparable performance; they all go through gcc|llvm, and all have the same optimizations. That's not necessarily true. For example language semantics (essentially how much information the optimiser has) such as whether mutable pointers are allowed to alias (or even the existence of non-mutable pointers) can play a huge role in what optimisations can be applied in a given situation and even how effective certain optimisations are. Also default behaviours like D, rust, and nim doing bounds-check can change the practical speed (although not necessarily theoretical speed) of a language. And finally things like garbage collectors can make certain languages faster in some cases but slower in others (again there's a practical vs theoretical argument here, since you could get similar speed-ups using other techniques). So no they don't necessarily have to have comparable performance, at least not in all situations.

mhh__ 7y ago
It's a completely meaningless comparison in practice. D's contract mechanism (i.e. in/out, and invariant blocks) can provide very strong guarantees to the compiler (as a specified part of the language as opposed to a GCC pragma/builtin), which the LLVM D compiler definitely uses. All of the on by defaults that D has are usually there for a reason, i.e. floats are NaN initialized and bounds checking is on by default: These are very good idiot-proofing which can often be ignored unless profiling suggests there is a tangible issue.
- EvenThisAcronym 7y ago
  > D's contract mechanism [...] can provide very strong guarantees to the compiler... which the LLVM D compiler definitely uses. That's awesome. I didn't know LDC uses contracts like that. It'd be nice to have similar functionality across all D compilers.

nimmer 7y ago

> C, D, C++, rust, and nim should all have comparable performance No, Nim is often among the fastests, sometimes surpassing C. This is because it targets C by default and uses data structures and code paths that GCC can optimize very well.