On Sat, 21 Nov 2009 20:21:54 +0000 (UTC), dsimcha <dsim...@yahoo.com>
wrote:
>> I guess it is possible:
>> uint[] numbers = new uint[1_000];
>> pool.parallel_each!((size_t i){
>> numbers[i] = i;
>> })(iota(0, numbers.length));
>> Though I agree it's not as cute but it is faster since the delegate is
>> called directly. Or did I miss something?
>
>I'm sorry, but I put a lot of work into getting parallel foreach working, and I
>also have a few other pieces of code that depend on opApply and could not
>(easily)
>be rewritten in terms of ranges. I feel very strongly that opApply and ranges
>accomplish different enough goals that they should both be kept.
Nothing to be sorry about. I was replying to your statement that
parallel foreach cannot be implemented in terms of ranges.
>
>opApply is good when you **just** want to define foreach syntax and nothing
>else,
>with maximum flexibility as to how the foreach syntax is implemented. Ranges
>are
>good when you want to solve a superset of this problem and define iteration
>over
>your object more generally, giving up some flexibility as to how this iteration
>will be implemented.
>
>Furthermore, ranges don't allow for overloading based on the iteration type.
>For
>example, you can't do this with ranges:
>
>foreach(char[] line; file) {} // Recycles buffer.
>foreach(string line; file) {} // Doesn't recycle buffer.
Ok
>
>They also don't allow iterating over more than one variable, like:
>foreach(var1, var2, var3; myObject) {}
I guess it is a relatively rare case. And you can always provide a
range returning a tuple.
foreach(r; myObject.range) { writeln(r.front.var1, r.front.var2,
r.front.var3); }
The common case of iterating over index and value of a random access
range should be supported by foreach.
>
>Contrary to popular belief, opApply doesn't even have to be slow. Ranges can
>be
>as slow as or slower than opApply if at least one of the three functions
>(front,
>popFront, empty) is not inlined. This actually happens in practice. For
>example, based on reading disassemblies and the code to inline.c, neither
>front()
>nor popFront() in std.range.Take is ever inlined.
I think that is a problem with the compiler, not ranges.
> If the range functions are
>virtual, none of them will be inlined.
Ok
>
>Just as importantly, I've confirmed by reading the disassembly that LDC is
>capable
>of inlining the loop body of opApply at optimization levels >= O3. If D
>becomes
>mainstream, D2 will eventually also be implemented on a compiler that's smart
>enough to do stuff like this. To remove opApply for performance reasons would
>be
>to let the capabilities of DMD's current optimizer influence long-term design
>decisions.
>
Convinced. Let's keep opApply.
