4 ms·

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

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

ModernMech 5y ago
> 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 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.
- cb321 5y ago
  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 https://en.wikipedia.org/wiki/Boehm_garbage_collector

ModernMech 5y ago

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

cb321 5y ago
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 https://en.wikipedia.org/wiki/Boehm_garbage_collector