On Friday, 20 September 2013 at 16:28:49 UTC, Joseph Rushton
Wakeling wrote:
I wouldn't single out DMD for criticism -- I don't know to what
extent the underlying reasons overlap, but all the compilers
cope less well with range-based material than they might in
theory.
The canonical example would be something like,
foreach (i; iota(10)) { ... }
which in theory shouldn't be any slower than,
foreach (i; 0 .. 10) { ... }
but in practice is, no matter what the compiler.
Chandler made a talk about missed optimization opportunities in
LLVM some time ago visible here
http://llvm.org/devmtg/2013-04/videos/carruth-hires.mov
You may also want to look at that one for some basics before :
http://www.youtube.com/watch?v=eR34r7HOU14
What happen with range is that they do not fit that model
properly. Range code often look like a tree (front calling
subrange.front, popFront call subrange.popFront, etc . . .). At
each inlining, front/popFront and firend become bigger and bigger
to the point they aren't good inlining candidate. The compiler do
not see that everything cancels out at the end.
The other big performance pitfall in LLVM with range are bug in
the optimizer when it comes to aggregate store/load. I reported
some of these and LLVM team seems willing to get rid of them
because a lot of frontend generate them (notably gcc frontend).
clang do not use them, so they got less attention in the first
place.
