3 ms·

> the unit allocates memory or not, the unit performs in a given worst-case time or not, etc. etc. -- but not everything it could do it also should Strong agre

> the unit allocates memory or not, the unit performs in a given worst-case time or not, etc. etc. -- but not everything it could do it also should Strong agree. This list could also be extended endlessly, and with continuous dimensions: how much L1i/L2i/L1d/L2d/L3 cache does this consume? How many instructions will it generate? For AMD64, ARM? How well can it be reordered wrt this other function? Is it superscalar? It becomes dimensionally intractable, because these properties do interact with each other. IMHO, all side-effects considerations should be (easily) surfaced as hints to the programmer, but not as constraints. At least that's what a language/runtime should aim for. For example: Rust's asyncs can be called synchronously. That's fair enough (and ok), but the programmer should be made aware by the compiler that it will block the thread. To me, the best thing to aim for is a language that gets out of the way (correctness in changing requirements context is difficult enough already), but informs you on what you are trading off. Say your wrote a sequential part. A hypothetical 'parallelization opportunities' tab of your IDE should ask you the question: 'Do your business requirements allow that this part be made parallel?'.

pron 5y ago
Even if you could do it in a non-obtrusive way, I would argue that this is a very wrong direction for many languages. The reason is that the static information is only the worst-case. How much a cache a subroutine consumes is a dynamic property, as is how long it runs or whether or not it blocks a thread. This worst-case information, reflected statically at the language level, is useful only when you're aiming to optimise for the worst-case, as you do in hard realtime domains; in most other domains, you might want to optimise amortised or even average costs. The reason this is being considered for removal is that even though the mechanism is very flexible and powerful in theory, it is too elaborate to be used correctly by most programmers in practice.

pron 5y ago

Even if you could do it in a non-obtrusive way, I would argue that this is a very wrong direction for many languages. The reason is that the static information is only the worst-case. How much a cache a subroutine consumes is a dynamic property, as is how long it runs or whether or not it blocks a thread. This worst-case information, reflected statically at the language level, is useful only when you're aiming to optimise for the worst-case, as you do in hard realtime domains; in most other domains, you might want to optimise amortised or even average costs. The reason this is being considered for removal is that even though the mechanism is very flexible and powerful in theory, it is too elaborate to be used correctly by most programmers in practice.