Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The “C Is Efficient” Language Fallacy (2006)

scienceblogs.com

Post reply on HN
Print view View original

91–100 of 106 posts

Re: The “C Is Efficient” Language Fallacy (2006)

#91

Post by jblow »

ArkyBeagle wrote: post #87
jblow wrote: post #69

Earlier quoted context omitted.

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.

If you 1) Know the base address of the array. 2) Know the offset of the element(s) you're passing 2a) Know the declared length ( or other upper limit for the array ). then you need never refer to any element of an array that doesn't exist.

That's not the problem. The problem is any other live pointer could point into that array, for all the compiler knows. Unless the array was generated locally and never aliased, then if you ever call through some set of procedures that the compiler doesn't have complete visibility into, then it is possible that that code generates a pointer into that array and then uses it. The compiler has to be VERY conservative.

Re: The “C Is Efficient” Language Fallacy (2006)

#92

Post by tokenrove »

pekk wrote: post #50
tokenrove wrote: post #18

An 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…

Except that the default, basic, recommended style for writing in C and writing in some other language X often produces very reasonably fast code in C, and horribly slow code in X. Which was the whole reason people advanced the argument that you need to use contortions to get X to generate code that even approaches the speed of normal, uncontorted C.

I agree, although I think this is mostly cultural.

If we're only talking about single-threaded, CPU-bound code, this is basically true of any imperative language without fancy data structures: even a fairly naive native compiler will produce "pretty fast" code in our modern times where the standard for pretty fast is pretty low.

It seems intuitive that the further a language is from the machine, the harder the compiler has to work to make that language's idiomatic constructs efficient on a machine.

The kicker here is that C is no longer so close to the machine. It's still a PDP-11, and today's machine is not. This idea is what I think is still useful about the original article, for all its other faults.

I admire compilers like MLton that actually deliver on the promise of higher-level languages without the usual performance compromises for abstraction. Hopefully we'll see more of this as time goes on, as well as more languages like Sequoia that are close to the new machine.

Re: The “C Is Efficient” Language Fallacy (2006)

#93

Post by benchaney »

ygra wrote: post #83
jdright wrote: post #74

Earlier quoted context omitted.

No. The JVM should be included too as it is part of what the language needs to run. If you wanna compare including the boot of the real machine, then go for it as to run the JVM you still need a real machine to boot, but then you're adding noise as the machine is the same for the two programs and can, due external out of control reasons, have different timings. But still, JVM IS part of the language and the program u…

To add to this: The same goes for C's process startup (at least the OS won't call main with those arguments; the C stdlib performs some tasks before your code runs), or interpreter startup. Unless you're writing in assembler and call the OS directly, almost every programming language will have some overhead when starting. Granted, managed languages like Java are much worse than many others.

This is true, but any overhead that C has Java will also have because the JVM is itself an ELF binary.

Re: The “C Is Efficient” Language Fallacy (2006)

#96

Post by SixSigma »

hzhou321 wrote: post #90
SixSigma wrote: post #81

Earlier quoted context omitted.

The most efficient thing to do is nothing at all. What we want is effectiveness.

Efficiency is measured by cost and result. Doing nothing end up with no result, how is that "most efficient"? And what is the definition of effectiveness? ... maybe the word you are looking for is convenience?

no, efficiency is expenses / revenue

Re: The “C Is Efficient” Language Fallacy (2006)

#97

Post by YeGoblynQueenne »

lorenzhs wrote: post #84
jblow wrote: post #68

Earlier quoted context omitted.

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

At least in my (and my colleagues') areas of CS, you usually ask the original authors of a paper you want to compare to. A large percentage of them will be glad to provide you with their code, for it goes a long way towards ensuring that their algorithms aren't grossly misrepresented. If they don't (because the code is a mess, they can't find it or get it to work any more, or for whatever reason), you'll have to re-i…

>> Maybe not everyone is so inclined, but I'm sick of reading these stereotypes over and over again.

I'm sorry if my comment upset you. I'm really not trying to advance any stereotypes and rather just report what my experience is so far, as a Masters student (rather than a researcher). I've also discussed this with one of my professors, who does research mainly in NLP and he told me the same thing.

Personally I find it hard to understand why it's not compulsory for academics to point to a public repository where anyone can find the code that goes along with their papers. I've heard arguments for and against sharing code and particularly data, so I'm not saying that I am necessarily right, but it's really just weird to read "our system beats the best results reported so far" with nothing but a few figures in a table to back that up. And with so much infrastructure and tools around to support sharing code (just think of github) I really don't see what's stopping people.

Re: The “C Is Efficient” Language Fallacy (2006)

#98

Post by Retra »

Roboprog wrote: post #89
Retra wrote: post #79

Earlier quoted context omitted.

I think that C is a very good first language to learn, not because it hardens you against errors, but because it has a very simple mental model that you can use to understand how other might languages work in terms of C semantics, which provides useful clues for what the costs are for features in those languages.

I'm pretty sure that if C was the first language presented to me back in college, I would have found a new major. C was more convenient than doing assembler, but not much more, compared to say Pascal. (Having learned BASIC, FORTRAN 77, Pascal, PDP-11 ASM, Lisp at school, and some dBASE at work, before we switched over to C at school, which seemed like a big step backward) var s : string; multi : integer; ... s := 'He…

C was my first language, and I did find a new major (Physics/Mathematics.) I only considered going back for a CS degree after learning Haskell.

Re: The “C Is Efficient” Language Fallacy (2006)

#99

Post by lorenzhs »

YeGoblynQueenne wrote: post #97
lorenzhs wrote: post #84

Earlier quoted context omitted.

At least in my (and my colleagues') areas of CS, you usually ask the original authors of a paper you want to compare to. A large percentage of them will be glad to provide you with their code, for it goes a long way towards ensuring that their algorithms aren't grossly misrepresented. If they don't (because the code is a mess, they can't find it or get it to work any more, or for whatever reason), you'll have to re-i…

>> Maybe not everyone is so inclined, but I'm sick of reading these stereotypes over and over again. I'm sorry if my comment upset you. I'm really not trying to advance any stereotypes and rather just report what my experience is so far, as a Masters student (rather than a researcher). I've also discussed this with one of my professors, who does research mainly in NLP and he told me the same thing. Personally I find…

I didn't mean to attack you personally - that sentiment gets echoed a lot on HN and I replied to your comment, meaning to address all of those that I read before but didn't reply to, so please don't take it personally.

My area is in algorithmics, which is a lot less of a "hot topic" and there's less competition and more cooperation all-around. That may be an important factor in the willingness to share code.

I do agree with you on publishing code and have open-sourced the code to some of my research. Unfortunately I never heard back from anyone, maybe my topics just aren't hot enough ;) I'm a bit unsure whether to publish code for ongoing projects (where some aspects have been published, but others are still in the works for future publications) - in that case there is some incentive to keep the source closed until the project is finished.

Re: The “C Is Efficient” Language Fallacy (2006)

#100

Post by slededit »

pjmlp wrote: post #59
pekk wrote: post #50

Earlier quoted context omitted.

Except that the default, basic, recommended style for writing in C and writing in some other language X often produces very reasonably fast code in C, and horribly slow code in X. Which was the whole reason people advanced the argument that you need to use contortions to get X to generate code that even approaches the speed of normal, uncontorted C.

Except for the little fact that in the 80's and 90's most hobby coders still managed to write better Assembly than C compilers for home computers were able to generate. C compilers are fast in modern times, because of the amount of industry money spent in writing C optimizers since the industry adopted it.

You can still write better assembly today. You just probably wouldn't be able to keep up the effort for the entirety of your code base.
Post reply on HN