Yet another strike against the current AA implementation

[Michel Fortin]

On 2009-04-28 06:33:13 -0400, Daniel Keep <daniel.keep.lists at gmail.com> said:

> 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.

I guess I removed too much context from the above posts. We're just 
timing various foreach implementations.

You're right when you say ranges are more versatile than opApply, and 
I'm all for keeping both ranges and opApply. I just want the compiler 
to prefer opApply over ranges when both are available when generating 
code for foreach, since with opApply you sometime can optimize things 
in a way that that you can't with ranges.


>> 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.

Sure, especially since they're already implemented in the compiler. 
Inlining of delegates known at compile-time would have a greater reach 
though.


-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/