The Next Mainstream Programming Language: A Game Developer'sPerspective :: Redux

[Pragma]

Sean Kelly wrote:
> Pragma wrote:
>>
>> I really think that we have the tools we need If we were to teach the 
>> compiler how to perform some calculus on data structures when their 
>> handled in iteration, it's reasonable to assume that it can take steps 
>> to parallelize things for us - this would get us about half-way to the 
>> kind of stuff functional languages can pull off.  The D2.0 additions 
>> for invariance and const-ness will probably help here.
> 
> Hm...  I guess the purpose would be some sort of optimal COW mechanism 
> for shared data, or is there another use as well?  It's an intriguing 
> idea, though I wonder if such a scheme would make the performance of 
> code difficult to analyze.
> 
> 
> Sean

Your guess is as good as mine.  I was just making the observation that the major hurdle is that we're adopting 
techniques that are deliberately explicit, to overcome the fact that the D compiler is unaware of the problem; the 
degree of specificity that is required can be very unwieldy.  In contrast, the clear winners in this area are languages 
that are /implicitly/ paralellizable by design, so clearly we need to move in that direction instead. :)

Really, what I'm thinking of is a way to say "give me your best shot, or tell me why you can't parallelize this".  The 
parallel() suggestion for foreach (I forgot by who) is a good example of this.  Adding a "shared" modifier for classes 
and typedefs might be another.

Like you suggest, a modified CoW would be a good start.  At a minimum, if the GC were more thread aware, we could do 
smarter things inside and outside the compiler.

-- 
- EricAnderton at yahoo