5 ms·

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

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
TheCoelacanth 5y ago
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.

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

TheCoelacanth 5y ago

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.