Unless you are using multiple machines, files are probably a better coordination abstraction than sockets.
(And if you are using multiple machines, you might still want to be using a file-like abstraction.) The reason is that sockets give you a "stop and wait" abstraction while files give you a "named data" abstraction. Also, modern OS's are pretty good about caching files, not so good about caching stuff going across sockets. Thanks, -- Raul On Thu, Feb 26, 2015 at 11:29 AM, Devon McCormick <devon...@gmail.com> wrote: > 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 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
