
The "C is Efficient" Language Fallacy (2006) - m_for_monkey
http://scienceblogs.com/goodmath/2006/11/the_c_is_efficient_language_fa.php
======
nickolai
Umm, 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.

~~~
jrockway
You're missing the point. The target demographic for this article is someone
who is not a computer scientist. He's someone who doesn't have time to deal
with thread libraries and low-level matrix operations. He just needs to crunch
his data quickly so that he can publish his valuable research. This person
reads the same blog articles that computer scientists do, and comes to the
conclusion that "I should learn C++ for my number crunching". That's simply
not the case; you _can_ use C++ to get good performance, but the amount of
knowledge you need to acquire to do so is an entire field. You aren't going to
be the world's best human genome researcher _and_ C++ programmer; the time
spent learning C++ could have been used to do research.

The idea is: if you use a tool that lets you describe your problem at a high
level and let the computer worry about how to do the calculation efficiently,
you'll beat your hand-rolled C++ every time. And, there is now the possibility
of hiring a "Real Programmer" to hack your math library (Octave, Mathematica,
Python + numpy, whatever), allowing you to delegate work. If every calculation
was a brand new C++ program, you'd only be able to improve your application's
performance by hacking on your application. Separating the problem description
and the solution description allows the solution-finding code to be optimized
without knowledge of the specific problem.

I think this approach scales to the work that practicing programmers, too. We
don't see it a lot because writing tools is time consuming and we all have
deadlines; so we pic k the "worse is better" solution and hard-code our
applications in what amounts to glorified machine code.

Just because a practice is common doesn't mean it's a good idea.

~~~
danieldk
Except that there are fine high-level matrix libraries, optimization
libraries, etc. for C/C++. I needed an parameter estimator for maximum entropy
models that was efficient for training rankers (e.g. for parse disambiguation,
fluency ranking, etc.), that also had good support for feature selection. I
just used an off-the-shelf optimizer (liblbfgs), implemented calculation of
the objective and gradients, plus various feature selection methods.

Within no-time, we had an extremely fast estimator, that could also help
answering my research question (what are the most discriminative features in
our models).

Let me push this point somewhat further: C is a very simple language. It's
something that someone with a certain level of intelligence can fairly quickly
pick up. There is also a wealth of excellent libraries available. The problem
with 'use high-level, the compiler/interpreter will take care of it' is that
those languages are either a lot more complex (Haskell, OCaml) or a lot slower
(Python, Perl, Ruby). In the latter case, you will end up implementing modules
in C anyway.

~~~
MichaelSalib
_C is a very simple language._

It is? Out of curiosity, did you know about all the undefined behaviors
described at [http://blog.llvm.org/2011/05/what-every-c-programmer-
should-...](http://blog.llvm.org/2011/05/what-every-c-programmer-should-
know.html) and did you understand how your C compiler takes advantage of them
before you wrote that statement?

~~~
rcfox
Yes, that's what makes C simple. If all of those edge cases were covered, the
language would be much more complex.

Simple != Easy to use

~~~
MichaelSalib
So when people say that "C is simple", you think they really mean "C is simple
to implement" or maybe "C is simple to specify"? I don't think the grandparent
meant either of those things and I don't think either of them are true anyway.

~~~
danieldk
Simple in the sense that it is a small language. There are not a lot of
constructs, abstractions, etc. C lets you allocate blocks of memory, and
perform operations on those blocks of memory. That's mostly it. In my
experience, this very much maps to the problem domain (number crunching).

If you want to do performant number crunching with most other languages, you
have to not only grasp the language, but also the underlying virtual machine
or compiler. The more layers you pile on top, the harder it becomes to
identify bottlenecks.

Sure, you can use fast implementations of common algorithms in a high-level
language. But they are often written in C or C++. So, if you want to modify or
extend such algorithms (which is likely, or you could just use an off-the-
shelf program), you will end up in C-land anyway.

~~~
wvenable
> C lets you allocate blocks of memory

It doesn't even let you do that -- those things are external library calls.

~~~
derleth
They're standardized, so they are part of the language.

They don't have special syntax, but, then, neither does practically anything
you do in Common Lisp, and that's standardized as well.

~~~
stcredzero
_They're standardized, so they are part of the language._

"Language" has slightly different meanings in different contexts. Perhaps he's
talking about something in a theoretic context, as opposed to practice?
Smalltalk has no special syntax for allocation (creating new objects) either.

~~~
derleth
> Perhaps he's talking about something in a theoretic context, as opposed to
> practice?

Then he's still wrong. A standardized part of the language is a part of the
language.

------
MichaelSalib
Putting aside his general point C efficiency, I'm curious about his specific
claim that Fortran compilers outperform C specifically because aliasing
conceals optimization opportunities. John Reghr points [1] to a really
interesting paper from 2004 that used a special analysis tool to mark every
single pointer as restrict as it safely could in the SPEC benchmark. The
result was a 1% performance improvement.

That suggests that at least circa 2004, if aliasing were a serious problem for
C compilers, restrict annotations were not the solution, which calls Chu-
Carroll's claim into question. But there might be other explanations. Any
thoughts?

[1] <http://blog.regehr.org/archives/537>

ETA: Just to clarify what the 2004 paper involved: the researcher took the
SPEC code and ran it through a dynamic analysis tool that identified every
single use of non-restricted pointers that did not alias any other in-scope
pointer at the time. He then took all of those pointers and marked them as
restricted in the source text. The result was a program with every possible
pointer marked as restricted that could be so marked. That's way more than a
human annotater will ever do. And all that got him a 1% performance
improvement.

~~~
lukesandberg
Well maybe the reason performance improved only slightly is because not a lot
of effort has gone into optimizing situations involving restrict pointers
because it is so rare. If it is common in fortran it would make sense that a
lot of effort has gone into special optimizations for that case, the same
effort would not have been spent in c compilers because it is so rare.

~~~
AshleysBrain
I'm not sure it's as rare as you make it out to be - AFAIK most compilers that
support restrict declare malloc() and new to return restrict pointers, so

    
    
        int *x = malloc(100), *y = malloc(100);
    

followed by some loop should be able to spot that x and y are not aliased. It
should also be able to propagate the restrict as pointers are passed around,
at least to some extent.

~~~
lukesandberg
would the c compiler actually pull that restrict annotation forward without
declaring the locals as restrict?

------
unwind
This 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.

~~~
rbehrends
The problem with the C99 restrict is that its correct use is not (and cannot)
be enforced by the compiler. For example, the following is legal C (in the
sense that no compiler that I know of will issue as much as a warning):

void f(char * restrict p, char * restrict q); char * h() { static char s[10];
return s; } void g() { f(h(), h()); }

(Correctness of a program using restrict is, in general, not decidable.)

The tradeoff here is that while restrict can be used to allow for further
aliasing, it is very easy to write code with undefined behavior as a result.
Dennis Ritchie argued as much when he (successfully) kept "noalias", the
precursor of "restrict", out of the C89 standard:
<http://www.lysator.liu.se/c/dmr-on-noalias.html> (while "restrict" is not
quite as dangerous as "noalias", it still has to be used with care).

~~~
jmilloy
I don't know the first thing about FORTRAN. How does it enforce this?

~~~
rbehrends
This is independent of what FORTRAN does. The problem with the "restrict"
keyword in C99 is that introducing it can make otherwise correct code
incorrect and the compiler can't tell you.

As to program analysis, programming languages without pointer arithmetic have
it a lot easier than languages with. The pair (array, index) holds more
information than the address of array[index]. For example, it is trival to
perform array bound checks if you have the former information, but very hard
if you deal with arbitrary pointers. Pointer arithmetic loses information.

------
chalst
_C and C++ suck rocks as languages for numerical computing. They are not the
fastest, not by a longshot. In fact, the fundamental design of them makes it
pretty much impossible to make really good, efficient code in C/C++._

I dare say this is more or less true of C, but following big improvements in
the quality of C++ compilers (changes that happened well before 2006), C++ has
proven itself as a language for high-performance scientific computing. Todd
Veldhuizen provided a survey back in 1997 of the changing case in favour of
C++ to accompany his Blitz C++ library:
[http://www.autistici.org/sens/inf/scientificcomputingcfortra...](http://www.autistici.org/sens/inf/scientificcomputingcfortran.pdf)

Fortran still has considerable advantages, but it's been a long time since
Fortran programmers could regard C++ as offering unserious performance.

I would also hesitate to say that C++ is lower level than Fortran. With a
suitable coding style, C++ is a quite high-level language. In fact, it is
precisely the abstractions that C++ offered (templates) that allow the
optimisations to take place that have delivered these improvements in compiler
performance. Was the author not aware that templates can be used in this way?
The discussion of alias detection suggests so.

The high-level point is right, namely that abstractions make for safer
languages and give compilers freedom to make optimisations that apparently
more efficient, less safe languages cannot, and so deliver better performance.
But it would have been a better article if it had not mentioned C++.

Another conclusion to draw is that benchmarks produced by people who are out
to make a point are worthless.

~~~
lutorm
I was going to post something similar, with one addition:

One performance problem with Blitz was that the expression templates
obfuscated the code enough that the compiler bailed on doing SIMD
vectorization of the evaluation loops. That was fixed this year at least for
the Intel compiler (gcc doesn't have pragmas to control vectorization), so now
performance can even exceed Fortran for large-ish arrays.

I made some plots while fiddling with this if you are interested:
[http://governator.ucsc.edu/filer/blitzbench_r1845/blitzcomp....](http://governator.ucsc.edu/filer/blitzbench_r1845/blitzcomp.html)

------
attractivechaos
The longest common substring problem (LCS) can be solved in O(n^2) time using
dynamic programming, not O(n^3) as is stated by the author of that post. If
the author is unable to get the basic fact right, I can hardly trust his
benchmark. Also, I question the author's skill in C/C++: in my experiences, C
is consistently faster than Java for such tasks and C++ is nearly as fast as C
as long as we use it the right way. If we look at the computer benchmark
games, OCaml never beats C in terms of speed. I doubt the conclusion was much
different in 2006. The author should released the source code; otherwise the
benchmark tells us nothing but his incapability in programming.

EDIT: in his comments to another commenter, the author was saying this: "[The
OCaml compiler] could do some dramatic code rewriting that made it possible to
merge loops, and hoist some local constants out of the restructured merged
loop." A good C programmer should be able to do all the above simply by
instinct. The author was not good enough. I buy the argument that being really
good at C/C++ is more difficult than at other languages, but this is not the
same thing as arguing C is inefficient.

~~~
chengl
What the author mentioned is longest common SUBSEQUENCE (not substring). And
it's true that LCS requires O(n^2) if only need to find ONE LCS, using dynamic
programming. But if it's required to find ALL longest common subsequence, it
definitely requires higher order.
[http://en.wikipedia.org/wiki/Longest_common_subsequence_prob...](http://en.wikipedia.org/wiki/Longest_common_subsequence_problem)

I agree that the author should post the code he used to benchmark different
languages. Otherwise, it's not convincing

~~~
attractivechaos
Can you find the proof that finding all LCS is O(n^3)? The author was talking
about "the standard algorithm for computing LCS". I was assuming the standard
algorithm finds one LCS only.

~~~
cperciva
Indeed, finding all LCSs requires exponential time: The strings
"abcdefghijkl..." and "badcfehgjilk..." have the 2^(N/2) LCSs
"[ab][cd][ef][gh][ij][kl]..." and no algorithm can ever run faster than the
amount of time it takes to print its output.

------
zvrba
C and C++ are efficient for _general-purpose_ programming, if you know how to
use them. C is here to stay because it is lingua franca of the computing
world: OS APIs are defined in terms of C functions, and I know of no libraries
in wide-spread use that do not offer a C or C++ interface.

People otherwise rightfully challenge his conclusions.

There's a funny comment there about matlab: "MATLAB struck me as being the
wrong tool for every problem."

~~~
Peaker
Matlab may be a pretty bad language, but it gives access to a huge (and
growing) body of existing code.

~~~
wickedchicken
If you're an engineer (like an engineer engineer, not a software engineer) 90%
of the time matlab has some module built-in or for sale that simply solves the
problem you have. For example: [http://www.mathworks.de/products/dsp-
system/demos.html?file=...](http://www.mathworks.de/products/dsp-
system/demos.html?file=/products/demos/shipping/dsp/adaptfxlmsdemo.html)

The code to construct an LMS filter
([http://en.wikipedia.org/wiki/Least_mean_squares_filter#LMS_a...](http://en.wikipedia.org/wiki/Least_mean_squares_filter#LMS_algorithm_summary))
is effectively one line:

    
    
       h = adaptfilt.filtxlms(L,muW,1,Hhat);

~~~
KingMob
You've hit the nail on the head. This is exactly why Matlab is so pervasive in
science. Not because it's actually good, but because it has so many handy
libraries. The Mathworks is the Microsoft of science.

I had to use Matlab for seven years in neuroscience, and it's a terrible
language for everything other than matrix math, data plotting, and (if you
cough up for the Parallel Computing Toolbox) easy parallelization.

~~~
rcfox
Somewhat off-topic: Have you heard of the Neural Engineering Framework?
<http://ctn.uwaterloo.ca/~cnrglab/?q=node/10> It's got a Python (well, Jython)
scripting interface and can also interact with Matlab.

~~~
KingMob
No, I hadn't heard of it, but I was operating slightly higher, in cognitive
neuroscience, and doing a lot of fMRI and intracranial EEG work. For those
domains, the biggest packages are SPM and Fieldtrip, both of which run on
Matlab.

I do, however, hope that Python will push out Matlab one day.

------
haberman
As someone who doesn't know Fortran, how does Fortran solve the aliasing
problem? Even if pointers and arrays are different, how can you ensure two
arrays don't alias each other? The only way I can think of to do this is to
always copy arrays when they are passed to functions, but this seems
expensive. Otherwise I don't see how you can avoid this pseudocode:

    
    
      void f(array1, array2) { /* somehow guaranteed not to alias? */ }
      void g() {
        array my_array[50];
        f(my_array, my_array);
      }

~~~
scott_s
I thought about it, and I realized I didn't know. This is the best discussion
I found: [http://gcc.gnu.org/onlinedocs/gcc-3.4.6/g77/Aliasing-
Assumed...](http://gcc.gnu.org/onlinedocs/gcc-3.4.6/g77/Aliasing-Assumed-To-
Work.html)

Short answer: they don't. What you wrote is an undefined behavior, just like
dereferencing a null pointer in C. If the compiler can't tell statically, then
it just assumes they're not aliased.

I'm basing this conclusion mainly on this statement from that piece on
aliasing: _Essentially, compilers are promised (by the standard and,
therefore, by programmers who write code they claim to be standard-conforming)
that if they cannot detect aliasing via static analysis of a single program
unit's EQUIVALENCE and COMMON statements, no such aliasing exists. In such
cases, compilers are free to assume that an assignment to one variable will
not change the value of another variable, allowing it to avoid generating code
to re-read the value of the other variable, to re-schedule reads and writes,
and so on, to produce a faster executable_

~~~
haberman
Interesting, that sounds equivalent to just assuming "restrict" on all
function parameters. If that's true, then C and Fortran aren't fundamentally
that different in this respect except that C assumes things can be aliased by
default and Fortran assumes they can't.

------
jpdoctor
> _Modern architectures have reached the point where people can't code
> effectively in assembler anymore_

Someone should inform the guys over at ffmpeg that the jig is up.

~~~
ternaryoperator
The statement is overbroad but not wholly incorrect. The biggest challenge to
writing good (I don't know about "effective") assembly language is indeed the
complexity of processors and architectures which can greatly magnify the
effects of imperfect instruction choices or instruction sequencing. Obviously,
some people can code effectively within those constraints, but it's a very
much more specialized skill than it used to be.

------
Locke1689
Arrays and pointers are most certainly _not_ the same thing in C. Check
yourself here:

    
    
        char x[100];
        char* y = malloc(100*sizeof(char));
        printf("Array: %ld\nPointer: %ld\n", sizeof(x), sizeof(y));

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

~~~
exDM69
The OP wants to point out that C hasn't got first class arrays the same way
that Fortran does. The C kind of arrays get passed to and from functions using
naked pointers and that makes lots of compiler optimizations more difficult
because of aliasing issues while a Fortran compiler knows that two arrays
cannot alias (use overlapping memory areas). By adding a "restricted"
declaration to your pointer types in function signatures, the compiler assumes
no aliasing occurs and goes on with the optimizations. It's the coders'
responsibility to make sure no aliasing happens, but if it does, all hell can
break loose.

~~~
jrockway
Sort of true. In C99, you can:

    
    
      void f(int len){
        int array[len];
        printf("sizeof len: %zu\n", sizeof(array));
      }
    

Yes, I was weirded out when I saw this for the first time. But C does in fact
have arrays; they're just not very good arrays.

~~~
pjmlp
If len is big enough your f() call will crash with a stack overflow.

~~~
repsilat
I don't understand why stacks are still so small. On nice operating systems
memory is only needed when it's touched, not when it's asked for, so making
the stack large doesn't cost anything unless you need a large stack. On 64-bit
systems you could make the stack a billion gigabytes and still have 95% of
your process' virtual address space available for the heap.

On Windows the stack is one megabyte by default. We live in the future and
we're still afraid of recursion without tail-call optimisation and arrays on
the stack. Ridiculous.

~~~
jemfinch
Stacks are small because every thread in the system has to have one, it's that
simple.

~~~
quotemstr
Who said stacks had to be contiguous and allocated ahead of time?

~~~
emillon
How would you manage non-contiguous stacks ? ie, how would you know (upon
return) where is the caller's stack frame is ?

~~~
exDM69
The stack is only contiguous in the virtual address space. The physical
address space is a different beast. The operating system allocates a big chunk
of virtual address space for the stack but doesn't allocate the physical
memory to fill that. When an app wants to read or write from the unallocated
part of the stack, a page fault interrupt is generated and the operating
system allocates physical memory frames and assigns them to the virtual memory
addresses of the stack. When the thread/process is interrupted for servicing,
the operating system checks the value of the stack pointer register (rsp in
x86_64) and frees the physical memory corresponding to the virtual addresses
above that in the stack.

So having a large stack will only consume virtual address space which we have
plenty of (2^48 bytes in most x86_64's) but will not consume physical memory,
which is a more limited resource.

------
cks
I 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++.

~~~
jmaygarden
Matrix operations can be faster in FORTRAN than C because of differences in
the way arrays are defined/implemented in each language.

~~~
stephencanon
This is just totally false. You can lay out your C arrays in exactly the same
way that Fortran does, if you choose to. Or you can do something else, if that
will give better performance. Tools are just tools; they don't determine what
you can do with them. (I write matrix operations for a living, generally in C
or Assembly; much of what I write is provably as fast as possible on the
target hardware, so it could not possibly be faster if written in Fortran).

------
jheriko
Okay, so there are reasons why C is /difficult/ to make very efficient for
numerical computations. Aliasing is not one of them since C99 for a
sufficiently knowledgable programmer thanks to the restrict keyword.

The library is the real problem.

code.google.com/p/fridgescript - faster than C in some cases, only because it
doesn't use the math library, but uses hardware without indirect calls and
without caring for obscure edge cases.

------
stephencanon
I write high-performance numerical software for a living. There are a lot of
baseless claims in this post. You can write high performance software in C,
C++, Fortran, Assembly, or a whole host of other languages. There are
syntactic reasons to prefer one or another, but you should not choose among
them for performance reasons.

I choose to write in C and Assembly, for example, and much of the code I write
is provably as fast as possible on the targeted architecture. It is literally
impossible that it would go faster if I wrote it in Fortran instead. All of
these languages are just tools, and if you know your tool, you can do great
things with it. The specifics of which tool you choose are often unimportant.

There are some syntactic niceties in fortran which make it more comfortable
for people who don't want to think about certain low-level details. However,
you cannot write software that runs as fast as possible without considering
those details, so a programmer with that goal is forced to think about them no
matter what tool he or she chooses.

Fortran _does_ have a (slightly) more relaxed numerics model than standard C,
which allows a compiler to make some optimizations that a C or C++ program
would need to explicitly license. However, these optimizations are disallowed
in standard C and C++ because they are unsafe. The fact that Fortran enables
them does not make Fortran a better language for numerical computation (from
my perspective as low-level library writer, they make it _worse_ ).
Performance without correctness is absolutely meaningless.

Write software in the language that is comfortable for you. Use libraries
written by experts for performance critical operations. Use a profiler to
identify operations that are hotspots in your code. Don't complain about your
(or someone else's) tools.

------
yummyfajitas
The author's point is well taken, but his example leaves a lot to be desired:

 _If you look at that loop, it can be parallelized or vectorized without any
problem if and only if the array pointed to by x and the array pointed to by y
are completely distinct with no overlap. But there's no way to write code in C
or C++ that guarantees that._

    
    
        double* doMath(double** y) {
            double** x = allocateNew2DArray(20000, 20000);
            for (int i=0; i < 20000) {
                for (int j=0; j < 20000) {
                    x[i][j] = y[i-2][j+1] * y[i+1][j-2];
                }
            }
            return x;
        }
    

All you need to do for this example is replace the fortran coding style
doMath(double* x , double* y) with the c coding style doMath(double* y).

I don't think any C compilers actually do parallelize code like this, or at
least they don't do much beyond using SIMD. But in principle they could.

~~~
nitrogen
I think something may have been lost when you typed your code. y is a pointer
to double, so can't accept two array subscripts (if it were "double * * y" it
could, or you could keep it as a one-dimensional array and use something like
y[(i - 2) * 20000 + j + 1]), and i and j don't appear to be incremented
anywhere.

~~~
yummyfajitas
Thanks, fixed the "double * * y". The i and j not being incremented is
actually an error in the original blog post - I'll leave it here for
consistency.

~~~
nitrogen
_The i and j not being incremented is actually an error in the original blog
post - I'll leave it here for consistency._

Ah. In that case, I wonder how the author managed to get an infinite loop to
complete in 0.8 seconds ;).

------
antirez
C does not offer parallelization automatically, but you can pick a model, and
a library, that is a good fit for turning your app into a parallel one. In
this regard the following slides are interesting:
<http://swtch.com/~rsc/talks/threads07/> The model proposed here may not be
the right one for your application, so you can design your own (including
multiple processes exchanging messages for instance, or the usual threading
with locks, and so forth, it's up to you).

This requires efforts but to be honest, there is currently no language that is
a good fit for system programming and that is able to parallelize your code
magically and automatically. Such a language would give a strong competitive
advantage to programmers using it, as C did in the past over other languages,
so would become mainstream soon or later, or its ideas would incarnate in some
other "better C" language. If this is not happening IMHO there is something
wrong in languages that currently are able to do more than C in this regard.

In programming ideas tend to take years to be accepted, but there is a very
clear trend over decades: something that is really better (as in code that is
faster, or simpler to write (very useful abstraction XYZ), or more easy to
debug, or with higher quality libraries, or even much simpler to deploy (PHP
I'm looking at you)) eventually becomes mainstream.

------
gsg
No mention of representation issues? Memory is a big optimisation target these
days, and a weak point of languages like Java and OCaml.

------
dwc
The missing meta lessons: don't fall for overly simple characterizations, and
don't be a language bigot.

"C is Efficient" is largely true, but it's certainly not always true, and
there are problem domains where it's seldom true. If you don't know that this
is the case with any language then you're not qualified to be picking an
implementation language anyway.

------
growingconcern
What a dolt. It's possible to tell the compiler that two pointers aren't
aliases: the "restrict" keyword. Unless I'm mistaken that is really his sole
argument against "pointer-based languages".

------
duaneb
Well argued... until I realized that his argument hinges on C/++ compilers not
being able to guarantee non-aliasing. That's why they introduced the
`restrict` keyword in C99....

------
akg
Every language has it's pitfalls. There isn't one single greatest language for
everything. Within an application domain one needs to consider the tradeoff
between machine-time and human development-time and determine what the best
tool for the job is.

A 5minute run-time in Python might be acceptable if it takes you 1 hour to
write it and are only going to use it once; whereas you may not even know how
to program in OCaml even though it offers the best run-time.

------
jensnockert
While 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.

~~~
exDM69
> C isn't an efficient language, C is just thin layer on top of assembly.

This is a pretty common fallacy. These days a C compiler does so much magic
that calling it sugared assembly doesn't describe it accurately.

With a 1970's single pass compiler your argument may have been more true.

~~~
jrockway
Yes, but it would be just as easy to write an "assembly compiler" that did the
same optimizations on your program text. C provides a layer above the machine
that acts as we imagine a machine to work; the compiler adjusts our
expectation to reality.

In the end, C has branching and memory access, and that's basically what our
computers have too. The rest is details.

~~~
adgar
> Yes, but it would be just as easy to write an "assembly compiler" that did
> the same optimizations on your program text.

While there are ways to optimize machine code without extra debug information,
no, what you've said is not true. It is not nearly as easy to optimize machine
code as it is to optimize C.

------
gizzlon
For me, the blinking and moving ads completely invalidate this site..

~~~
z0r
Because I've read this blog before, I can point you to this:

[http://scienceblogs.com/goodmath/2010/07/seed_conflicts_of_i...](http://scienceblogs.com/goodmath/2010/07/seed_conflicts_of_interest_and.php)

Don't blame the author

~~~
stonemetal
Given that you might like his new site better.

<http://scientopia.org/blogs/goodmath/>

