Walter Bright Wrote:
> Since then I have tried to master this topic, but I don't have much experience writing complex multithreaded code. So what we need are people who are experienced with MT code who can evaluate the design to see if we missed the boat or not. I'd rather not shoot at the moon yet wind up orbiting some asteroid.

Walter,

How would you characterize D1.0 in terms of it's use for big multithreaded applications?   Does the compiler produce safe/performant code?

Thanks,
Brien

Walter Bright <newshound1@digitalmars.com> writes:

> The failed Java concurrency model is an example of this shortage.

Can you elaborate? Are you talking pre-JSR-000133¹?


Footnotes: ¹ http://jcp.org/aboutJava/communityprocess/review/jsr133/index.html

-- 
Steven E. Harris

Fri, 08 Jan 2010 00:50:26 -0800, Walter Bright wrote:

> Michel Fortin wrote:
>> Also keep in mind that we don't really need a shared vision among everyone. What's needed is someone who takes the decisions. Discussion is only needed to help that person take the right decisions. Although consensus among all members certainly boosts the decider self-confidence, it is not required, and not necessarily desirable either. A consensus among only a few key people is all that is needed, and this has little to do with who is allowed to raise issues and propose solutions.
> 
> The real problem with a concurrency model is that very few programmers understand the issues. The failed Java concurrency model is an example of this shortage. For another, about 5 years ago I attended a panel of 30 of the top C++ experts in the world to discuss a concurrency model for C++0x.
> 
> It didn't take long for it to become obvious that exactly two people understood the issues - Hans Boehm and Herb Sutter. The rest of us sat there slack-jawed and drooling, asking endless inane questions. I wish I had the patience Hans and Herb showed in dealing with this.
> 
> Since then I have tried to master this topic, but I don't have much experience writing complex multithreaded code. So what we need are people who are experienced with MT code who can evaluate the design to see if we missed the boat or not. I'd rather not shoot at the moon yet wind up orbiting some asteroid.

If only 2 of the top 30 c++ experts understand concurrency models, what makes you think that D programming community, mostly consisting of novice/ hobbyist/student programmers have any better luck? There are only a handful of such experts as Sean, Andrei, Bartosz, Brad et al here. The D community is maybe 3 to 4 orders of magnitude smaller than the global C++ community. Only a handful of enterprises use D and there is basically no academic research happening around D.

retard wrote:
> Fri, 08 Jan 2010 00:50:26 -0800, Walter Bright wrote:
> 
>> Michel Fortin wrote:
>>> Also keep in mind that we don't really need a shared vision among
>>> everyone. What's needed is someone who takes the decisions. Discussion
>>> is only needed to help that person take the right decisions. Although
>>> consensus among all members certainly boosts the decider
>>> self-confidence, it is not required, and not necessarily desirable
>>> either. A consensus among only a few key people is all that is needed,
>>> and this has little to do with who is allowed to raise issues and
>>> propose solutions.
>> The real problem with a concurrency model is that very few programmers
>> understand the issues. The failed Java concurrency model is an example
>> of this shortage. For another, about 5 years ago I attended a panel of
>> 30 of the top C++ experts in the world to discuss a concurrency model
>> for C++0x.
>>
>> It didn't take long for it to become obvious that exactly two people
>> understood the issues - Hans Boehm and Herb Sutter. The rest of us sat
>> there slack-jawed and drooling, asking endless inane questions. I wish I
>> had the patience Hans and Herb showed in dealing with this.
>>
>> Since then I have tried to master this topic, but I don't have much
>> experience writing complex multithreaded code. So what we need are
>> people who are experienced with MT code who can evaluate the design to
>> see if we missed the boat or not. I'd rather not shoot at the moon yet
>> wind up orbiting some asteroid.
> 
> If only 2 of the top 30 c++ experts understand concurrency models, what makes you think that D programming community, mostly consisting of novice/
> hobbyist/student programmers have any better luck? There are only a handful of such experts as Sean, Andrei, Bartosz, Brad et al here. The D community is maybe 3 to 4 orders of magnitude smaller than the global C++ community. Only a handful of enterprises use D and there is basically no academic research happening around D.

Our flagship for communicating across concurrent entities is message passing, which is much more palatable than classic share-the-world concurrency models.

I'm very excited about how this is coming together.


Andrei

Brien wrote:
> How would you characterize D1.0 in terms of it's use for big
> multithreaded applications?   Does the compiler produce
> safe/performant code?

D 1.0 is about where Java is in its support for MT programming. You can
do it, but you get little or no support from the type system.

Steven E. Harris wrote:
> Walter Bright <newshound1@digitalmars.com> writes:
> 
>> The failed Java concurrency model is an example of this shortage.
> 
> Can you elaborate? Are you talking pre-JSR-000133¹?
> 
> 
> Footnotes: ¹ http://jcp.org/aboutJava/communityprocess/review/jsr133/index.html
> 


In Java, you can share data between threads without restriction. Hence, code is vulnerable to all the sequential consistency bugs.

retard wrote:
> If only 2 of the top 30 c++ experts understand concurrency models, what makes you think that D programming community, mostly consisting of novice/
> hobbyist/student programmers have any better luck?

That is why the flagship of doing concurrency in D will be message passing, which is how Erlang, Scala, and Go do concurrency. Using message passing will avoid any need by the user to understand sharing, sequential consistency, and synchronization issues.

Sharing and synchronization will be for the advanced programmer.


> Only a handful of enterprises use D and there is basically no academic research happening around D.

That'll change!

Fri, 08 Jan 2010 12:33:06 -0800, Walter Bright wrote:

> retard wrote:
>> If only 2 of the top 30 c++ experts understand concurrency models, what makes you think that D programming community, mostly consisting of novice/ hobbyist/student programmers have any better luck?
> 
> That is why the flagship of doing concurrency in D will be message passing, which is how Erlang, Scala, and Go do concurrency. Using message passing will avoid any need by the user to understand sharing, sequential consistency, and synchronization issues.
> 
> Sharing and synchronization will be for the advanced programmer.

My point was, what makes D community members more capable of reasoning about these issues. I bet it's obvious to the top 30 C++ experts that other kinds of concurrency models exist than multi-threaded shared memory abstraction or SIMD. The problem isn't just about coming up with a model -- if it helps you in any way, go ahead and browse old academic papers. E.g. CSP was invented 32 years ago.

There are message passing libs for C++, too, for instance MPI. Making the feature built-in doesn't automatically make creating concurrent applications easier. For instance message passing is harder to use than implicit parallelism and auto-vectorization when doing parallel processing in loops.

retard wrote:
> My point was, what makes D community members more capable of reasoning about these issues.

Nothing. What makes D special, though, is better language support for sound concurrent programming. But you'll still need a mental model of what's going on, just like you cannot program very successfully in C if you have no mental model of what a pointer is.

> I bet it's obvious to the top 30 C++ experts that other kinds of concurrency models exist than multi-threaded shared memory abstraction or SIMD. The problem isn't just about coming up with a model -- if it helps you in any way, go ahead and browse old academic papers. E.g. CSP was invented 32 years ago.
> 
> There are message passing libs for C++, too, for instance MPI. Making the feature built-in doesn't automatically make creating concurrent applications easier.

Yes it does. C++'s (and Java's, Scala's, and Go's) gaping problem is there's no way to ensure that you don't have implicit sharing going on. In D, such can be guaranteed.

> For instance message passing is harder to use than implicit parallelism and auto-vectorization when doing parallel processing in loops.

Sure. Except that implicit parallelism is inherently unsound unless the type system can support it.

I'll go further than that. Any language that supports implicit sharing of mutable data is inherently unsound for multithreaded programming.

== Quote from Walter Bright (newshound1@digitalmars.com)'s article
> Sure. Except that implicit parallelism is inherently unsound unless the
> type system can support it.
> I'll go further than that. Any language that supports implicit sharing
> of mutable data is inherently unsound for multithreaded programming.

One thing that I think needs to be considered in the concurrency architecture is
the case of performance-critical massive data parallelism.  In these cases
concurrency is actually not very hard and a simple parallel foreach loop covers a
lot of cases.  As far as safety, the amount of code being executed inside a
parallel foreach loop is generally small enough that it's easy to reason about,
and thus it's ok not to have any hard static guarantees and leave safety up to the
programmer, as long as the programmer understands at least the basics of concurrency.

I would like to see a situation where OpenMP/ParallelFuture-style concurrency is still implementable in D without unreasonable performance or syntactic overhead after the new concurrency system is fully in place.