Yet another strike against the current AA implementation

[downs]

Daniel Keep wrote:
> 
> Michel Fortin wrote:
>> On 2009-04-27 10:51:22 -0400, Frits van Bommel
>> <fvbommel at REMwOVExCAPSs.nl> said:
>>
>>> I edited this code to work with ldc (D1) + Tango, and saw the Direct
>>> and opApply cases generate identical code (inc, cmp, jne, with the
>>> loop counter in a register) [1], so they're equally fast (modulo
>>> process scheduling randomness).
>> Thank you for your timings. I think it shows my point: that by prefering
>> ranges over opApply we're just optimising around a deficiency in DMD's
>> optimizer.
> 
> Not true.  Here's an excellent reason to use ranges over opApply: you
> can't define zip with opApply.  Because opApply uses inversion of
> control, you can't use more than one without bringing threads into the
> equation.
> 

Your point stands, of course, but I just wanted to mention that stackthreads/fibers work too and have far less overhead.

>> I'm thinking... with proper inlining, perhaps we could take the notion
>> of ranges out of the compiler and just define a generic opApply in
>> std.range that use front, popFront, and empty. :-) Perhaps.
> 
> I suspect supporting ranges is just much easier.
> 
>   -- Daniel