If you ever have a long-running process that chews up CPU, you'll appreciate a second core when you try to get something else done while that process is running. I don't think it's too difficult to use multi-cores with coarse-grained parallelism, but it does require some programming work to architect your app to take advantage of it.
On Mon, Feb 15, 2010 at 8:46 PM, Matthew Brand <[email protected]>wrote: > I don't disagree with your line of thought.Based on what people have said > so > far it seems like a lot of effort to make good parallelisation and the > gains > might not be as large as one first thinks when watching the processor > monitor hovering just below 50%. I guess I am a bit suckered in by that, > because it feels like a waste. Niavely, I think I should have bought 1 core > at half the speed :-). > > > On 16 February 2010 01:23, Devon McCormick <[email protected]> wrote: > > > 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 > > > ---------------------------------------------------------------------- > 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
