www.digitalmars.com         C & C++   DMDScript  

D - D & Occam

reply "Kris" <someidiot earthlink.net> writes:
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 ...
Mar 10 2004
next sibling parent reply Ben Hinkle <bhinkle4 juno.com> writes:
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
Mar 10 2004
parent kris <kris_member pathlink.com> writes:
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 ...
Mar 10 2004
prev sibling next sibling parent resistor mac.com writes:
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 ...
Mar 10 2004
prev sibling parent reply "Kris" <someidiot earthlink.net> writes:
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.
Mar 11 2004
parent Brad Anderson <brad sankaty.dot.com> writes:
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
Mar 11 2004