Hidden Overheads (2023)(blog.xoria.org)
blog.xoria.org
Hidden Overheads (2023)
https://blog.xoria.org/hidden-overheads/
5 comments
Only VLIW, where you control instruction scheduling, gives real assurance.
> Locals which the programmer desires to be spilled could be annotated, making the performance cost visible in the source.
> I’ve never heard of anyone asking for such a feature.
Nevertheless we have/had it (for the other way around though): https://en.wikipedia.org/wiki/Register_(keyword)
> I’ve never heard of anyone asking for such a feature.
Nevertheless we have/had it (for the other way around though): https://en.wikipedia.org/wiki/Register_(keyword)
I personally don't think that copy-on-write is problematic. It's deterministic and its overhead depends only on size of the chunk of data to be copied. Stuff like garbage collection or synchronization primitives are for example much less predictable.
Experienced programmers can skip to the conclusion, which (after a brief misstep to say that "accessing memory on the stack is, like any other memory access, O(n), depending on how much memory you access") is basically that the defining characteristic of a systems language is that no built-in operation should take more than O(1).
I mean, sort of. Except that obviously there are operations, like sorting, which necessarily take more than O(1). Suppose we had a language exactly like C except that `sort` was a builtin instead of a library function: would that make it less of a good systems language? Or is there something about spelling the operation "sort" that makes it more acceptable?
Is the ultimate criterion just that everything should have "the right" cost for how it's spelled — or in other words, that operations' costs should be predictable by the systems programmer — or in other words, the language shouldn't behave too weirdly given how it looks — or in other words it should look mostly like C, and the parts that look like C should also behave like C? I think that's a pretty decent criterion, actually.
I mean, sort of. Except that obviously there are operations, like sorting, which necessarily take more than O(1). Suppose we had a language exactly like C except that `sort` was a builtin instead of a library function: would that make it less of a good systems language? Or is there something about spelling the operation "sort" that makes it more acceptable?
Is the ultimate criterion just that everything should have "the right" cost for how it's spelled — or in other words, that operations' costs should be predictable by the systems programmer — or in other words, the language shouldn't behave too weirdly given how it looks — or in other words it should look mostly like C, and the parts that look like C should also behave like C? I think that's a pretty decent criterion, actually.
Once you start to dig into how computer hardware really works, you start to realize that nothing is really O(1).
If you’ve never looked into computer hardware, you’d believe that lots of the primitive machine operations like reading and writing a value are O(1). But on modern hardware, they can be far slower. And that’s before we even get into out of order instructions etc.
So by the authors definition, I guess assembly and machine code aren’t real systems languages ;)
https://queue.acm.org/detail.cfm?id=3212479