Given that the world of PC are heading down the path of muti-cpus:

What features does D supply to take advantage of concurrency, over an above what can be accomplished though C++ today?

How could the language be improved to be better at concurrency problems then other languages?

(You'll not that I left out the word threading as that is only one form of concurrency programming).

-
I'm just thinking that, perhaps if concurrency is handled well enough in D, it can catch the wave of parallel programming that is on the horizon.

janderson wrote:
> Given that the world of PC are heading down the path of muti-cpus:
> 
> What features does D supply to take advantage of concurrency, over an above what can be accomplished though C++ today?

A definition of 'volatile' that works.  I'd say more, but "can be accomplished" is a pretty broad category.

> How could the language be improved to be better at concurrency problems then other languages?

Improved support for advanced concurrency features.  I've seen a test copy of CSP for D, which is a nice start.  And futures wouldn't be very difficult to write in library code.  Really, I think it comes down to finding simpler ways to break up the traditionally sequential nature of imperative code.  A good bit of work still needs to be done here even at the research level, as I haven't seen any solution yet that's without problems.  Oh, software transactional memory might be an interesting experiment as well.

> I'm just thinking that, perhaps if concurrency is handled well enough in D, it can catch the wave of parallel programming that is on the horizon.

I'd be surprised if it didn't.


Sean

janderson Wrote:

> Given that the world of PC are heading down the path of muti-cpus:
> 
> What features does D supply to take advantage of concurrency, over an above what can be accomplished though C++ today?
> 
> How could the language be improved to be better at concurrency problems then other languages?
> 
> (You'll not that I left out the word threading as that is only one form of concurrency programming).
> 
> -
> I'm just thinking that, perhaps if concurrency is handled well enough in
> D, it can catch the wave of parallel programming that is on the horizon.

D should be the language of choice when it comes to concurrency. This the window of opportunity for D. Since none of the currently "popular" languages speaks concurrency fluently.

vtp (vanh@dslextreme.com) 	2006/12/12 17:53
>>janderson Wrote:
>> I'm just thinking that, perhaps if concurrency is handled well enough in D, it can catch the wave of parallel programming that is on the horizon.
>D should be the language of choice when it comes to concurrency. This the window
of opportunity for D. Since none of the currently "popular" languages
>speaks concurrency fluently.

That's the correct timeperiod sure, but the problem is that the 'concurrency' topic is far from being settled, there are so many ways to treat it: threading and locks (don't compose), STM (still a research topic and not a complete solution: it cannot handle side-effect), like in the Concur project active object waiting for future events (the mapping of "future thread" to real thread doesn't seem obvious to me to get good performances), CSP, etc.

renoX

janderson wrote:
> Given that the world of PC are heading down the path of muti-cpus:
> 
> What features does D supply to take advantage of concurrency, over an above what can be accomplished though C++ today?
> 
> How could the language be improved to be better at concurrency problems then other languages?
> 
> (You'll not that I left out the word threading as that is only one form of concurrency programming).
> 
> -
> I'm just thinking that, perhaps if concurrency is handled well enough in D, it can catch the wave of parallel programming that is on the horizon.

I agree that D should have more support for concurrency. Putting some sensible support into the language is FAR better than trying to do it all with libraries.

Graham St Jack wrote:
> janderson wrote:
>> Given that the world of PC are heading down the path of muti-cpus:
>>
>> What features does D supply to take advantage of concurrency, over an above what can be accomplished though C++ today?
>>
>> How could the language be improved to be better at concurrency problems then other languages?
>>
>> (You'll not that I left out the word threading as that is only one form of concurrency programming).
>>
>> -
>> I'm just thinking that, perhaps if concurrency is handled well enough in D, it can catch the wave of parallel programming that is on the horizon.
> 
> I agree that D should have more support for concurrency. Putting some sensible support into the language is FAR better than trying to do it all with libraries.

I think the problem is that this is a developing field, and language additions tend to be somewhat permanent.  Sutter's futures, for example, could benefit from a bit of language support (the active object part), but I'm not convinced the idea is quite "there" yet.  And something like what's in Cilk may be more mature but seems a bit too much for D. Better language support for concurrency will have to be a 2.0 thing, if only to allow more time for experimentation in library code.


Sean

Sean Kelly wrote:
> Graham St Jack wrote:
>> janderson wrote:
>>> Given that the world of PC are heading down the path of muti-cpus:
>>>
>>> What features does D supply to take advantage of concurrency, over an above what can be accomplished though C++ today?
>>>
>>> How could the language be improved to be better at concurrency problems then other languages?
>>>
>>> (You'll not that I left out the word threading as that is only one form of concurrency programming).
>>>
>>> -
>>> I'm just thinking that, perhaps if concurrency is handled well enough in D, it can catch the wave of parallel programming that is on the horizon.
>>
>> I agree that D should have more support for concurrency. Putting some sensible support into the language is FAR better than trying to do it all with libraries.
> 
> I think the problem is that this is a developing field, and language additions tend to be somewhat permanent.  Sutter's futures, for example, could benefit from a bit of language support (the active object part), but I'm not convinced the idea is quite "there" yet.  And something like what's in Cilk may be more mature but seems a bit too much for D. Better language support for concurrency will have to be a 2.0 thing, if only to allow more time for experimentation in library code.
> 
> 
> Sean

This may be the case, however it would be worth investigating other languages (in particular ones designed around concurrency).  Maybe the solution will be a library with D simply providing support to make the library easier to use then it otherwise would be.  I'm not sure. Something I think needs to be discussed.

What are the best and newest parallel languages out there?   What are the most difficult parts to solve?

What are the best libraries?  What are the hardest parts to use in those libraries?

I'm particularly interested if the difficult parts of lockless programming supported in some form.

-Joel

janderson wrote:
> Sean Kelly wrote:
>> Graham St Jack wrote:
>>> janderson wrote:
>>>> Given that the world of PC are heading down the path of muti-cpus:
>>>>
>>>> What features does D supply to take advantage of concurrency, over an above what can be accomplished though C++ today?
>>>>
>>>> How could the language be improved to be better at concurrency problems then other languages?
>>>>
>>>> (You'll not that I left out the word threading as that is only one form of concurrency programming).
>>>>
>>>> -
>>>> I'm just thinking that, perhaps if concurrency is handled well enough in D, it can catch the wave of parallel programming that is on the horizon.
>>>
>>> I agree that D should have more support for concurrency. Putting some sensible support into the language is FAR better than trying to do it all with libraries.
>>
>> I think the problem is that this is a developing field, and language additions tend to be somewhat permanent.  Sutter's futures, for example, could benefit from a bit of language support (the active object part), but I'm not convinced the idea is quite "there" yet.  And something like what's in Cilk may be more mature but seems a bit too much for D. Better language support for concurrency will have to be a 2.0 thing, if only to allow more time for experimentation in library code.
>>
>>
>> Sean
> 
> This may be the case, however it would be worth investigating other languages (in particular ones designed around concurrency).  Maybe the solution will be a library with D simply providing support to make the library easier to use then it otherwise would be.  I'm not sure. Something I think needs to be discussed.
> 
> What are the best and newest parallel languages out there?   What are the most difficult parts to solve?

Very quickly (because I'm exhausted and on my way to bed), I think CSP is the right idea but falls apart in its "sequential" aspect.  Ideally, any concurrent programming approach should apply equally to traditional and to distributed systems in that it shouldn't matter how or where operations are performed so long as they're performed and the program state remains coherent.  ORB architectures (CORBA, DCOM) work along these lines as a library approach, but they put the burden of concurrency on the user much like mutexes and such do for traditional multithreaded programming.  Also, I think a process algebra would be ideal for any such solution to guarantee that a system built on the technique was provable.  And while there does appear to be some current work in the area, who knows how long it will take to bear fruit.

As for parallel languages... I've already mentioned Cilk and think it appears to be pretty decent.  Can't think of any others offhand, though C# has actually proved to be a good platform for experimental language features, because the language is actually extensible in some ways.  In fact, it already has a test version of Sutter's active objects and futures available as well as software-transactional memory, both with some degree of "language support."

> What are the best libraries?  What are the hardest parts to use in those libraries?

ACE is probably the best for C++, though I've used it only sparingly. Not sure about other languages.

> I'm particularly interested if the difficult parts of lockless programming supported in some form.

I'm less interested in details than in the high-level design.  If a library uses lock-free then great, and if it uses something else that's fine too, just as long as it scales appropriately, offers the appropriate progress guarantees, etc.  For example, CSP may be implemented using mutexes, lock-free, etc, but this is all invisible to the user.  He simply knows that tasks are being issued and completed concurrently, and that's all that matters.


Sean