On Sun, 01 Mar 2009 21:25:10 +1300, Daniel Keep
<daniel.keep.li...@gmail.com> wrote:
Tim M wrote:
Through out that page it shows examples of iterations where order is not
actually defined, the index has to modify by one but it gives the
compiler the ability to create a few threads and execute in parallel.
Thats what I was actually talking about. I would hate for that code to
be valid and would prefer to use the usual while, do while, for and
foreach loops but have an attribute to enable optimization eg:
unordered for(i = 0; i < 10; ++i)
{
//anything here is independant of the previous iterations
//and I dont care if compiler splits accross cpu cores
}
Anyway I still think there is of low priority over other things like
cent data type but it is rated rather high.
C-style for is a pretty terrible construct for this. How can it be
unordered when you've SPECIFIED that i increases linearly?
Compilers are intelligent.
Does that mean it's equivalent to this?
unordered for(i = 9; i >= 0; --i)
{
...
}
If so, then 60% of that statement is redundant. So let's try using
foreach instead.
unordered foreach( i ; 0..10 )
{
...
}
Much better. But now the compiler has to prove that it's actually
possible to run this in arbitrary order.
The idea is that iteration two doesnt have to come after 1 as you specify
to the compiler that it doesnt matter. You are also adding extra syntax
and it would be best if D didn't do that because before you know it will
become to ambiguous to the compiler, not saying that alone is ambiguous
though.
The easiest way to do this is
to check to see whether the body of the foreach is pure or not. Problem
there is that it CAN'T be pure; if it's pure, then the loop cannot
produce any results.
Pure shouldn't be required. If you need you can put you locks in place but
pure is too restricted. Anyway pure is so the compiler can parralise
anyway. Most of the need for pure is that parralel will be there
automatically by default.
