I thought that the point of having an explicit threading primitive was to support / give J developers the decision making process in deciding how to manage threads?
How is this supposed to work if the threads doing the work are not the threads they are delegating the tasks to, in some undocumented fashion? Thanks, -- Raul On Sun, Jan 22, 2023 at 5:28 AM Elijah Stone <[email protected]> wrote: > > I don't think it necessarily needs to go in nuvoc. It's an implementation > detail; any number of things might be parallelised at a given point in time. > > > Probably I need to look for primitives whose implementation routine's call > > tree includes a routine whose implementation might use jtjobrun. > > Yes. > > On Sun, 22 Jan 2023, Raul Miller wrote: > > > Ok... if I understand correctly, instead of "parallelizable primitive" > > being executed only in pool 0, nuvoc should instead state that > > "parallelized primitives" will only be executed in pool 0. > > > > And, these primitives should be explicitly enumerated in nuvoc in that > > context. (Either in that part of that page > > (Vocabulary/tcapdot#Threadpools) or on some other page which is > > referenced from that part of that page.) > > > > I suppose I can probably figure this out for myself, so that I can > > update nuvoc. But I'll have to think a bit about > > this issue before I could come up with a reasonably reliable approach > > for catching these calltrees. (If you could list the primitives, that > > would be great.) > > > > Thanks, > > > > -- > > Raul > > > > > > On Sun, Jan 22, 2023 at 4:22 AM Elijah Stone <[email protected]> wrote: > >> > >> It's 'complicated' as usual, but in general parallelising things like + > >> and * > >> is a waste of resources. Currently parallelised are +/ .* and a few of the > >> 128!: ops. > >> > >> On Sun, 22 Jan 2023, Raul Miller wrote: > >> > >> > On Sun, Jan 22, 2023 at 2:46 AM Elijah Stone <[email protected]> wrote: > >> >> And parallelisable primitives will > >> >> always be run by threads in pool 0 (for now); never by threads in the > >> >> pool > >> >> where they were kicked off (unless that happens to be pool 0). > >> > > >> > I see mention of this in nuvoc: > >> > > >> > https://code.jsoftware.com/wiki/Vocabulary/tcapdot#Threadpools > >> > > >> > But I do not understand which primitives are "parallelizable". > >> > > >> > Intuitively, I imagine that this would be all primitive operations > >> > (either monadic or dyadic) with a non-infinite rank and no required > >> > side effects. > >> > > >> > But expecting that all addition and multiplication happens in pool 0 > >> > for a task running in pool 1 baffles me, as a design decision. If my > >> > interpretation was correct, what would be the current advantage for > >> > using this approach? Or, if my interpretation is wrong, what does > >> > "parallelizable primitive" mean? > >> > > >> > 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 > > ---------------------------------------------------------------------- > > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
