I run parallelized J on multi-core machines and have done so for years. I looked at the "CPU affinity" thing and concluded it was a waste of time and an unnecessary constraint for what I was doing. What I've found is that the OS - Windows in my case - does a fine job on its own of distributing multiple J sessions across the available cores.
A detailed write-up of what I've done is here: http://www.jsoftware.com/jwiki/Community/Conference2012/Talks/ParallelSimulationInJ . An earlier version is here: http://www.jsoftware.com/jwiki/DevonMcCormick/ParallelizedJCodeExamples . The next advance I'd like to come up with would be to spin off multiple J processes, then co-ordinate work between them with something like sockets. This would allow me to do some simple load-balancing. On Wed, Feb 25, 2015 at 9:04 PM, Joe Bogner <joebog...@gmail.com> wrote: > On Wed, Feb 25, 2015 at 5:41 PM, N.N. <nakabi...@gmail.com> wrote: > > > 1) does Windows use the 8 processors to run the j-console ? > > > > No, J is single threaded > > 2) is it possible to run 8 j-consoles and assign each console on one > > processor ? > > > > You could, but I'm not sure what the benefit would be. You could assign CPU > affinity to each process. Each would run independently. > > 3) is it possible to use 1 console and manually create threads > > assigning a process on the 7 remaining processors ? > > > > > J is single threaded and doesn't provide a capability to create threads > natively. You can spawn processes so you would need to write your own code > to spawn the processes and submit the work to each process. This is > conceptually how other single threaded console apps cluster their work > (node.js and R) > > I have done some prototyping on this topic: > > 1. Integrating tinyc to just-in-time compile multi-threaded C code - > http://www.jsoftware.com/pipermail/chat/2015-February/006488.html > > 2. Integrating go-lang to function as a multi-threaded web server - > http://www.jsoftware.com/pipermail/source/2015-February/000663.html > > 3. Spawning another J process and duplicating the socket to effectively > function as a multi-threaded server - > http://www.jsoftware.com/pipermail/chat/2013-August/005328.html > > > Still, it would be worthwhile to understand your use-case for threading. My > experience has been that threading is most useful when different tasks need > to run in parallel. I haven't seen as much benefit in breaking up a single > task into chunks and executing it on multiple threads / processes. J's > performance has been largely sufficient for single task execution. > ---------------------------------------------------------------------- > 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
