> There has been continued interest on this forum and elsewhere
> in the APL community about taking advantage of the up-and-coming
> generation of multi-core machines.
Mapped files and asynchronous signaling provide a good foundation for your
Netflix type of coarse parallelism. They permit distinct J processes to
communicate efficiently. One "passes" large data via shared mapped files, and
control data (small) via asynchronous signals (this is analogous to the FTP
model).
Of course, once you go this route, you end up with all the same multi-threading
obstacles encountered in "normal" languages. A major reason to use J is
precisely to avoid low level house-keeping details like this.
The DoJ takes great pains to avoid promising order of execution. For example,
at the first Hoboken JUG, Roger mentioned that he had found a "bug" in the
Dictionary. Here's the problematic sentence:
(f g h) y <==> (f y) g (h y)
Can you spot the error?
...
The bug is that asserting that equivalence also guarantees an order of
execution. To fix the bug Roger simply excised the sentence; now the forks are
defined only by the tree diagram (which promises no order). See also [A].
Why would the Dictionary be so reserved on this topic? I don't know, but the
only reason that I can think of is keep its options open wrt parallelism.
That is, you can use mapped files & async to implement coarse parallelism if
you have to. But try not to have to. I, personally, am content that subtler
minds than my own are looking at this problem.
-Dan
[A] Roger made some stronger statements wrt execution order a decade ago in
comp.lang.apl:
Regarding the interaction between order of evaluation within
an operator and functions with side effects: It would be unwise
to depend on a particular order of evaluation.
http://groups.google.com/group/comp.lang.apl/browse_thread/thread/7f5b75eabd1ee304/1f515d8e36cf7ab8
Regardless of the application, regardless of how nice it would
be, regardless of how many times or how strongly you wish it,
regardless of how many messages are sent to comp.lang.apl,
regardless of whatever reason, ... it would be unwise to depend
on a particular order of evaluation within an operator.
http://groups.google.com/group/comp.lang.apl/browse_thread/thread/e82e4dd256c7b6ff/7219da66b09dfd92
[B] We've discussed this topic before, and we all agree it's a tough problem.
But wouldn't it be nice to have our cake and eat it too? With the advent of
multicores, and a notation _designed_ from the get go to abstract parallelism,
our programs could be beautiful AND lighting fast.
APL's been (notationally) ahead of this curve for decades. I wish we could
take advantage of that.
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
