It's ironic that Musks two big successes were funded by the Obama administration against vehement Republican objections. Shelby repeatedly tried to kill Space-X and without the $400million DOE loan Tesla would never have been able to start production - and without the electric car tax credit - it never would have been able to sell.

The interdata was a strange machine architecture - before the era where everything started to look the same. Via Wikipedia: https://books.google.com/books?id=pWBoOXVjuZ0C&dq=%227%2F32%...

It's interesting how often people repeat this argument as if it were persuasive. The compiler developers and Standards writers made an engineering decision which is hard to justify so most people who support it don't even try.

Good explanation of my overly terse note. The current standard interrupt architecture imposes enormous latency and the synchronous timer could be more precise. The simplest implementation would just "fetch" jmp every N instructions (with N programmable) - just like voluntary switching but where the processor would volunteer the program.

You still need to save the PC and have a place to save it ....

A) there is no evidence such phenomena - especially in net- are due to unsafe optimizations, b) those companies dont need to shift their costs to other users

Your argument would be more compelling if programming languages with higher level iteration primitives were significantly more optimizable than C. The underlying processor architectures have loop indexes. Just pretending you can do applicative programming doesn't mean you can. C is very adaptable - even to GPUs. Also, I have yet to see that decent memory model.

> C is very adaptable - even to GPUs.

Can you expand on this? I've never heard of someone seriously running actual C on a GPU.

I doubt that very much, and one of the points of the article is that there is a shortage of data to back up claims like yours.

In any case, for people who want to write OS or cryptography or embedded systems or arithmetic libraries or ... in C, this is not a relevant point.

You doubt it because you aren't a compiler developer, so you aren't aware of the history. Try taking some of the classic Fortran scientific programming libraries, such as LAPACK, recoding them in C, and then see what happens when you need to generate code with a compiler that doesn't do any of the optimizations the article complains about and has no undefined behavior. Then you'll figure out why.

You still don't have any data.

You're the one arguing for a change to the status quo, the burden of proof is on you.

My understanding is the reason FORTRAN is faster than C isn't because of stupid stuff like noalias and the like. It's because FORTRAN has arrays and C doesn't.

You're right, sort of. Because C doesn't have proper arrays, you make up for it by passing a pointer to the first element and the range. So for C to do as well as Fortran on matrix operations the compiler developers need help. One source of help is that if you have a pointer to double and a pointer to int, you can assume that writing pdouble[k] doesn't alter anything reachable as pint[m].

It's because C has pointers and FORTRAN doesn't and pointers are a pain for certain types of optimization.

Why would that put C at a disadvantage performance-wise? Array decay is, with hindsight, an unfortunate feature, but optimizing access to contiguous memory is very low-hanging fruit as far as compiler optimizations go.

Some optimizations are low-hanging fruit only if you know length of the array. Which C avoids by design at all costs.

If you want better safety, runtime and compile time performance the lowest hanging fruit would be to fire the C standards committee and hard fork C++/C into C++ and C only ecosystems.

There was no size_t in K&R1. Size_t was introduced in the standards process as was the definition of index variables in the for loop. You may have a complain with the standard there.

As for the optimization, it is based on misunderstanding of C semantics. The only place where the sign extend makes a difference is where pointers are longer than "ints" AND where the the iterator can overflow, and in that case, sign extend only makes a difference if the loop is incorrectly coded so that the end condition is never true. The code should just provoke a warning and then omit the sign extend (and it almost certainly doesn't make much of a difference since sign extend is highly optimized and has zero cost in a pipelined processor).

> There was no size_t in K&R1. Size_t was introduced in the standards process as was the definition of index variables in the for loop. You may have a complain with the standard there.

I certainly do. C and descendants makes you over-specify variables by declaring them all int/size_t/etc individually. It should've had C++11-style "auto" from the start and there should be a statement like "for i=0..n" that declares "i" the same type as "n".

Nobody claims optimizations are not important.