concurrency

Christopher Wright dhasenan at gmail.com
Mon Feb 4 05:39:31 PST 2008


Craig Black wrote:
> 
> "Daniel Lewis" <murpsoft at hotmail.com> wrote in message 
> news:fo5vdf$2q2e$1 at digitalmars.com...
>> Craig Black Wrote:
>>> Walter also has said recently that he wants to implement automatic
>>> parallelization, and is working on features to will support this (const,
>>> invariant, pure).  I think Andrei is pushing this.  I have my doubts 
>>> that
>>> this will be useful for most programs.  I think that to leverage this
>>> automatic parallelization, you will have to code in a functional 
>>> style, or
>>> build your application using pure functions.  Granularity will also 
>>> probably
>>> be an issue.  Because of these drawbacks, automatic parallelization 
>>> may not
>>> be so automatic, but may require careful programming, just like manual
>>> parallelization.  But maybe I'm wrong and it will be the greatest thing
>>> ever.
>>>
>>> -Craig
>>>
>>
>> Craig, I'm not sure if you noticed that AMD and Intel had "HT" for a 
>> long time and are now pushing multicore on desktop users now, as well 
>> as servers.  Const and pure are also relevant to live application 
>> migration, embedded application interfacing, optimization, and debugging.
>>
> 
> Yes everything is going multi-threaded and multi-core.  Any feature that 
> aids programmers in writing multi-threaded software is a plus.  However, 
> I'm skeptical that a compiler will be able to take code that is written 
> without any consideration for threading, and parallelize it.
> 
>> D is moving towards supporting some assertions that data isn't changed 
>> by an algorithm, and/or that it must not be changed.  That doesn't 
>> require any more work than deciding whether something should be 
>> constant, and then making it compile.
> 
> Consider that the compiler is relying on pure functions for 
> parallelization. If (1) the programmer doesn't write any pure functions, 
> or (2) the granularity of the pure function does not justify the 
> overhead of parallelization, then there's no benefit.  Thus, careful 
> consideration will be required to leverage automatic parallelization.

I'm curious how automatic parallelization might work with delegates. It 
probably won't, unless you put the 'pure' keyword in the signature of 
the delegates. In that case, I hope that pure delegates are implicitly 
convertible to non-pure delegates.

I was wondering because I work with a highly event-driven application in 
C# that might benefit from automatic parallelization, though some event 
subscribers probably modify data that they don't own.



More information about the Digitalmars-d mailing list