View mode: basic / threaded / horizontal-split · Log in · Help
February 03, 2008
concurrency
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?
February 03, 2008
Re: 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
February 04, 2008
Re: concurrency
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
February 04, 2008
Re: concurrency
"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
February 04, 2008
Re: concurrency
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.
February 04, 2008
Re: concurrency
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.
February 04, 2008
Re: concurrency
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.
February 04, 2008
Re: concurrency
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
February 04, 2008
Re: concurrency
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
February 04, 2008
Re: concurrency
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
« First   ‹ Prev
1 2 3
Top | Discussion index | About this forum | D home