8 ms·

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 be

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.

capableweb 5y ago
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.
wyldfire 5y ago
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?
- TheCoelacanth 5y ago
  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.
  - dahfizz 5y ago
    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.
    - staticassertion 5y ago
      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.
      - dahfizz 5y ago
        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.
    - ModernMech 5y ago
      > There is no runtime C has a runtime, it's called the CRT (C Runtime). http://www.vishalchovatiya.com/crt-run-time-before-starting-main/ http://www.vishalchovatiya.com/crt-run-time-before-starting-... It's quite small, but it's there.
      - dahfizz 5y ago
        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.
        ModernMech 5y ago
        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 https://en.wikipedia.org/wiki/Java_processor
- abainbridge 5y ago
  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.
  - otherme123 5y ago
    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.
  - wyldfire 5y ago
    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.
- gameswithgo 5y ago
  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.
  - arc619 5y ago
    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.
ReleaseCandidat 5y ago
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).
- gameswithgo 5y ago
  C has fortran like performance =)
Rendello 5y ago
Zig as well.
- galangalalgol 5y ago
  I haven't seen a shootout like this with zig, is it comparable?
  - Rendello 5y ago
    Zig is as fast as C, occasionally faster.

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.

capableweb 5y ago

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.

wyldfire 5y ago

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?

TheCoelacanth 5y ago
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.
- dahfizz 5y ago
  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.
  - staticassertion 5y ago
    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.
    - dahfizz 5y ago
      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.
  - ModernMech 5y ago
    > There is no runtime C has a runtime, it's called the CRT (C Runtime). http://www.vishalchovatiya.com/crt-run-time-before-starting-main/ http://www.vishalchovatiya.com/crt-run-time-before-starting-... It's quite small, but it's there.
    - dahfizz 5y ago
      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.
      - ModernMech 5y ago
        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 https://en.wikipedia.org/wiki/Java_processor
abainbridge 5y ago
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.
- otherme123 5y ago
  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.
- wyldfire 5y ago
  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.
gameswithgo 5y ago
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.
- arc619 5y ago
  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.

ReleaseCandidat 5y ago

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

gameswithgo 5y ago
C has fortran like performance =)

Rendello 5y ago

Zig as well.

galangalalgol 5y ago
I haven't seen a shootout like this with zig, is it comparable?
- Rendello 5y ago
  Zig is as fast as C, occasionally faster.