3 ms·
It's a serious problem in compiler optimization. In the ideal world, a program with loop unrolling and vectorization should always be faster, but in practice, t
by segfaultbuserr 8y ago
It's a serious problem in compiler optimization. In the ideal world, a program with loop unrolling and vectorization should always be faster, but in practice, the bigger binary size induces cache misses and may produce a slower problem. Time goes by, and compilers keep adding increasingly complex techniques based on space/time tradeoffs, making the problem trickier.
Historically, under some circumstances, a problem compiled with -Os, may paradoxically be faster than -O2, and -O2 may be faster than -O3. I think the situation is getting better now, and the optimizing level mostly works as advertised. But there's still some problems in automatic loop vectorization.
- greglindahl 8y agoWhat's the paradox? The compiler simply can't tell.
- 0815test 8y ago> In the ideal world, a program with loop unrolling and vectorization should always be faster, but in practice, the bigger binary size induces cache misses and may produce a slower problem. The solution is to use abstract, arbitrary vectors in the ISA instead of packed SIMD and unrolled loops. RISC-V gets this right with their V extension.
- greglindahl 8y agoThere are many different kinds of loop unrolling, and RISC-V's V extension is not the only one. Itanium had the same issue: the loop unrolling assist in the instruction set was not viewed by many compiler people as being sufficient.
- colejohnson66 8y agoForwardCom has abitrary length vector support. http://www.forwardcom.info/ http://www.forwardcom.info/ https://news.ycombinator.com/item?id=19340267 https://news.ycombinator.com/item?id=19340267