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

71–80 of 106 posts

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

#71

Post by the_why_of_y »

saynsedit wrote: post #64

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

Obviously, the OP was talking about function parameters, where "int x[1000]" is semantically equivalent to "int *x", see C11, 6.9.1, item 10:

http://www.iso-9899.info/n1570.html#6.9.1

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

#72

Post by ThePhysicist »

jarvist wrote: post #32
ThePhysicist wrote: post #29

Really good points! For me, the best approach to efficiency in terms of development speed and performance is to use a fast language for critical code paths and then make it accessible using a scripting language. Python and C++ work really great in this respect, as it's very easy to generate Python bindings for a C++ library using e.g. SWIG, SIP or Boost. Lua is also a good choice as an embedable scripting language an…

From your username & requirements, I'd definitely recommend looking at Julia: http://docs.julialang.org/en/release-0.4/manual/introduction... It can be very fast by itself, and can also be written extremely high level & is very easy to form bindings to other languages, thanks to the multiple dispatch. Even small things such as having full unicode support is very nice to write maths code in a very 'pen and paper' kind…

Yes Julia is interesting, but for most use cases the languages is (to my knowledge) still significantly slower than C, while not having the great library ecosystem that e.g. Python has. This might change in the future though, and I know that really bright people like Stefan Karpinski are behind the language, so I'm sure it might become a serious contender to Python in the future.

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

#73

Post by saynsedit »

the_why_of_y wrote: post #71
saynsedit wrote: post #64

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

Obviously , the OP was talking about function parameters, where "int x[1000]" is semantically equivalent to "int *x", see C11, 6.9.1, item 10: http://www.iso-9899.info/n1570.html#6.9.1

It's not obvious what he was talking about. In context he was responding to this comment:

"While I know that C compilers are really conservative about this, doesn’t it matter as to how x and y are declared? After all if they are dclared as: int x[1000], y[1000];"

Those array declarations aren't function argument declarations (except in pre-C89), so not sure why he would talk about semantic equivalence in response to that if it only applies to function arguments.

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

#74

Post by jdright »

YeGoblynQueenne wrote: post #57
corndoge wrote: post #49

Earlier quoted context omitted.

If you produced the exact same binary the language that was used to produce it would be inconsequential, no?

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 unless you compile to native.

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

#75

Post by sharth »

supercarrot wrote: post #6

as much as it's not part of the standard, __restrict__ allows limiting the effects of pointer aliasing in C/C++. [1] [1] : https://en.wikipedia.org/wiki/Restrict

The first line of your reference says that restrict __is__ part of the C99 standard.

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

#76

Post by ktRolster »

It's hard to take any post on efficiency seriously if the author doesn't indicate that they understand the difference between a cache miss and a branch-prediction. Things like that are so huge in modern processors that you will have trouble understanding how things work without it.

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

#77

Post by jdright »

YeGoblynQueenne wrote: post #56
corndoge wrote: post #49

Earlier quoted context omitted.

If you produced the exact same binary the language that was used to produce it would be inconsequential, no?

Hah. You're right, missed that. But that's the point, isn't it? You can't ever compare two programs written in different languages claiming to test "the same program" written in different languages. Because in the end either they're not the same program, so there's no comparison, or they're the same program, so what are you really comparing?

I think the reason of comparing two programs in two different languages is exactly to have an idea of how expressive one language can be to generate a performing program given its inputs and outputs are the same, the way on which the code is written is the second factor being evaluated. The benchmark game is the perfect exemple of this, anyone can write a better version of a program and improve the language "score" until no one will be able to improve it. At this moment we can see how the language design impacts the resulting program. This should be the only way to compare languages.

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

#79

Post by Retra »

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.

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

#80

Post by Const-me »

I don’t do numeric methods, but I occasionally solve performance-sensitive CPU-bound problems, in areas like CAD/CAM, 3D graphics, and GIS.

An average C++ CPU-bound code isn’t radically faster compared to e.g. C#. I suppose that’s true for other higher-level compiled languages.

But the good thing about C++, after I’ve profiled which parts of the algorithm take most time, I can gradually replace my average C++ code with SSE or AVX intrinsics. Sure it’s harder to read, write and understand, but if done right, on modern hardware it can become several times faster.

Post reply on HN