Tracy, I have always felt that array languages such as APL & J were excellent candidates to take advantage of the parallel processing capabilities that are becoming available in modern processors. Unlike most scalar sequential languages, J extends its primitives operations to arrays, allowing a programmer to describe operations on groups of items rather than individual items. Thus, a programmer can explicitly describe high-level array operations required for their program. With scalar languages, the programmer would have to rely on vectorizing compilers to discover these mass repetitive operations (often unsuccessfully), or have to explicitly define the concurrency using concurrent languages such as Erlang or Clik, .
J seems to have a philosophy of "hiding the details" of how it goes about its underlying processes, as long as the final result is correct. Take for example the grade-up/sort primitive. J does not guarantee how it will get the items sorted, only that they will be correctly sorted. I am told that J will pick the most appropriate sorting algorithm for the data, to optimize the sort time and space processing requirements. With all J primitives extended to generalized arrays, this effectively means that most potential parallel operations in J will be fully spelled out by the programmer, in the normal course of programming in J. The J interpreter can then simply decide whether the requested mass operations can benefit from concurrent execution or not. If they can, it can use the available processing cores in parallel to perform the operation. If not, everything will proceed as normal, sequentially. The J interpreter will not have to DISCOVER the mass repetitive operations. It will only have to decide whether the operations will benefit from concurrent processing or not. And, J saves the programmer from explicitly doing the dirty work of data dissassembly, assembly, etc. J's 120-or-so primitives seem to cover most of the fundamental processing algorithms in modern computing. It would seem that some of these algorithms would likely benefit from concurrent processing, particularly as datasets become large. Of course one could always re-write the algorithm in one of the explicit concurrent languages such as Erlang or Clik. These languages (and concurrent C, Turing +, etc.), are all designed to allow programmers to explicitly program concurrent algorithms. By this I mean that these languages require the programmer to explicitly break the data into parts that can be placed on multiple processors, as well as design how and when each processor will access it's data. Designing algorithms to take advantage of concurrency is not trivial. Just something as simple as adding two arrays together pairwise, can be quite involved. The concurrent program needs a way to discover how many processors are available. Then the data has to be broken up into pieces, and the size of each piece for each processor will depend on the number of processors. The appropriate data segments must be sent to each processor. For efficiency's sake, the data needs to reach all the processors as close to simultaneously as possible, so all computations can be started approximately at the same time, to achieve the most concurrency. After the computation has completed, the data must be re-assembled back into a single array of sums. All of this complexity begs to be hidden "beneath the covers" of J, just like the sort algorithm details are hidden from the programmer. It is obvious that for most simple array operations on small datasets, the overhead of data separation, transmission to the various processor cores, retrieval from the cores, and re-assembly of the data , will overwhelm the actual processing step, thus making pure single-processor, sequential operations the appropriate choice for these cases. However, at some point, specific operations on larger datasets may benefit from parallel operations. Intel has expended significant efforts designing tools to help take advantage of their multi-core processors. See: http://tinyurl.com/cwd7ud It would be interesting to see what effect Intel's latest concurrent compiler would have on J's interpreter. However, I expect that making a significant portion of J's primitives "concurrent-aware" will require considerably more than just a simple compiler change. I like Roger's rule that if a change to the interpreter can't improve the processing speed or memory usage significantly, it shouldn't be done. That should be the criteria for all concurrent modifications to J's interpreter. Multi-core processors are becoming ubiquitous in our personal computing systems. It would seem that array languages such as J would be the ideal candidate to take advantage of this concurrency, saving the J programmer from the complex details of concurrent programming. If the J community wants to expand J's usage, making J an "implicitly concurrent" language (as opposed to explicitly concurrent like Erlang) would attract many new users. Of course, it may be that very few common algorithms can take advantage of these multi-core architectures, due to the data movement overhead. If that us true, then the chip vendors may be going down the wrong path in their quest for ever-higher performance. Skip Cave Tracy Harms wrote: > Has anybody applied, or discussed, the Actor model from the standpoint of J? > > http://en.wikipedia.org/wiki/Actor_model > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > > > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
