Since, on my "Core(TM)2 Duo CPU T6400 @ 2.00 GHz", 6!:2 '(i.1e6)+i.1e6' 0.016344815
it's unclear even this would benefit sufficiently from parallel execution to make it worthwhile. For any arbitrary function on arbitrary arguments, it's even less clear that fine-grained parallelism is worth the trouble. I'm not arguing that it would never be worthwhile, just that it's unclear and requires a lot of effort to clarify it, even for a specific function much less for the general case. "i." is probably a particularly unworthy basis for deciding to go parallel given Roger's recent comments indicating that J's already doing something with APVs (arithmetic progression vectors) for lengthy vectors. On Mon, Feb 15, 2010 at 2:06 PM, Matthew Brand <[email protected]>wrote: > Recognising that 1 2 + 2 4 is a loop with 2 iterations the decision could > be > made to do it in serial. > > Recognising that (i.1000000) + (i.1000000) is a loop with many iterations > the decision could be made to explore doing "+" in parallel. > > Isn't this the type of decision that i. does for algorithm selection? > > On 15 February 2010 18:49, Devon McCormick <[email protected]> wrote: > > > Raul - yes - there's always been a lot of hand-waving magic about the > > benefits of parallel processing but many a pretty ship of theory has > > foundered on the cold hard rocks of fact. Until you consider a specific > > problem and do the work, you can't make any claims about the benefits. > > > > In fact, it's easy to offer a "dis-proof of concept": parallelize > > > > 1 2+3 4 > > > > I bet any parallel version of this will lose to the non-parallel version > - > > there's no way the overhead cost of breaking up and re-assembling the > > results of this small piece of work is less than simply doing it. > > > > We talked about this at the last NYCJUG and I'm glad to see it's still a > > pressing topic as this will motivate me to update the wiki for February's > > meeting. > > > > Regards, > > > > Devon > > > > On Mon, Feb 15, 2010 at 12:33 PM, Raul Miller <[email protected]> > > wrote: > > > > > On Mon, Feb 15, 2010 at 11:00 AM, bill lam <[email protected]> > wrote: > > > > Apart from the startup time and memory cost, the biggest problems are > > > > the need to tailor the algorithm by programmer for each for its > > > > applications, synchronisation of sessions, the memory bandwidth it > > > > took to transfer data between session. OTOH the low level solution is > > > > transparent, J programmers will not even need to aware its existence. > > > > Henry Rich had also suggested this approach if memory served me. > > > > > > One problem with the low level approach seems to be that, so > > > far, no one wants to fund the investigative costs associated with > > > this change. > > > > > > To my knowledge no one has even shown a "proof of concept" > > > implementation for any primitive. > > > > > > -- > > > Raul > > > ---------------------------------------------------------------------- > > > For information about J forums see http://www.jsoftware.com/forums.htm > > > > > > > > > > > -- > > Devon McCormick, CFA > > ^me^ at acm. > > org is my > > preferred e-mail > > ---------------------------------------------------------------------- > > 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 ^me^ at acm. org is my preferred e-mail ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
