The "C is Efficient" Language Fallacy (2006)
scienceblogs.com
The "C is Efficient" Language Fallacy (2006)
1–10 of 133 posts
Re: The "C is Efficient" Language Fallacy (2006)
#2This is old (2006), and seems to base its argument around the problems with unrestricted pointers in C, that cause aliasing.
As of C99, of course, C has the "restrict" keyword which allows pointers to explicitly be declared to not alias, thus enabling all these optimizations in C, too.
Re: The "C is Efficient" Language Fallacy (2006)
#3For me, the blinking and moving ads completely invalidate this site..
Re: The "C is Efficient" Language Fallacy (2006)
#4> In C and C++, there's no such thing as an array
Yes there is. `int a[10]` allocates 10 consecutive `int`s on the stack, and it's the only language construct to express that (with `alloca` but it's a builtin function).
Re: The "C is Efficient" Language Fallacy (2006)
#5This is old (2006), and seems to base its argument around the problems with unrestricted pointers in C, that cause aliasing. As of C99, of course, C has the "restrict" keyword which allows pointers to explicitly be declared to not alias, thus enabling all these optimizations in C, too.
And then there are SIMD compiler intrinsics. Not technically part of the C standard, but if you want them, C/C++ is where you find'em. Failing that there's inline assembly.
Re: The "C is Efficient" Language Fallacy (2006)
#6For me, the blinking and moving ads completely invalidate this site..
Because I've read this blog before, I can point you to this:
http://scienceblogs.com/goodmath/2010/07/seed_conflicts_of_i...
Don't blame the author
Re: The "C is Efficient" Language Fallacy (2006)
#7I was actually under the impression that Fortran was used simply because the experts (in this case in fluid dynamics) was familiar with Fortran. It was the language they learned and used while back at the university. At least this is the impression I got from working in the field.
I never heard of anyone suggesting we should use Fortfran for performance reasons, instead there was an ongoing movement to evolve the code, moving it to use the OpenFOAM solver that's written in C++.
Re: The "C is Efficient" Language Fallacy (2006)
#8This is old (2006), and seems to base its argument around the problems with unrestricted pointers in C, that cause aliasing. As of C99, of course, C has the "restrict" keyword which allows pointers to explicitly be declared to not alias, thus enabling all these optimizations in C, too.
Thank you. I see some variant of this argument somewhere on the web every few months, and it makes me want to bang my head on the table.
Re: The "C is Efficient" Language Fallacy (2006)
#9Umm, yes C/C++ will not parallelize your code for you, whereas Language XYZ will. Im not sure how this is an argument against C/C++ being effective. C/C++ will not parallelize your code by design. It's was never meant to. I'd never blame my stick-shift car for not changing gears by itself - thats the first reason I didnt buy an automatic in the first place!
If your matrix manupuilation code performance becomes an issue, you, the C/C++ coder will have to parallelize it and take responsibility for whatever assumptions have to be made.
Im sure that the limit of what one considers as acceptable code alteration by the compiler/interpreter depends on the person. Personally I'd be very wary of a system trying to guess-parallelize my code - especially if I can do it myself whenever I see fit by adding a dozen boilerplate code lines. I'm sure most academics needing a numerical calculus system would be glad to have the system abstract away every possible optimization, so that they can stay as much as possible in the 'abstract math space'.
I am also kind of wary of the "look, I wrote the program in several languages and here is the perf comparison". Our skills with each language vary. What I liked was (i cant seem to find the link) a teacher who asked his class to write a program doing some text manipulation/indexing (iirc) in whatever language they wanted. The fastest code was in C, yet the worst C implementation was significantly slower than an average java code. To sum all this up - the speed depends on the skill of the person in the particular language, much more than on the language itself.
Re: The "C is Efficient" Language Fallacy (2006)
#10While a lot of Scientific computing is done in FORTRAN, much of the lower-level `plumbing' is written in assembly, C or C++.
C isn't an efficient language, C is just thin layer on top of assembly. You can write shit code in C, I know that from experience, but you can also write really fast code in C.