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

81–90 of 106 posts

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

#81

Post by SixSigma »

hzhou321 wrote: post #48

If there is a universal, relatively simple formula for general efficiency, then compilers may be constructed with such algorithm to render certain language more efficient than other. Alas, there is no such thing. Efficiency, as current situation (before true AI), are always specific. The compiler may implement certain specific optimizations that enable efficiency for certain specific applications -- inline here and t…

The most efficient thing to do is nothing at all.

What we want is effectiveness.

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

#82

Post by marvy »

shenberg wrote: post #16

The author is wrong about the details but right regarding the general point. Wrongness: 1. C99 has the restrict keyword to declare no aliasing. 2. there are still many places dropping down to assembly is better than what your compiler can do, mostly since C is too portable to provide access to processor flags directly (see strlen.s/asm for your platform for an example, e.g. http://lxr.free-electrons.com/source/arch/a…

3. nitpick to the nitpick: your example is a bad way to prove that arrays and pointers are distinct: a = a; // also doesn't compile const int x, y; x=y; // also doesn't compile :) The following is more helpful I think: a=b; //error b=a; //fine! sizeof a != sizeof b; // true

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

#83

Post by ygra »

jdright wrote: post #74
YeGoblynQueenne wrote: post #57

Earlier quoted context omitted.

Something else that struck me as wrong: the op counts the time the JVM needs to startup in the time it takes for the program to complete. That should be completely wrong, right? Otherwise we should count the time the physical machine took to boot up -and then the OS to load- in the time each benchmarked implementation took to complete. The JVM is a virtual computer, so why treat it any different than the physical one…

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.

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

#84

Post by lorenzhs »

jblow wrote: post #68
semi-extrinsic wrote: post #60

Earlier quoted context omitted.

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

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-implement it. We take great care to match their performance and have, on several occasions, beat it (compared to the published results, running on similar hardware). It's a lot more work, but in our group we really try to make fair comparisons. Maybe not everyone is so inclined, but I'm sick of reading these stereotypes over and over again.

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

#85

Post by jjdredd »

gus_massa wrote: post #26
iheartmemcache wrote: post #11

Mods- put a (2006) in there please. The number-crunching ecosystem has changed drastically in 10 years. He also didn't mention what compiler he's using. Intel's ICC had a huge advantage over gcc 2.95.3 (or whatever was used in '06) especially in numerical methods. (Though, I'm not sure when Intel's MKL became semi-freeware; at which point there was a significant performance jump if one opted to use the lib appropriat…

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

Particle physicists began to move on to C++: Pythia, GEANT4, root.

EDIT: Also, lattice QCD people are using C++ nowdays (frankly, I haven't seen them using anything else).

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

#86

Post by SilasX »

YeGoblynQueenne wrote: post #30
satysin wrote: post #23

Earlier quoted context omitted.

Indeed. This post is nothing more than "I did this and look at the results" but offers nothing for us to repeat his tests. Plus yeah it is a decade old, things have changed a hell of a lot in the past decade.

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

That's seems ... unscientific, you know? To make it unnecessarily difficult to replicate your results for purposes of confirmation/refutation?

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

#87

Post by ArkyBeagle »

jblow wrote: post #69
ArkyBeagle wrote: post #10

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

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.

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

#88

Post by ksk »

iheartmemcache wrote: post #11

Mods- put a (2006) in there please. The number-crunching ecosystem has changed drastically in 10 years. He also didn't mention what compiler he's using. Intel's ICC had a huge advantage over gcc 2.95.3 (or whatever was used in '06) especially in numerical methods. (Though, I'm not sure when Intel's MKL became semi-freeware; at which point there was a significant performance jump if one opted to use the lib appropriat…

> The number-crunching ecosystem has changed drastically in 10 years.

How has it gotten better? What has changed? And why are those changes relevant?

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

#89

Post by Roboprog »

Retra wrote: post #79
michaelfeathers wrote: post #5

True, the efficiency argument is wrong. Thinking about your algorithm and knowing where you actually need to be efficient are far more important. What I appreciate about C in particular is that it seems harder to "program by accident" than it is in most languages. C was my first language. After I learned C, I programmed in a higher level language for a while later before discovering that its runtime threw exceptions…

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 := 'Hello' + ' ' + 'world';
    multi := 616;
    writeln( s, ' ', multi : 4);
vs

    char s[ 256 ]; int multi;
    ...
    s = strcat( strcat( "Hello", " "), "world");
    multi = 616;
    printf( "%s %d4\n" s, multi);
It's a shame no work was put into good Modula 2 compilers (for various platforms) around 85-90, rather than running with C as the standard. Imagine all the security disasters that probably would have been avoided.

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

#90

Post by hzhou321 »

SixSigma wrote: post #81
hzhou321 wrote: post #48

If there is a universal, relatively simple formula for general efficiency, then compilers may be constructed with such algorithm to render certain language more efficient than other. Alas, there is no such thing. Efficiency, as current situation (before true AI), are always specific. The compiler may implement certain specific optimizations that enable efficiency for certain specific applications -- inline here and t…

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?
Post reply on HN