Ok, Walter's said previously (I think) that he's going to wait to see what C++ does in regards to multicore concurrency.

Ignoring this for now, for fun, what ideas do you guys have regarding multicore concurrency?

"Denton Cockburn" <diboss@hotmail.com> wrote in message news:pan.2008.02.03.02.33.36.603288@hotmail.com...
> Ok, Walter's said previously (I think) that he's going to wait to see what
> C++ does in regards to multicore concurrency.
>
> Ignoring this for now, for fun, what ideas do you guys have regarding
> multicore concurrency?

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 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.

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.

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.

Regards,
Dan

"Daniel Lewis" <murpsoft@hotmail.com> wrote in message news:fo5vdf$2q2e$1@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 

Denton Cockburn wrote:
> Ok, Walter's said previously (I think) that he's going to wait to see what
> C++ does in regards to multicore concurrency.
> 
> Ignoring this for now, for fun, what ideas do you guys have regarding
> multicore concurrency?

There were two solutions for concurrent programming proposed at the D conference. Walter talked about automatic parallelization made available functional programming styles, which Craig & Daniel are discussing. The other solution presented, which I have seen comparatively little discussion in the NG about, was software transactional memory.

I don't think that STM necessarily leads to simpler or more readable code than lock-based concurrency, however I think STM has two distinct advantages over these traditional methods:
1. possibly better performance
2. better reliability (i.e. no need to worry about deadlocks, etc.)

I think an ideal solution is two combine the two techniques. If functional-style programming is emphasized, and STM is used where state-based programming makes more sense, it frees the programmer to write code without worrying about the complexities of synchronization.

That said, I never found traditional concurrency that hard, especially within frameworks like SEDA, etc.

Robert Fraser wrote:
> Denton Cockburn wrote:
>> Ok, Walter's said previously (I think) that he's going to wait to see
>> what
>> C++ does in regards to multicore concurrency.
>>
>> Ignoring this for now, for fun, what ideas do you guys have regarding multicore concurrency?
> 
> There were two solutions for concurrent programming proposed at the D conference. Walter talked about automatic parallelization made available functional programming styles, which Craig & Daniel are discussing. The other solution presented, which I have seen comparatively little discussion in the NG about, was software transactional memory.
> 
> I don't think that STM necessarily leads to simpler or more readable
> code than lock-based concurrency, however I think STM has two distinct
> advantages over these traditional methods:
> 1. possibly better performance
> 2. better reliability (i.e. no need to worry about deadlocks, etc.)

STM actually offers worse performance than lock-based programming, but in exchange gains a guarantee that the app won't deadlock (though I believe it could theoretically livelock, at least with some STM strategies).  Also it's simply easier for most people to think in terms of transactions.

For the average application, I think it's a preferable option to lock-based programming.  However, I think even STM will only get us so far, and eventually we're going to need to move to more naturally parallelizable methods of programming.  The 'pure' functions and such in D are an attempt to get some of this without losing the imperative syntax that is so popular today.

> I think an ideal solution is two combine the two techniques. If functional-style programming is emphasized, and STM is used where state-based programming makes more sense, it frees the programmer to write code without worrying about the complexities of synchronization.

If we're talking about D, then I agree.

> That said, I never found traditional concurrency that hard, especially within frameworks like SEDA, etc.

Me either, but from what I've heard, this is not typical.

I think the best way to tackle concurrency is to have two types of functions

blocking functions (like in the old sequential code execution)

and non-blocking functions (the new parallel code execution)

for non-blocking functions, the function returns additional type which is true when function execution is completed

for example


a = foo();

// para1_foo and para2_foo are completely independent and executed in parallel

b = para1_foo();
c = para2_foo();

// wait here for both functions to finish
// another syntax could be used also

if (b.done and c.done)
     continue:


I'm not sure about supporting non-pure functions (or allowing accessing global vars); it's just too ugly for no good reason.



Sean Kelly Wrote:

> Robert Fraser wrote:
> > Denton Cockburn wrote:
> >> Ok, Walter's said previously (I think) that he's going to wait to see
> >> what
> >> C++ does in regards to multicore concurrency.
> >>
> >> Ignoring this for now, for fun, what ideas do you guys have regarding multicore concurrency?
> > 
> > There were two solutions for concurrent programming proposed at the D conference. Walter talked about automatic parallelization made available functional programming styles, which Craig & Daniel are discussing. The other solution presented, which I have seen comparatively little discussion in the NG about, was software transactional memory.
> > 
> > I don't think that STM necessarily leads to simpler or more readable
> > code than lock-based concurrency, however I think STM has two distinct
> > advantages over these traditional methods:
> > 1. possibly better performance
> > 2. better reliability (i.e. no need to worry about deadlocks, etc.)
> 
> STM actually offers worse performance than lock-based programming, but in exchange gains a guarantee that the app won't deadlock (though I believe it could theoretically livelock, at least with some STM strategies).  Also it's simply easier for most people to think in terms of transactions.
> 
> For the average application, I think it's a preferable option to lock-based programming.  However, I think even STM will only get us so far, and eventually we're going to need to move to more naturally parallelizable methods of programming.  The 'pure' functions and such in D are an attempt to get some of this without losing the imperative syntax that is so popular today.
> 
> > I think an ideal solution is two combine the two techniques. If functional-style programming is emphasized, and STM is used where state-based programming makes more sense, it frees the programmer to write code without worrying about the complexities of synchronization.
> 
> If we're talking about D, then I agree.
> 
> > That said, I never found traditional concurrency that hard, especially within frameworks like SEDA, etc.
> 
> Me either, but from what I've heard, this is not typical.

Bedros Hanounik wrote:
> I think the best way to tackle concurrency is to have two types of functions
> 
> blocking functions (like in the old sequential code execution)
> 
> and non-blocking functions (the new parallel code execution)
> 
> for non-blocking functions, the function returns additional type which is true when function execution is completed

This is basically how futures work.  It's a pretty useful approach.


Sean

hi,

wouldn't it be okay to do it like in 'Active Oberon' (http://bluebottle.ethz.ch/languagereport/ActiveReport.html) or 'Zennon' (http://www.oberon.ethz.ch/oberon.net/)?



Sean Kelly Wrote:

> Bedros Hanounik wrote:
> > I think the best way to tackle concurrency is to have two types of functions
> > 
> > blocking functions (like in the old sequential code execution)
> > 
> > and non-blocking functions (the new parallel code execution)
> > 
> > for non-blocking functions, the function returns additional type which is true when function execution is completed
> 
> This is basically how futures work.  It's a pretty useful approach.
> 
> 
> Sean

hi,

wouldn't it be okay to do it like in 'Active Oberon' (http://bluebottle.ethz.ch/languagereport/ActiveReport.html) or 'Zennon' (http://www.oberon.ethz.ch/oberon.net/)?



Sean Kelly Wrote:

> Bedros Hanounik wrote:
> > I think the best way to tackle concurrency is to have two types of functions
> > 
> > blocking functions (like in the old sequential code execution)
> > 
> > and non-blocking functions (the new parallel code execution)
> > 
> > for non-blocking functions, the function returns additional type which is true when function execution is completed
> 
> This is basically how futures work.  It's a pretty useful approach.
> 
> 
> Sean