Re: [TUHS] History of popularity of C

[John Gilmore <gnu@toad.com>]

Tyler Adams <coppero1237@gmail.com> wrote:
> Doesn't C++ also generate tight code and is fairly close to the metal?
> Today C++ is the high performant language for game developers and HFT shops.
> 
> But, I never found it on any of these embedded systems, it was straight C.

My take on this is that programmers who understand the underlying
hardware architecture can easily intuit the code that would result from
what they write in C.  There are only a few late features (e.g. struct
parameters, longjmp) that require complex code to be generated, or
function calls to occur where no function call was written by the
programmer.

Whereas in C++, Pascal, Python, APL, etc, a few characters can cause the
generated code to do immense amounts of unexpected work.  Think of
string compares, hash table types, object initializers, or arbitrary
amounts of jumping through tables of pointers to different kinds of
objects.  Automated memory allocation.  Garbage collection.

This is both a blessing and a curse.  In C it was quite predictable how
well or badly typical sections of your code would perform.  If the
performance was bad, it was YOUR fault!  But at least YOU could fix it,
without learning to hack a compiler instead of your own application.

(I once found Berkeley SPICE code doing string compares in a triply
nested loop, just to look up the names of the signals.  In C.  Making
changes to a large state machine going into a custom chip was taking the
Sun hardware engineers multiple hours per change.  I spent weeks finding
the source code (Sun's tools group was dysfunctional; I got it from
UCB).  In half a day of profiling it and fixing it to cache the
result of the first string lookup on each signal name, four hour
rebuilds went down to under a minute.  A second day of profiling
and cacheing, just for fun, took it down to 10 seconds.)

	John