With the major CPU players heading towards multi-core devices, multi-threaded software is gonna' become much more commonplace. It's great that D already has some thread-awareness built-in, such as the synchronized keyword. How about some others? For example, Occam was a killer language for parallel development; it had constructs like par(;;){} which is akin to for(;;){} but performed each loop instance in parallel where it could.

Just thought I'd try to get the ball rolling here ...

On Wed, 10 Mar 2004 16:43:17 -0800, "Kris" <someidiot@earthlink.net> wrote:

>With the major CPU players heading towards multi-core devices, multi-threaded software is gonna' become much more commonplace. It's great that D already has some thread-awareness built-in, such as the synchronized keyword. How about some others? For example, Occam was a killer language for parallel development; it had constructs like par(;;){} which is akin to for(;;){} but performed each loop instance in parallel where it could.
>
>Just thought I'd try to get the ball rolling here ...

Occam - oh that brings back the memories! I remember programming 16 transputers run by a mac for various dynamical system simulations and trying to use Occam but ended up using C and assembly for more speed and interfacing with the host. I think it was a T800.

In the back of my mind I want to use D's pragmas to support OpenMP
http://www.openmp.org.
That would be very very cool.

-Ben

That doesn't sound like a bad idea.  Really it's just a for loop that provides
some extra information to
the compiler: that the loops are not required to be executed in order.  If they
don't have to be done in
order, an intelligent compiler could try to optimize it for parallelization.

Personally, I'd say go ahead and add something like it even if the compiler just
treats it like a for loop
for now.  Who knows?  Once GDMD gets far enough along, maybe someone will hook
up a parallelizing
backend to it.

The point is that by allowing the programmer to provide slightly more
information to the compiler (the
fact that the order of the loops doesn't matter), you're leaving the door open
for future optimizations.
Sure, the current compiler could safely ignore that extra information and treat
it as a for loop, but the
hypothetical D compiler of the future might be able to use that information to
its optimizational
advantage.

Owen

In article <c2oc9r$9m$1@digitaldaemon.com>, Kris says...
>
>With the major CPU players heading towards multi-core devices, multi-threaded software is gonna' become much more commonplace. It's great that D already has some thread-awareness built-in, such as the synchronized keyword. How about some others? For example, Occam was a killer language for parallel development; it had constructs like par(;;){} which is akin to for(;;){} but performed each loop instance in parallel where it could.
>
>Just thought I'd try to get the ball rolling here ...
>
>

In article <48jv405nd0bqvtbb1jd797ep668h7e4qdq@4ax.com>, Ben Hinkle says...
>
>On Wed, 10 Mar 2004 16:43:17 -0800, "Kris" <someidiot@earthlink.net> wrote:
>
>>With the major CPU players heading towards multi-core devices, multi-threaded software is gonna' become much more commonplace. It's great that D already has some thread-awareness built-in, such as the synchronized keyword. How about some others? For example, Occam was a killer language for parallel development; it had constructs like par(;;){} which is akin to for(;;){} but performed each loop instance in parallel where it could.
>>
>>Just thought I'd try to get the ball rolling here ...
>
>Occam - oh that brings back the memories! I remember programming 16 transputers run by a mac for various dynamical system simulations and trying to use Occam but ended up using C and assembly for more speed and interfacing with the host. I think it was a T800.
>
>In the back of my mind I want to use D's pragmas to support OpenMP
>http://www.openmp.org.
>That would be very very cool.
>
>-Ben
>

Ta for the Link Ben; would be nice to see some of those directives as first class citizens rather than #pragmas ...

Was thinking a little more about this; it strikes me that while D is certainly elegant and 'modern', that's hardly enough to get it through the corporate door. What it need is a 'killer' feature; something that really makes it stand out from the established crowd. One could argue that dbc/unittest is that feature, but that doesn't hit the bottom-line in a way that most VPs take notice of ...

I'll go out on a (short) limb and state my belief that if D were to explicitly/natively support the current thinking in multi-threading, while applying a dash of the "safe programming" techniques it already exudes, that might be enough to open the corporate door.

Kris wrote:
> One could argue that
> dbc/unittest is that feature, but that doesn't hit the bottom-line in a way
> that most VPs take notice of ...

I agree with you here, but it's piss-poor "sales" from the programmers and project leads to the VP.  I can't think of anything that would play better to a VP than reduced development costs over the life-cycle of a product, fewer initial bugs in a shipping product, and built-in methods to ensure no repeat appearances of bugs.

In the end it comes down to the people using the tool properly, not that the features are there.  The fact that it's not an add-on extension will help D grow from within the hacker community.  (fresh off that read of Paul Graham's essay in an earlier post).

BA