Re: Unpopular parameter passing mechanisms and parallelisation

On Wed, 31 Oct 2007 16:41:53 +0000, Anton Lokhmotov <al407@cam.ac.uk>
wrote:


>George,
>
>I think the following paper discusses similar ideas to yours (Haskell,
>CBN, micro-threads):
>Tim Harris, Satnam Singh. *Feedback directed implicit parallelism
>(http://research.microsoft.com/~tharris/papers/2007-fdip.pdf)*
><http://research.microsoft.com/%7Etharris/papers/2007-fdip.pdf> /ICFP,
>Oct 2007


Thanks for the reference.




>> Nowadays we don't even have the vector processors,
>Not quite true: http://slashdot.org/article.pl?sid=07/10/25/236200


There's always somebody. NEC doesn't appear to have any useful
information about it on their web site - all I could find was the
press release which doesn't have any details about the architecture.




>> the SIMD units in todays CPUs don't have the same semantics.
>...the same as vector assignment statements? But - in your own words -
>machines like Cray-1 also didn't have it.


Not so. Cray did have compound registers, but the vector units were
serial pipelined, not SIMD - they accessed compound registers as
queues, 1 value index at a time. The vector units could not read from
memory - vector arguments had to be in registers - but they could
optionally write results back to memory.


[I assume you noticed the Cray in the background of the picture
accompanying the Slashdot article about the NEC processor?]




As far as CBVR is concerned, CBVR is violated if the program can, at
any time, perceive a partial update. Vectors that exceed the length
of the registers (vector pipelines) have to be processed
incrementally, requiring temporary storage and explicit copying to
preserve CBVR semantics.




>> Additional temporary storage is almost always required to get the desired behavior
>> For vector processing, CBVR is mostly an intellectual convenience for
>> the programmer rather than a useful execution strategy. It doesn't
>> buy you any more than other vector methods.
>>
>...what other methods? I think CBV(D)R *is* useful in the age of
>parallelism (and that's was the reason for my recalling it).
>
>> As a parameter passing method, CBVR was deprecated because most
>> programmers found it confusing.
>
>But today is different because CBV(D)R is *more natural* for *parallel*
>programming (I am again alluding to the August discussion on the
>semantics of vector assignment statements).
>
>Anton.


Considering the example (in Sequoia) you gave:


  | fCBVR(int a) { // copy in
  | a = 1; // delay write to caller's memory, make a local copy
  | print a; // prints 1 by reading from the local copy
  | } // copy out
  |
  | main() {
  | int z;
  | z = 0;
  | fCBVR(z); // update z
  | print z; // prints 1
  | }


I honestly don't see much semantic difference between CBVR and CBV(D)R
from the point of view of the caller - if you disagree perhaps you'd
care to expound on it.


However, the behavior within the callee I think would be confusing to
most programmers. I think it's wrong to allow an assignment and then
refuse to acknowledge it ... particularly in what otherwise appears to
be an imperative language and when the desired behavior (as I
understand it) can be accomplished in a less confusing manner using
something like Ada's IN and OUT parameters. [Not that I particularly
like Ada, but its parameter control _is_ a useful feature.]


YMMV,
George

Return to the comp.compilers page.
Search the comp.compilers archives again.