Hacker News Reader

Comment by capableweb | Hacker News Reader

> That's kind of expected right?

I'm not sure. The following claim is being made on Nim's website:

> Modern concepts like zero-overhead iterators and compile-time evaluation of user-defined functions, in combination with the preference of value-based datatypes allocated on the stack, lead to extremely performant code.

> Efficient, expressive, elegant

> Nim is a statically typed compiled systems programming language

A systems programming language need to have exceptionally good performance, so not sure it's to be expected that the performance is so different than Rust.

Apparently the Rust versions have received more optimization efforts compared to the Nim code as well, and it seems some people are working on optimizing the Nim versions so we'll see where it lands in the future I guess: https://news.ycombinator.com/item?id=30244188

View on HN

>Apparently the Rust versions have received more optimization efforts compared to the Nim code as well

Having programmed in both I think Rust often makes it easier to write fast code by making all the copying vs borrowing more explicit.

Nim is obviously still very fast and much easier to pick up, so there are trade-offs here.

I've been programming for like 30 years and I've seen dozens of language show up claiming "C like performance" and so far Rust is the only one where that has been true.

Indeed, probably the most overused selling pitch for programming languages has to be "C like performance", while only providing evidence for a few smaller use cases. I've only dabbled with Rust enough to grok the ownership parts, but I'm happy to hear you feel it lives up to that.

As an aside, I'm not expecting a lot of languages to live up to the "C like performance" claim when they make it, as C has been receiving optimizations for over 50 years by now, so it makes sense it's still the fastest around, at least until there is some major breakthrough in programming language design.

But Nim uses a C backend, right? So this should put it in a good position to compare well with C, I'd assume.

EDIT: Downvoters - is that not the case?

No. By that logic, all languages should have equivalent performance because they all ultimately turn into machine code.

C isn't inherently fast, commonly used constructs in C just tend to match up well with semantics that can be turned into high-performance machine code. For a language that compiles to C to be fast, its commonly used constructs would need to have semantics that match up well with what can be turned into high-performance C, which is often not the case. There are many examples of languages that compile to C, but are still very slow.

I would argue that C is inheritance fast. C puts the least amount of shit between the code and the CPU. There is no runtime, GC, expensive abstractions, etc. Your code more or less directly becomes machine code and is executed.

Maybe a better way to frame it is that most other languages are inherently slow. Garabge collection will always be slower than non-GC. JIT and interpreted languages will always be slower than ahead-of-time compiled languages. etc etc.

The point is that C isn't inherently fast ie: by simple virtue of translating a program from one language to C you are not producing a faster program. x86 has the least amount of shit between the code and the cpu, but we can see that many programs that compile to x86 are not fast.

That is a fair point, and looking back I misread the context of the comment I replied to. You should not expect free performance gains from transpiling to C.

> There is no runtime

C has a runtime, it's called the CRT (C Runtime).

http://www.vishalchovatiya.com/crt-run-time-before-starting-...

It's quite small, but it's there.

Maybe I should have put a disclaimer in my comment to stave off this kind of reply.

I am well aware of the CRT. I don't think its worth mentioning because it is a "run time" in name only. It literally doesn't do anything at run time. The only thing crt0 does is call your main(). From that point on, only your actual code is executing.

Contrast with Java or Python, where your code is executing inside a runtime which eats up cpu cycles at runtime.

I'm confused, if the CRT doesn't do anything at runtime except to call main(), how does argv get onto your program's stack? :P

Look, I get what you're saying, but it's not exactly relevant here. Yes, after your C program is loaded, execution follows by just moving the PC to the next instruction in the loaded binary. In C, adding two integers can be compiled down to a concise, machine supported operation; whereas in a language like Python, adding two numbers is a branch-heavy operation that cannot be compiled to a concise instruction ahead of time, so it must be interpreted at runtime. That's true. But that's really more about C being a compiled language than whether or not it has a runtime.

For an example of a runtime-heavy language that can compile highly performant code, see Julia. Thanks to dynamic dispatch, you get the best of both worlds. Yes you pay a heavy upfront cost (TTFP), but it's the same deal with compiling code -- pay once upfront, benefit forever with improved runtime performance.

You used Java as an example of a runtime-heavy language, but I think Java demonstrates why C should be considered as having a runtime, regardless of how small it is. Imagine a hardware Java Processing Unit (JPU), which is a CPU that has Java byte code for machine code [1]. I don't see why it wouldn't be possible to handle all of the stuff the JRE does in the OS, and everything the JVM does in the JPU. Then we could say that Java has no runtime. But really all we've done is taken the runtime and moved it to another place.

You could also imagine a version of C which compiles to CBC (C byte code) and runs on a CVM (C virtual machine), which itself runs on the JPU. You could write C code as usual, but the resulting binary would be compiled to CBC, and would have to run through a number of layers before it is executed on the JPU. Then could we say Java is an inherently fast language, and C is necessarily slower because it has a runtime? Maybe in this strange reality, but it's not necessarily the case. And it certainly has nothing to do with the languages per se, but their implementations on specific hardware/software platforms.

Or to get even crazier with it, we could imagine a version of Java which compiles directly to x86 machine code, because why not? There's no reason that should be slower than C.

Anyway, I think the point is that whether or not one considers a language to have a runtime depends very much on how a language is compiled, what hardware it's targeting, and how much you're able to leverage the OS (there's usually a lot of leverage available when the OS itself is written in the language you're using). So really, all languages have a runtime, it's just a matter of where it's hiding.

[1] https://en.wikipedia.org/wiki/Java_processor

> So really, all languages have a runtime, it's just a matter of where it's hiding.

Your definitions are meaningless. You may as well also say that all languages are garbage collected, since the C programmer must call `free` one way or another (or not, and let the OS be the garbage collector at cleanup).

By everyone's understanding of the words, C does not have a runtime nor garbage collection. Java does have a runtime and garbage collection. You can play with definitions and hypotheticals; it does not change the facts.

> By everyone's understanding of the words, C does not have a runtime

What? But we both just agreed it did.

The way I understand these words are that C is a language, and a language is different from its implementation, and implementation is dependent on hardware. I understand that a runtime is code that runs when a program starts, in order to enable its execution. Is this not your understanding?

Let me put it this way: if C is inherently fast as you, why can you take the same C source, put it into two different compilers, and get two different binaries with different performance profiles?

The answer is because the language itself has no bearing on speed, and it all comes down to how a language is compiled. So I still wouldn't say C is inherently fast, but I would say that C's design lends itself to compiling fast binaries for Von Neumann style machines. That of course doesn't preclude compiling just-as-fast or even faster binaries from other languages, e.g. Rust or C++.

> You can play with definitions and hypotheticals; it does not change the facts.

I'm not playing with hypotheticals. JPUs are a thing; I linked to the Wiki page. Natively compiled Java is basically GraalVM: https://www.graalvm.org, which I think pretty much proves the point -- it all comes down to the compiler. Garbage checking is also an implementation detail. You can even run a garbage collector for C if you want.

I have to back up ModernMech here. C with -O0 is not very fast on any compiler that has it (by design) which is most. Nor is the output of barely optimizing compilers like tinycc/tcc. Saying "C is inherently fast" is very naive.

Moreover, it is also untrue on the other side of this axis - you can often go much faster. Even with -Ofast or -Omax or whatever there are still (often) opportunities for SIMD vectorization on modern machines that autovec cannot find. Most C compilers provide (not really standardized) escape hatches to assembly in various ways for that last 2..64X speed-up (single thread). (Yes, avx512/8-bits=64 wide vectors these days.)

Finally, whether it "has a runtime" in the sense of automatic memory management, well, that just depends upon how you link programs. Link with -lboehm and you can never free (and, yes, allocations become potentially expensive). These Rust conversations are unfortunately prone to absolutist statements that indicate very narrow exposure.

[1] https://en.wikipedia.org/wiki/Boehm_garbage_collector

It's not inherently fast. It puts up few barriers that prevent the user from writing a fast program, but it's still on the user to write a program that is actually fast.

If your language has semantics that are difficult to translate into fast C, then your language isn't going to be fast just by going through C.

I wouldn't have down voted this comment, but I guess people are objecting because using C as the backend doesn't really tell us anything about performance. If the C code the Nim compiler generates is inefficient, the resulting program will still be slow. I imagine it is difficult to convert a Nim program into efficient C.

E.g. the Json interface of the Nim stdlib is not the quickest, but there are some third party libraries, 100% Nim, really fast (jsony). A look a both reveals that the problem is not the Nim compiler, but the algorithm used and intended usage.

I tried to qualify it "should put it in a good position" but I guess I wasn't handwavy enough. Indeed, the C code could be inefficient. But, for example, nim uses a C backend unlike Python which interprets bytecode.

It could, but at the moment it puts a garbage collector in there, though there are modes where you can turn that off. I haven't used Nim in a while so I don't know what the implications of disabling GC are at the moment.

With noting that the GC in Nim (not "stop the world" BTW) is attached to the type. Unless you declare a type as `ref`, you're using stack allocation.

Even if you do use the GC, the compiler elides GC work if the type doesn't escape the scope.

You should have heard of 'Fortran', the language that had C like performance before C even existed ;).

But no, Fortran is not an alternative to C (und vice versa).

C has fortran like performance =)

Zig as well.

I haven't seen a shootout like this with zig, is it comparable?

Zig is as fast as C, occasionally faster.

Reply on news.ycombinator.com