3 ms·
It's a hard problem because the cost model is incredibly complicated. For example: you decide to unroll/inline/vectorize code has unpredictable effect on perfo
by fooker 1y ago
It's a hard problem because the cost model is incredibly complicated.
For example: you decide to unroll/inline/vectorize code has unpredictable effect on performance.
- bell-cot 1y agoOr worse - it has perfectly predictable effects on the performance...so long as you know details (core counts, cache sizes, etc.) of the CPU model and dataset which your code will be run on, and the TLB/cache/fabric/memory usage pattern of other jobs which might be running at the same time.
- fooker 1y agoNo, maybe you misunderstand the problem here? Given a specific program, yes it is measurable and predictable. A compiler has to deal with arbitrary programs, actually - small fragments of arbitrary programs at a time. Even if you could have an oracle giving you very precise measurements for the program fragment the compiler is dealing with, it won't hold up in practice. Consider a small representative example. Suppose the compiler is compiling a function, and it did the best possible job. Now, inlining this function at two callsites could have completely different second order effects like further optimizations, register pressure. There are partial solutions of course, people have spent their entire careers dealing with this specific problem. Rest assured that whatever you can come up with after thinking for a minute has been tried in 1970.
- fancyfredbot 1y agoI think OP was agreeing with you.
- fooker 1y agoMy point was - even if you knew everything about the hardware and could measure performance with absolute precision, it is still a hard problem for compilers for many many reasons.