Hacker News Reader

Comment by earenndil | Hacker News Reader

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.

View on HN

> 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.

> 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).

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.

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.

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.

> 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 .

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.

This is also the same claim that gets mentioned when k comes up: the shortness of programs leads to finding better solutions.

> 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.

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.

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.

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/

D's betterC includes the metaprogramming facilities.

And at the very least it has dub right? I've thought about it alot.

I'd love to use betterC more if it had dynamic arrays and assoc arrays. BetterC opens up opportunities such as WebAssembly too.

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.

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

>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 :)

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

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 .

It's a very important point that is often underrated. Programming is a human activity; the tool should make the human happy.

My thoughts exactly. If I want to build something, I just do it, and I really enjoy it.

> 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.

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.

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.

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!

1000x faster than numpy / scipy ?

Yea...were you using Numpy or just trying to do someyin base Python?

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.

> 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.

> 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.

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.

> 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.

Reply on news.ycombinator.com