This seems to be a perennial topic where people focus on the natural parallelism in the language but ignore the inconvenient fact that the time spent allocating memory dwarfs processing time. If you look at the timings using Marshall's parallelize adverb, you'll see that verbs parallelized at the array level run more slowly than the non-parallel version.
As I've mentioned before, I run parallel J code every day but in such a way as to achieve faster throughput by spinning off multiple processes for a coarse parallelism: www.jsoftware.com/jwiki/Community/Conference2012/Talks/ParallelSimulationInJ. The main advantage that J offers is not the fine parallelism inherent in the language but the simplification of code that allows us to break apart problems at a high-level combined with the lightness of the interpreter that allows us to spin off multiple processes simultaneously. Some of my parallel code spins off dozens of simultaneous instances of the interpreter with no problem. On Sat, Feb 22, 2014 at 12:17 PM, Don Guinn <[email protected]> wrote: > There are at least two ways for parallel processing (multi-tasking) - One > where several processors share the same memory, and another where memory is > not shared and it is necessary to transfer or duplicate data on computing > systems that may or may not be tightly connected. > > The latter case obviously requires action on part of the application to > determine if and how to split up the processing. The first case is where J > can really shine in that existing J code is easy to parallelize as the > notation shows were parallelization is OK. Well, maybe not so easy, but > possible. The problem is similar to the one that faced APL when vector > processors became more available. How to avoid using the vector processors > on very short vectors. > > > On Sat, Feb 22, 2014 at 9:06 AM, Raul Miller <[email protected]> > wrote: > > > On Sat, Feb 22, 2014 at 9:35 AM, Jan-Pieter Jacobs > > <[email protected]> wrote: > > > The overhead issue is always there, and it is up to the user to not > apply > > > parallellization for things that are not worth parallellizing. > > > > It might be nice to have a "parallelize this" adverb. > > > > That said... you really want the data to already be in place on > > parallel instances, and there's a certain amount of setup time to > > publish them out. > > > > Another critical issue is having a common language, for shipping > > commands between parallel instances (this can be modeled using > > independent processes but for real practical work you might want > > independent machines, but the GPU variant is also interesting and has > > some fascinating constraints). > > > > In J, we would probably use 5!:5 to serialize and 0!:0 to deserialize? > > > > Here's an illustration: > > > > mean=: +/ %# > > T=: 5!:5 <'mean' > > A=: 'MEAN=:',T > > 0!:0 A > > > > data=:2 3 5 > > 0!:0 'V=:',5!:5 <'data' > > 0!:0]0 :0 > > smoutput MEAN V > > ) > > 3.33333 > > > > Thanks, > > > > -- > > Raul > > ---------------------------------------------------------------------- > > For information about J forums see http://www.jsoftware.com/forums.htm > > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > -- Devon McCormick, CFA ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
