vyodaiken

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.

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

You still don't have any data.

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

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.

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.

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

It is because they are "free" and also because they attract massive investment from FAANG and National Labs etc.

Nobody claims optimizations are not important.

Maybe you should tell the Linux developers that they are making a mistake.

if it was a randomly selected function, which it is not.

The most interesting thing is that his critique of Pascal type rigidity applies to C Standard C, which is very different from C.

This proposal is moving through the C standards process and I was curious about whether people think it is a good idea. It appears to have a lot of backing in the Committee ( I am dubious, but I think I am in the minority).

If there is interest, I will also publish links to other proposals that are moving forward in the C23 process.

Send Linux Torvalds a note and tell him he has only superficial knowledge of C.

FYI https://www.yodaiken.com/2021/05/21/your-computer-is-a-fast-...

The problems with that argument are 1) The expectations changed with no notice. You can say it always was that way, but that's just not correct. The bounds check worked and then didn't, no matter what you think the standard "always said" (and the UB experts on the WG14 often find it impossible to say exactly what provisions mean, so claims that all this was ever clear are also wrong.) 2) deleting overflow check reduces the power of the language. The supposed work arounds are painful and have edge cases. 3) the example, and others, show that much UB "we assume it can't happen" "optimization" is unnecessary. You make the language more difficult to use, more prone to unpleasant surprise, and in return you provide an "optmization" that could easily be produced by other means. You're insisting on using a hammer as a fork and annoyed when people don't find it convenient.

It is impossible to write C applications without invoking UB and your theory that UB behavior had no semantics is nonsensical. It may have no semantics that compilers currently feel they need to keep stable, but code that compiles and runs has semantics.

I am sorry to say, I do not have a good short reference. There has to be one, though, I hope. The Hennesey Patterson books are the standard intros.

ILP, sheesh