4 ms·

Of course the C language and compilers are so simple, and C sits at such a low level (right above assembly) that few things can go wrong in it (compiler bug) or

by mrb 14y ago

Of course the C language and compilers are so simple, and C sits at such a low level (right above assembly) that few things can go wrong in it (compiler bug) or under it (cpu bug). As people jokingly say, C is just a high level assembly language. If one tried to re-invent a language with C's properties, one would come up with C, again. For these reasons, I too expect C to remain the most performant and reliable high-level language baring any major change in computer architectures. Debating this fact would be the same as debating whether assembly is the most performant and reliable low-level language or not. Of course it is. (Preemptive reply to the doubter: as an example my 64-bit assembly implementation of MD5 is 75% faster that a 64-bit C implementation: http://www.zorinaq.com/papers/md5-amd64.html http://www.zorinaq.com/papers/md5-amd64.html ) And of course, performance and reliability don't always need to be #1 priorities, therefore, as the author says, "most every popular language has uses where it's a better choice."

jzwinck 14y ago
Computer architecture has already changed, with today's PCs having many logical processors. And indeed C lacks any direct affordance for parallelism. Good old pthreads are hardly adequate for many tasks compared to facilities in other languages. Yes, you can implement most of the needed features in C, but often without the grace or safety available elsewhere.
- pbsd 14y ago
  C11 adds thread and atomic op support: https://en.wikipedia.org/wiki/C11_%28C_standard_revision%29 https://en.wikipedia.org/wiki/C11_%28C_standard_revision%29
- mrb 14y ago
  Perhaps you are right. Perhaps a technological advance in compilers and languages so deep as to dislodge C is needed to fully solve the ease of programming of many-core computers... Something the industry has been trying to achieve for more than a decade.
abecedarius 14y ago
Part of its apparent inevitability now comes from its influence. Bliss was a reasonable competitor at the time with significant differences: expression-oriented, reducible control flow, immutable variables (you used something like ML's refs when you needed assignment, but stack-allocated). C started simple, but grew kind of complex. I'd like to have an ubiquitous simple mid-level language.
betterunix 14y ago
"Debating this fact would be the same as debating whether assembly is the most performant and reliable low-level language or not." Discounting special CPU features that are hard for compilers to utilize (e.g. AESNI instructions in newer Intel CPUs), I think this is really a matter of scale. For small functions like MD5, hand-tuned assembly language is probably going to be faster than what a compiler generates. Likewise, for short, tight loops that are the bottleneck, hand-tuned assembly may be faster (you see that sort of thing in game engines). Beyond a certain point, though, compilers are going to outperform even the best humans; compilers are just better at keeping track of things across large areas of code. Compilers are also going to do a lot better when they have higher-level information available. You could conceivably write an x86 assembly optimizing tool (I suspect someone will point one out) if you wanted to, but even the best such tool will lose to a good C compiler. At the very least, your C compiler knows something about types, which can help a lot with optimizing; your C compiler also gets information about the purpose of certain sequences of instructions and how various control structures relate to various types, in ways that are hard to extract from assembly language. Of course, this argument can be taken a step further: a good compiler for a high level language should be able to do even better than a good C compiler at a large enough scale. While it is conceivable that you could do anything in C that a high-level language compiler does automatically, that just brings us back to the issue of whether or not compilers can outperform humans -- and again, at a large enough scale, that is going to be the case (of course, comparisons are difficult; higher-level languages are used for things that C is rarely used for, and we could debate endlessly about why that is the case).
- spc476 14y ago
  SynthesisOS (http://valerieaurora.org/synthesis/SynthesisOS/ http://valerieaurora.org/synthesis/SynthesisOS/) used an optimizing assembler to recompile the operating system on the fly (think of it as the OS being JITed). The reason it had to use an optimizing assembler is because the operating system itself was written in assembler (MC68030). It could run SunOS binaries faster than SunOS on the same hardware. And this was done back in 1992, when the major debate was Assembler vs. C (back when C was considered "high level").
bcoates 14y ago
Forth and Fortran would like to have a word with you :) But seriously, I would expect the maximum possible performance on today's architectures to come from the infamous sufficently smart compiler that can do bytecode generation at runtime. That can at least in theory produce programs faster than any system restricted to ahead-of-time operations, including handwritten AOT assembly. Whatever language can make that practical without having some other crippling performance issue might be able to consistently leave C and every other AOT language in the dust.
- naveen99 14y ago
  I love the ideas of forth, have been toying around with them in factor of factorcode.org recently. How many resources should that smart compiler be able to use ? The problems of optimization become important when you are about to run out of resouces... If you are out of resources, why would you leave some for the compiler ?
rayiner 14y ago
That's not really true. If I were designing a low-level language I wouldn't go for "it's just a really fast PDP-11" C. I'd pick something with programmable syntax and Lisp-style macros, because being able to generate code at compile time is a huge boon if you're writing something performance intensive. C++ BLAS libraries use this to good effect to partially-evaluate things using the template mechanism, but that's just a small bit of what's possible with proper metaprogramming.
- harryh 14y ago
  Hi. This comment has nothing to do with the actual post. I saw tptacek recommend your HN comments here: https://twitter.com/tqbf/status/292100038367277056 https://twitter.com/tqbf/status/292100038367277056 I just read a bunch of your comments and I agree with his assessment. You seem smart and interesting and apparently work in Manhattan. If you'd ever like to get a beer after work and shoot the shit about whatever I always like meeting interesting folks who are outside of my normal sphere of existence. My contact info is in my HN profile. Hopefully you will actually see this.

by mrb 14y ago

jzwinck 14y ago

Computer architecture has already changed, with today's PCs having many logical processors. And indeed C lacks any direct affordance for parallelism. Good old pthreads are hardly adequate for many tasks compared to facilities in other languages. Yes, you can implement most of the needed features in C, but often without the grace or safety available elsewhere.

pbsd 14y ago
C11 adds thread and atomic op support: https://en.wikipedia.org/wiki/C11_%28C_standard_revision%29 https://en.wikipedia.org/wiki/C11_%28C_standard_revision%29
mrb 14y ago
Perhaps you are right. Perhaps a technological advance in compilers and languages so deep as to dislodge C is needed to fully solve the ease of programming of many-core computers... Something the industry has been trying to achieve for more than a decade.

abecedarius 14y ago

Part of its apparent inevitability now comes from its influence. Bliss was a reasonable competitor at the time with significant differences: expression-oriented, reducible control flow, immutable variables (you used something like ML's refs when you needed assignment, but stack-allocated). C started simple, but grew kind of complex. I'd like to have an ubiquitous simple mid-level language.

betterunix 14y ago

"Debating this fact would be the same as debating whether assembly is the most performant and reliable low-level language or not." Discounting special CPU features that are hard for compilers to utilize (e.g. AESNI instructions in newer Intel CPUs), I think this is really a matter of scale. For small functions like MD5, hand-tuned assembly language is probably going to be faster than what a compiler generates. Likewise, for short, tight loops that are the bottleneck, hand-tuned assembly may be faster (you see that sort of thing in game engines). Beyond a certain point, though, compilers are going to outperform even the best humans; compilers are just better at keeping track of things across large areas of code. Compilers are also going to do a lot better when they have higher-level information available. You could conceivably write an x86 assembly optimizing tool (I suspect someone will point one out) if you wanted to, but even the best such tool will lose to a good C compiler. At the very least, your C compiler knows something about types, which can help a lot with optimizing; your C compiler also gets information about the purpose of certain sequences of instructions and how various control structures relate to various types, in ways that are hard to extract from assembly language. Of course, this argument can be taken a step further: a good compiler for a high level language should be able to do even better than a good C compiler at a large enough scale. While it is conceivable that you could do anything in C that a high-level language compiler does automatically, that just brings us back to the issue of whether or not compilers can outperform humans -- and again, at a large enough scale, that is going to be the case (of course, comparisons are difficult; higher-level languages are used for things that C is rarely used for, and we could debate endlessly about why that is the case).

spc476 14y ago
SynthesisOS (http://valerieaurora.org/synthesis/SynthesisOS/ http://valerieaurora.org/synthesis/SynthesisOS/) used an optimizing assembler to recompile the operating system on the fly (think of it as the OS being JITed). The reason it had to use an optimizing assembler is because the operating system itself was written in assembler (MC68030). It could run SunOS binaries faster than SunOS on the same hardware. And this was done back in 1992, when the major debate was Assembler vs. C (back when C was considered "high level").

bcoates 14y ago

Forth and Fortran would like to have a word with you :) But seriously, I would expect the maximum possible performance on today's architectures to come from the infamous sufficently smart compiler that can do bytecode generation at runtime. That can at least in theory produce programs faster than any system restricted to ahead-of-time operations, including handwritten AOT assembly. Whatever language can make that practical without having some other crippling performance issue might be able to consistently leave C and every other AOT language in the dust.

naveen99 14y ago
I love the ideas of forth, have been toying around with them in factor of factorcode.org recently. How many resources should that smart compiler be able to use ? The problems of optimization become important when you are about to run out of resouces... If you are out of resources, why would you leave some for the compiler ?

rayiner 14y ago

That's not really true. If I were designing a low-level language I wouldn't go for "it's just a really fast PDP-11" C. I'd pick something with programmable syntax and Lisp-style macros, because being able to generate code at compile time is a huge boon if you're writing something performance intensive. C++ BLAS libraries use this to good effect to partially-evaluate things using the template mechanism, but that's just a small bit of what's possible with proper metaprogramming.

harryh 14y ago
Hi. This comment has nothing to do with the actual post. I saw tptacek recommend your HN comments here: https://twitter.com/tqbf/status/292100038367277056 https://twitter.com/tqbf/status/292100038367277056 I just read a bunch of your comments and I agree with his assessment. You seem smart and interesting and apparently work in Manhattan. If you'd ever like to get a beer after work and shoot the shit about whatever I always like meeting interesting folks who are outside of my normal sphere of existence. My contact info is in my HN profile. Hopefully you will actually see this.