Re: Not enough parallelism in programming

David C. DiNucci wrote:
> JJ wrote:
> > David C. DiNucci wrote:
>
> >>A bigger problem for parallel software engineering lies in hiding
> >>behavior/timing. For example, I can ask two programmers to implement a
> >>module that takes value on two ports, A and B, and produces a result on
> >>port C that is their sum and one on D which is their difference (A-B).
> >>Even if both programmers implement the module to this spec, with no
> >>funny side effects or access to global info, one might work in my app
> >>and one might not solely due to the order in which they read their
> >>inputs from ports A and B and/or produce their results. Adding this
> >>sort of info to the spec (e.g. in temporal logic) can get very complex
> >
> >
> > If you ask a hardware EE in Verilog (or VHDL) the precise answer is
> >
> > assign
> > c = a+b, d = a-b;
> snip
> > Trying to model this in occam and I suspect in most any SW par language
> > is just doomed to reinvent only partially what timing accurate HDLS
> > already have.
>
> But there's a reason for that. SW languages don't want or need the
> majority of what's in timing accurate HDLS--especially the notion of a
> clock.
>

Funnily enough nor do some hardware projects if some simplifying
conditions are imposed hence C cycle simulators but with out the
benefit of the Verilog syntax unless a Verilog to C translator is used.

Clocks and master slave DFlops are the obvious hardware form of process
syncronization. The assign statement is a continouos process whose
outputs are eventually syncronized at a pipeline register. Now in
asynch hardware designs, clocks are replaced with self generated ready
strobes, not very useful to most ASIC or any FPGA designers.

> > Now when I do this in C, to be cheap & fast, the code looks exactly the
> > same but presumes that a,b are atatic and also only binary,
>
> Pretty valid presumptions in my book.
>
> > so c,d get
> > reavualated whenever a,b might have or did change with in a group
> > change.
>
> I don't know how you came to that conclusion. It depends completely on
> the context in which those statements are written.
>

In my context of poor mans simulator based on cycle C simulation with
out event wheel, values are just reevaluated every pipeline cycle no
matter if they change or not. This is still effective even if many
values don't change often, as long as some do change. The cycle
simulation trades speed and simplicity for the event driven simulator
accuracy. The two appraoches can be mixed.

> snip
> > One might conclude the software world is busily doing the same thing
> > with concurrency reinventing something the hardware people have had for
> > maybe 40-50yrs in simulation. Not that HDLs are of much use yet to seq
> > coders.
>
> Nor to parallel coders, I would conclude.
>
> Note that I was certainly not saying that it was impossible, or even
> difficult, to more carefully specify the problem above, or to code the
> solution in existing parallel languages, such that there wouldn't be any
> problem. It was meant just to illustrate that with only a specification
> based on inputs and outputs and not on relative timings, it can lead to
> a problem in software languages, just as it could in an HDL. For more
> info, google "Brock-Ackerman Anomaly".
>

I looked at
http://theory.stanford.edu/people/jcm/cs358-96/4-15-lecture.html
but I get lost in unfamilair style. I am not sure why the 2 sorts when
combined into another system would be a problem if the sorts proceed as
atomic operations. Were they not atomic?

I think your and my parallel camps are rather different. Imagine the
lambda calculas person trying to talk with the regular digital guys.

I am not sure where your par interests in ScalPL are and what the
applications are likely to be.

Most of the par apps I am interested in might be called embarrassingly
parallel, but include anything that might be remotely accelerated as
hardware esp if in FPGA or ASIC. It also includes the reverse case of
things that went from hardware to software such as all the DSP codecs
that run very well on PCs but might also be described more naturally as
HDL processes. It esp includes EDA software that runs as slow as
mollasses on PCs.

Occam is used both as a hardware description language in HandelC form
and as a general purpose par language so I see it as a bridge between
pure HDLs and seq languages. HandelC had to have added a no of things
Verilog already had such as wide bit types and clocks. If concurrent
processes can model hardware, then one is bound to compare to other
hardware modelling languages.



> I'm pretty certain we tossed this "HDL as parallel programming language"
> notion around quite a bit in The Thread That Would Not Die some time ago
> (2 years?). I didn't believe it then, and I still don't.
>
> -Dave

Yes we did, but A Glew brought up the side thread of hardware
simulation which is in my area of interest, and how a par language for
our camp might exploit the usefull concepts of Verilog (or VHDL) with
the general purpose C base without turning into a Superlog monster.

Since there have been 1000 plus seq languages over the years, it would
hardly be surprising if more than a few par languages were added to the
picture and could be just as entirely domain specific. I never see any
refs to hardware languages though in the multi language tomes or even
much on par ones.


johnjakson at usa ...

.

Relevant Pages

  • Re: Not enough parallelism in programming
    ... It was meant just to illustrate that with only a specification based on inputs and outputs and not on relative timings, it can lead to a problem in software languages, just as it could in an HDL. ... hardware esp if in FPGA or ASIC. ... and as a general purpose par language so I see it as a bridge between ... For all ScalPL cares, Andy's original example ...
    (comp.arch)
  • Re: Interesting take on Paradigms (OO vs Procedural)
    ... Because they weren't 'programmers', they were simulation modellers. ... Functional languages: Lisp, Scheme, Haskell ... Cobol from accounting, Fortran from engineering, APL from mathematics. ... Thus class data is a struct, ...
    (comp.lang.cobol)
  • Re: Interesting take on Paradigms (OO vs Procedural)
    ... Because they weren't 'programmers', they were simulation modellers. ... Functional languages: Lisp, Scheme, Haskell ... It happens that OO features were grafted on to existing computer ... Thus class data is a struct, ...
    (comp.lang.cobol)
  • Re: language and program nostalgia
    ... As languages, I'd bet most of them are still running on ... "contemporaneous" hardware, either inside virtual machines, ... I'd bet sources running on some unix are often ... The creation of emulators & virtual machines is almost as old as ...
    (comp.lang.lisp)
  • Re: Hows dot.net doing nowadays?
    ... Windows applications not web based apps. ... nothing else just to feel that if I make the switch to other languages some ... I work with specialized hardware. ... In regards to Java, I hear alot of people are excited about Ruby on rails. ...
    (microsoft.public.vb.general.discussion)