Yes, which is why I was pointing out that your previous message was not relevant to the discussion at hand. We're talking about loops and you about referential integrity, two things that have nothing in common.
-- Cédric On Thu, Jan 6, 2011 at 10:18 AM, Ricky Clarkson <[email protected]>wrote: > That's not a function with the same input, it's a function with > different inputs. E.g.: > > for (int a = 0; a < 100; a++) > array[a] = a * 2; > > If I extracted a * 2 into a separate method: > > for (int a = 0; a < 100; a++) > array[a] = doubleIt(a); > > there's only one input, and it would be the same if I parallelised that > loop. > > Something like your example: > > int soFar = 0; > for (int a = 0; a < 100; a++) > array[a] = soFar += a; > > Here if I extract a method I get: > > int soFar = 0; > for (int a = 0; a < 100; a++) { > soFar = addSome(soFar, a); > array[a] = soFar; > } > > (eliding soFar is quite easy, but the problem remains) > > This time you aren't calling the same function with the same inputs, > so even though addSome is referentially transparent (i.e., it > describes a function), parallelising it won't work. > > 2011/1/6 Cédric Beust ♔ <[email protected]>: > > > > > > On Thu, Jan 6, 2011 at 10:05 AM, Kevin Wright <[email protected]> > > wrote: > >> > >> > > >> > This seems wrong. Just because the loop seems to be parallelizable > >> > doesn't mean it is. The compiler needs to know whether your iteration > is > >> > ordering sensitive or not ("Is it okay if index 3 is treated before > index > >> > 1?"). This hint is much more meaningful than whether the developer is > using > >> > an index of foreach. The same applies to closures, LINQ or whatever > >> > comprehension walking mechanism you favor. > >> > >> If you have referential integrity (the same function, with the same > input > >> always returns the same value, immutability is important here) and the > >> functions have no side-effects (e.g println) then it's mathematically > >> guaranteed that ordering won't matter. You can still have indices, they > >> just don't need to be processed in-order. > > > > Imagine a loop that calculates the product of several matrices stored in > an > > array. This operation satisfies all your requirements, yet the loop is > not > > parallelizable. > > -- > > Cédric > > > > > > -- > > You received this message because you are subscribed to the Google Groups > > "The Java Posse" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]<javaposse%[email protected]> > . > > For more options, visit this group at > > http://groups.google.com/group/javaposse?hl=en. > > > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<javaposse%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > > -- Cédric -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
