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

I wanted to show that we don't need UB justified deletes to get good code generation. There was no need to break all that working code when we could have just told people that size_t counters worked better in loops on x86-64 than ints. A lot of C optimization could work that way - relying on cooperation between the compiler and programmers. Java can't do that because Java programmers rely on complex abstractions that need a lot of compiler work to run fast.

Nobody knows UB rules. The WG14 discussions are full of confusion.

Fixed it, but same kind of result

https://gcc.godbolt.org/z/hx1zjE5xW

That is completely false. Look up "restrict" and there are many other contexts. BTW, "prove" and "assume" are different things. This is an old argument, which in a just world would have been settled by Dennis Ritchie's comments.

the offset is used to compute the index, not the count.

It's not an interesting optimization. Micro-benchmarks are of limited utility. The extra complication is to protect the code from flying off and writing on random memory. Well worth it.

You are being snide and inaccurate. Studies show 80% or more of GCC optimization improvements come from the core simple methods. Trying to compensate for the lack of data to support your argument by claiming (falsely) it's taught in an elementary course is weak.