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
