Roelof K. Brouwer wrote:
I would like to know if multiple threads is incorporated in the
implementation of J. ( this may be a stupid question).
Roelof,
Several previous posts in this forum have asked the same question about
multi-threading that you have, and the answer is NO. J only uses a
single thread of execution. List members have proposed breaking a
compute-intensive problem up into several chunks and starting multiple J
sessions to execute the code in parallel. This is a brute force
approach, but it can be effective.
However, it is clear the future of computation is rushing headlong into
multi-processing. Just read the "CPU Roadmap" article in this month's PC
Magazine:
http://www.pcmag.com/article2/0%2C1895%2C2084389%2C00.asp
Some key article points:
-By the end of 2006, they (dual-core processors) accounted for at least
70 percent of all desktop and notebook chips shipped from Intel.
-Quad cores shipping in volume in 2008
-Chances are, we'll also see the first eight-core processor in 2008
-16-cores by the end of the decade
Computer languages that take advantage of multiple-core processors will
have a huge advantage in the future.
Most of J's primitives could take advantage of multiple parallel
processor threads. A simple example is the addition primitive. If we add
two arrays together in a linear fashion, the execution time on a single
threaded machine requires an addition step for each cell in the array.
If we split the array addition process across 8 different processors,
each operating on a different portion of the array, there are still the
same number of addition steps, but we are performing eight additions at
the same time. Thus the overall array addition time has potentially been
sped up by eight times. Of course, this ignores set-up time to break up
the arrays into operable chunks for each processor, and then the time
needed to put the array pieces all back together again, but the
potential is still there for major performance improvements.
Roger Hui has stated that he will consider enhancing J's underlying
execution model of a specific primitive when that enhancement has the
potential to at least double the execution speed of that primitive. The
upcoming four and eight-core processors will bring the potential for
four to eight times performance gains. Multiple core processing should
provide a huge performance jump for most J primitives. However, J
primitives that require serial or sequential data operations will not
benefit from the parallel model.
APL, J, and their array-processing relatives, all have a big advantage
over scalar languages in the multi-processing paradigm. Array languages
typically specify algorithms at a higher-level abstraction than scalar
languages. This higher-level abstraction exposes the programmers'
algorithmic intent much more clearly that scalar languages. Scalar
languages must have "intelligent" vectorizing compilers that try to
discover the parallelism in the existing code, so that it can figure out
how to allocate the processing to various cores. The primitive
operations in array languages define operations that can be made
parallel (dare I say parallel-ized?) at the interpreter level, without
having to infer the programmers intent.
In the next few years, programmers will start looking for programming
languages that will take advantage of the availability of multiple core
processors. They will look for languages that do this effortlessly, if
not invisibly. A compute-intensive program that runs in one minute on a
two-core machine, should run in 15 seconds on an eight-core machine.
Languages that simplify (or better, hide) this problem of
parallel-izing programs could become the language of choice for
performance-minded programmers.
J is perfectly positioned to provide this type of capability. Most of
J's primitives are clearly parallel-izeable. However, this is not to
minimize the effort to add parallelization to J's primitives. It would
be a huge effort to modify J's primitives to take advantage of parallel
operations. Howevr, the gain - four to eight times performance gains -
could be worth it, and it could launch J into the forefront of modern
computer languages dealing with "Parallel-ization"
Skip Cave
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
