It's true that for extremely simple programs like the author's sole microbenchmark, non-C languages can get a speed boost over C from reasoning about aliasing. But this doesn't scale. The author's argument breaks down as soon as you ask for an example benchmark that is larger and smells like something real.
The “C Is Efficient” Language Fallacy (2006)
61–70 of 106 posts
Re: The “C Is Efficient” Language Fallacy (2006)
#62Did someone just insult the blessed C? Oh noes!!!
Re: The “C Is Efficient” Language Fallacy (2006)
#63An underlying point to this article that is still true is that C isn't inherently fast -- you have to work together with the compiler to make sure it generates what you want. Why is this even worth pointing out? Well, in many languages communities (Common Lisp is a good example), the speed argument comes up, and it's pointed out that carefully working with the compiler (declares in all the right places and so on) mak…
I imagine this is why so many game studios choose to use a mix of the two. C or C++ is used to write the engine code, which is kept just as simple as possible and is in charge of doing all the fiddly bits with the hardware. Unless you're on an embedded system with limited resources though (where the size of your code can actually matter) everything else is usually done in some sort of scripting language with its own…
Yeah, but there is no "fast JIT" on iOS and PS4 (not sure about X1) at least because they forbid creating memory pages with "Executable" bit, so usually AOT compilation is still ftw in game dev.
Re: The “C Is Efficient” Language Fallacy (2006)
#64Reeks of an anti-C bias. This comment by the author is flat out wrong, and I quote:
""" `int x[1000]` in C or C++ doesn’t have much meaning. It’s semantically equivalent to declaring “x” as `int *x`. You can reassign X any time you want, to make it point to a different location. """
C is also a pretty different language style-wise than C++. Aside from that, they're both good languages for building runtimes since their memory model resembles physical memory and they can run in an unhosted (runtime-less) environment.
Just a childish rant really.
Re: The “C Is Efficient” Language Fallacy (2006)
#65> In C and C++, there’s no such thing as an array – there’s just pointers, which you can subscript and a shorthand for pointer arithmetic and indirection
This is fallacy #1 about C. C does have arrays which constitute a contiguously allocated piece of memory, it's just that the identifier decays to a pointer in most contexts. When dealing with arrays, there is no indirection involved.
Re: The “C Is Efficient” Language Fallacy (2006)
#66This article's formatting is awful and very distracting.
Re: The “C Is Efficient” Language Fallacy (2006)
#67> In C and C++, there’s no such thing as an array – there’s just pointers, which you can subscript and a shorthand for pointer arithmetic and indirection This is fallacy #1 about C. C does have arrays which constitute a contiguously allocated piece of memory, it's just that the identifier decays to a pointer in most contexts. When dealing with arrays, there is no indirection involved.
He's obviously making comparisons to Fortran's arrays, which would be equivalent to using `restrict` for pointers (in addition to passing the size). This enables some compiler optimizations that can't be done if there is aliasing (ie. two pointers pointing to overlapping areas of memory).
In other words, this claim in the original article is incorrect: "But there's no way to write code in C or C++ that guarantees that. "
Re: The “C Is Efficient” Language Fallacy (2006)
#68Earlier quoted context omitted.
>> This post is nothing more than "I did this and look at the results" but offers nothing for us to repeat his tests. That's a valid gripe to have, but it should be said that most scientific papers that report simulation or algorithm results do exactly the same . Reproducing results is totally left to whomever feels like (and has the time to) dispute the claims. Which is why you don't often see much in the way of dis…
But scientific papers aren't comparing Language X v.2.7.5 vs Language Y v. 16.9.1. They're comparing Algorithm X vs Algorithm Y, and usually also give theoretical results. Unless there is a big dramatic change in computer hardware, results comparing some algorithms using good implementations in a single well-optimized language will likely stand the test of time well.
No, because the comparisons are usually "baseline version of algorithm I want to beat" vs "highly optimized and hand-tweaked version of the algorithm I have a vested interest in."
Re: The “C Is Efficient” Language Fallacy (2006)
#69Ehhhhh.... I can't help but think that it's never completely necessary to use totally unrestricted pointers in 'C'. Might be convenient, but very nearly certainly not necessary. Even in systems calls and library functions, it's possible to never dereference a pointer in an unconstrained manner. But you have to be prepared to reason rigorously about those constraints. Noting that the semantics of array access semi-equ…
You can't pass an array to a procedure without it becoming a pointer. But that is not even the issue ... the issue is that even if you know something is an array, any pointer of any type could be pointing anywhere into the interior of that array.
Re: The “C Is Efficient” Language Fallacy (2006)
#70Earlier quoted context omitted.
Fortran is still used in Physics. They have a lot of libraries, and they usually have a some program of a previous paper that almost do what they want now, and they know the technology stack, so many physicist are still not planning to change. (I work with a Physics group. Sometimes I found programs with an old part that still use numbered lines for the "do". We are still trying to get rid of numbered lines ...)
Not to mention that Fortran has come a long ways from your father's (or my) Fortran IV.
RatFor for the win... :)... :(