top | item 21054538

(no title)

19ylram49 | 6 years ago

> "As fast as C" would commonly be interpreted as "a program written in it will be as fast as a well-written C equivalent"

That’s your interpretation, which is fine, but the objective meaning stands. Even the idea of “well-written C” is, in my experience, fairly subjective amongst C programmers.

discuss

order

ezrast|6 years ago

Remember that we're comparing languages, not programs. A language can be thought of as the space of all programs that can be interpreted by that language. In any language, any algorithm can be implemented arbitrarily slowly. So the only meaningful point of comparison between language X and language Y is the upper bound on the performance of each language's program-space.

That some particular C program exists that is at least as slow as a program in some other language is always true, trivially, and so is not a good interpretation of "as fast as C" regardless of its objectivity.

RussianCow|6 years ago

You're missing the point. The fact that a language compiles down to C doesn't mean it compiles down to efficient C. At the simplest level, the compiled code could add a bunch of unnecessary function calls and pointers and other forms of indirection that wouldn't be present in hand-written C. But for a more extreme example, you could also compile an interpreter or VM to C, and it would still be much slower than the equivalent hand-written C code. This is why "as fast as C" typically refers to normal, hand-written C code—even though there is no formal definition for what "normal C" looks like, it's still a useful description.

19ylram49|6 years ago

> The fact that a language compiles down to C doesn't mean it compiles down to efficient C.

Where do you see me claiming otherwise?

> At the simplest level, the compiled code could add a bunch of unnecessary function calls and pointers and other forms of indirection that wouldn't be present in hand-written C.

Again, why are you telling me this? Please quote where I claimed otherwise.

> But for a more extreme example, you could also compile an interpreter or VM to C, and it would still be much slower than the equivalent hand-written C code.

The more that I read your response, the more that it seems that you’re debating yourself, because I’m not sure why you’re telling me this. You started your response by telling me that I’m “missing the point” when, in reality, you seem to have not even read my point. My main point was the following:

> If the code from which the resulting machine code is compiled is C, then it’s objectively “as fast as C” […] your resulting program will perform as fast as a C compiler [worth its salt] can get you.

This is true. I made no claims re efficiency; “as fast as C” and “as fast as efficient hand-written C” aren’t interchangeable claims. Forgive me for not assuming efficiency, because I’ve seen a good amount of inefficient hand-written C code in my years.

> This is why "as fast as C" typically refers to normal, hand-written C code—even though there is no formal definition for what "normal C" looks like, it's still a useful description.

Says who though? I’m professionally experienced in C, and as is very clear by this discussion, it’s down to individual interpretations.