Re: Computer architects leaving Intel...

On Sat, 31 Aug 2024 21:01:54 +0000, Bernd Linsel wrote:

On 31.08.24 21:08, Thomas Koenig wrote:

Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
>

Of course the fans of compilers that do what nobody means found a
counterargument long ago: They claim that compilers would need psychic
powers to know what you mean.

>
Of course, different compiler writers have different opinions, but
what you write is very close to a straw man argument.
>
What compiler writers generlly agree upon is that specifications
matter (either in the language standard or in documented behavior
of the compiler).  Howewer, the concept of a  specification is
something that you do not appear to understand, and maybe never
will.
>
An example: I work in the chemical industry.  If a pressure vessel
is rated for 16 bar overpressure, we are not allowed to run it at
32 bar. If the supplier happens to have sold vessels which can
actually withstand 32 bar, and then makes modifications which
lower the actual pressure the vessel can withstand only 16 bar,
the customer has no cause for complaint.
>
As usual, the specification goes both ways:  The supplier
guarantees the pressure rating, and the customer is obliged
(by law, in this case) to never operate the vessel above its
pressure rating.  Hence, safety valves rupture discs.

>
You compare apples and peaches. Technical specifications for your
pressure vessel result from the physical abilities of the chosen
material, by keeping requirements as vessel border width, geometry etc.,
while compiler writers are free in their search for optimization tricks
that let them shine at SPEC benchmarks.

A pressure vessel may actually be able to contain 2× the pressure it
will be able to contain 20 after 20 years of service due to stress
and strain acting on the base materials.
Then there are 3 kinds of metals {grey, white, yellow} with different
responses to stress and induced strain. There is no analogy in code--
If there were perhaps we would have better code today...

I personally write most code as in the days I learned C, where compilers
where literally too dumb to remember what they did 2 source lines ago,
so you could not rely on the compiler doing the "right thing" -- same as
nowadays, but because of other reasons.

I do too.

So the things that Anton mentioned -- using size_t (or suitable other
unsigned types) for iteration variables, pulling invariants out of
loops, and many more common optimizations -- can still be found in my
source codes.

The modern change is that "int" is no longer the fastest integral
type {which it was guaranteed to be in the days I learned C}.

PS: I find -fno-strict-overflow and -fno-strict-aliasing of value, too,
while I found that -fdelete-null-pointer-checks together with
-Wnull-pointer-dereference has some utility.