concurrency

Craig Black craigblack2 at cox.net
Sun Feb 3 19:25:14 PST 2008


"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 really have no idea what the approach will be for parallelization, but 
> if Walter's waiting for C++ to figure it out then it'll be better than 
> what they have.

I guess we can wait and see what happens.  It just seems that everyone is 
anticipating a silver bullet that may never arive.

-Craig 




More information about the Digitalmars-d mailing list