91–100 of 119 posts
Actually, for example looking at the winningest programs for x64 single core (http://benchmarksgame.alioth.debian.org/):
Ada: 1, C: 5, C++: 2, Fortran: 1, Haskell: 1, Java: 2, Javascript: 1
So plain C is only winningest in 5/12 = 38%, and C/C++ in 7/13 = 54%.
Earlier quoted context omitted.
I guess I will be your essay-writing dissenter. C is a high-level language with fewer features than many other languages, is not necessarily the engine behind other languages, has the problem of its programs poorly implementing a percentage of what other high level languages are capable of doing quickly and securely, and provides slow and troublesome memory allocation out-of-the-box. When comparing the speed of opera…
> Let's be honest: C is no "closer to the metal" than other high level languages This is dead wrong, and your links do not support it. This is exactly the kind of statement that gets me grumpy. Your link illustrates that an aggressive C optimizer can collapse a chunk of C code down to something smaller and simpler than the original code. This is true. But what you said is that C is "no closer to the metal" than other…
camlAdd__plus2_1030:
.L100:
addq $4, %rax
ret
Earlier quoted context omitted.
> Let's be honest: C is no "closer to the metal" than other high level languages This is dead wrong, and your links do not support it. This is exactly the kind of statement that gets me grumpy. Your link illustrates that an aggressive C optimizer can collapse a chunk of C code down to something smaller and simpler than the original code. This is true. But what you said is that C is "no closer to the metal" than other…
The equivalent `plus2` OCaml function compiles to: camlAdd__plus2_1030: .L100: addq $4, %rax ret (It's using 4 instead of 2, because ints are boxed; a 0 in the last bit denotes an int, a 1 denotes an address).
Earlier quoted context omitted.
> Let's be honest: C is no "closer to the metal" than other high level languages This is dead wrong, and your links do not support it. This is exactly the kind of statement that gets me grumpy. Your link illustrates that an aggressive C optimizer can collapse a chunk of C code down to something smaller and simpler than the original code. This is true. But what you said is that C is "no closer to the metal" than other…
Apples and oranges yet again. The original article is about Haskell; an entirely different beast from Python. Haskell compiles down to machine code, not byte code.
But even Haskell is not as "bare metal" as C. Just because a language can compile to machine code doesn't mean it fills the same role that C does.
Earlier quoted context omitted.
I guess I will be your essay-writing dissenter. C is a high-level language with fewer features than many other languages, is not necessarily the engine behind other languages, has the problem of its programs poorly implementing a percentage of what other high level languages are capable of doing quickly and securely, and provides slow and troublesome memory allocation out-of-the-box. When comparing the speed of opera…
> Let's be honest: C is no "closer to the metal" than other high level languages This is dead wrong, and your links do not support it. This is exactly the kind of statement that gets me grumpy. Your link illustrates that an aggressive C optimizer can collapse a chunk of C code down to something smaller and simpler than the original code. This is true. But what you said is that C is "no closer to the metal" than other…
Those functions maybe similar but they are not equivalent.
Earlier quoted context omitted.
I guess I will be your essay-writing dissenter. C is a high-level language with fewer features than many other languages, is not necessarily the engine behind other languages, has the problem of its programs poorly implementing a percentage of what other high level languages are capable of doing quickly and securely, and provides slow and troublesome memory allocation out-of-the-box. When comparing the speed of opera…
> Let's be honest: C is no "closer to the metal" than other high level languages This is dead wrong, and your links do not support it. This is exactly the kind of statement that gets me grumpy. Your link illustrates that an aggressive C optimizer can collapse a chunk of C code down to something smaller and simpler than the original code. This is true. But what you said is that C is "no closer to the metal" than other…
For example today it is quite possible to have Javascript OO code that runs more efficiently than, say, calling through structs of function pointers in C, since modern compilers have morphed into such strange runtime beasts that they can make (and test at runtime for) stronger assumptions about the contents of those pointers than a traditional compiler ever could. Where an indirect call in a traditional C compiler will only ever be at best "CALL [rax]" (assuming no indirection required to implement dynamic linking), newer implementations might inline the called function entirely, all dependent on what input the program happens to have been fed on a particular run.
This trend is why I'm not certain of the odds for less expressive languages in medium term. Instead of a struct of function pointers, imagine an inheritance chain of structs of function pointers. Although it can be implemented in C it is a native concept in Javascript, and one that compilers can already optimize. While the JS compiler has explicit information fundamental to the language to infer this structure from (and version any dependent objects to implement a runtime guard), we aren't nearly at the point where our compilers can deduce such an idiom in C or assembly, optimize for it, or solve a huge satisfiability problem at runtime in order to produce guards for it.
It naturally follows that the more semantic information a compiler has available to it, the better chance, at least in the medium term (10-20 years?) it has of applying tractable optimizations.
Earlier quoted context omitted.
> Let's be honest: C is no "closer to the metal" than other high level languages This is dead wrong, and your links do not support it. This is exactly the kind of statement that gets me grumpy. Your link illustrates that an aggressive C optimizer can collapse a chunk of C code down to something smaller and simpler than the original code. This is true. But what you said is that C is "no closer to the metal" than other…
Seconded. I'd add that languages like Python hide an enormous amount of not-close-to-the-metal-ness in every single statement, because every single statement has the implicit context "Interpreter, please interpret this string relative to your potentially complex internal state". Haskell is only slightly less prone to this, despite being compiled, since every expression by default becomes a request to instantiate a th…
In particular, what would it look like if you were avoiding instantiating thunks?
Earlier quoted context omitted.
But a JIT can perform such optimizations. Which doesn't help Haskell, but may help JavaScript or Lua beat C in some cases.
I'm doubtful that a JIT could realistically adapt its output based on runtime performance metrics, but if you have links I'd love to read more.
These "faster than C" claims are almost always embarrassing (usually involving C code that would easily win if it were as aggressively optimized as the high-level language) but that's almost not the point. The real point is the larger narrative. The subtext of these posts is what we are really arguing about. So let's just duke that out directly. High-level language fans have a point, which is that high-level language…
I guess I will be your essay-writing dissenter. C is a high-level language with fewer features than many other languages, is not necessarily the engine behind other languages, has the problem of its programs poorly implementing a percentage of what other high level languages are capable of doing quickly and securely, and provides slow and troublesome memory allocation out-of-the-box. When comparing the speed of opera…
"And contrary to what is spattered on the boards, C is not an understandable, close-to-the-metal wrapper around assembly instructions (compilers have advanced quite a bit)"
Yes, it isn't BUT it is (due to compilers supporting) the language where you can drop down to assembler or something closer to it: http://msdn.microsoft.com/en-us/library/26td21ds(v=vs.80).as... in the easiest way