Re: [TUHS] PDP-11 legacy, C, and modern architectTures

[Steffen Nurpmeso <steffen@sdaoden.eu>]

Theodore Y. Ts'o wrote in <20180627021843.GA31920@thunk.org>:
  ...
 |There is at least one of his points that I very much agree with, which
 |is the abstract model which is exported by the C programming paradigm
 |is very different from what totality of what the CPU can do.  Consider
 ...
 |That saying is essentially telling us that the compiler is capable of
 |doing a lot of things behinds our back (which goes against the common
 |understanding of what low-level language does), and second, that
 |modern CPU's has gotten too complicated for most humans to be able to
 |program directly, either comfortably or practically.
 ...
 |It's very easy to criticize Intel for engineering their CPU's the way
 |they did, but if you want to know who to blame for massively high
 |ILP's and caching, and compilers that do all sorts of re-ordering and
 |loop rewriting behind the developer's back, just look in the mirror.
 |It's the same as why we have climate change and sea level rise.
 |
 |"We have met the enemy and he is us". -- Pogo (Walt Kelly)

And my thinking is that the C language has been misused.  If you
can cast in stone a language policy that then allows compilers to
apply optimization X, and it gains your product ten percent
performance without the necessity to spend a single minute payed
manpower.

But even otherwise.  For example loop unrolling -- how could
a compiler know whether i want a loop to become unrolled or not?
It may have very clever heuristics, but despite that these have to
become coded themselves, they will not know whether i have the
desire to make this piece of code fast or not, shall it ever
execute.

In my opinion this "giving away decisions to the compiler" made
the C language worse, not better.  I think it would be better if
one could place attributes, like @unroll, @inline (since inline is
only a hint and placing not-to-be-inlined after their use cases
does not matter to intelligent CCs: @no-inline would be needed),
@prefetch[[X]], and @parallel.  And @align[[X]] and all these.
"@parallel @unroll for(;;)" could for example automatically split
a loop into X subranges.  Or it could hint secure prediction.  Or
at least indicate the programmer's intention or clearance of that,
if the hardware is capable.  And a good compiler could indicate
whether the desire could ever be fulfilled or not.  This looks
like the Julia language, but there these are user-defined "macros"
not compiler hints.  I mean, at least until quantum computers
happen C seems to map to what i know about hardware pretty good.
It is up to the programmer to localize data and avoid that threads
trumple on each other.  It is not so easy as if the language
offers a completely asynchronous shot with a single operator, but
in an ideal world you can get the same with a much smaller
footprint.

Unfortunately what you say seems to be right, and recalling what
the largest German computer magazine had to say about compilers,
it was mostly a series of graphs indicating the speed of the
generated code.  Whereas i had to deal with working around
compiler bugs for the same (free) CCs at the same time.  (Of
course, or maybe not of course, people did care to get them fixed,
but the story was not about "the walk", but what the eagles saw.)
There were two or three large interesting articles with quite some
context (except Mr. Stiller's "Prozessorgeflüster"; i recall he
once won a bottle of wine from some Intel manager), about at the
same time, one about the ARM architecture, one accompanying Donald
Knuth's 64th birthday regarding MMIX, and if you want one about
Smalltalk.  And indeed most think it is all about education,
despite the fact that each epoch seems to end regardless what you.
It has always been the fight to make people reflect, realize, and
be good with it.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)