java - Why does this parallel algorithm run more slowly than its sequential counterpart? -



java - Why does this parallel algorithm run more slowly than its sequential counterpart? -

sequential:

void do(list<d> d, final list<c> c) { (d datum : d) getchampoid(datum, c).tally(datum);

parallel:

static final int procs = runtime.getruntime().availableprocessors(); static final executorservice pool = executors.newfixedthreadpool(procs); void do(list<d> d, final list<c> c) { list<future> futures = new arraylist<>(); (final d datum : d) futures.add(pool.submit(new runnable() { @override public void run() { getchampoid(datum, c).tally(datum); } })); (future f : futures) seek { f.get(); } grab (interruptedexception e) { e.printstacktrace(); } grab (executionexception e) { e.printstacktrace(); }

i'm stumped because me exact same thing, parallel version should faster, it's order of magnitude slower. thoughts?

fyi both d , c huge lists somewhere between thousands , hundreds of thousands of items.

the parallel version should faster,

that mutual misconception.

but it's order of magnitude slower.

a mutual result

any thoughts?

using multiple threads has overhead 1 thread doesn't have. overhead can orders of magnitude higher work done, making much slower. if work done much larger overhead can scalability.

e.g. costs 10 micro-seconds pass task thread. if task takes 1 micro-second, overhead can kill performance. however, if task takes 100 micro-seconds, see important performance improvement , worth paying cost of overhead.

in short, nil free esp not multiple thread.

java concurrency parallel-processing

Comments

Popular posts from this blog

java - How to set log4j.defaultInitOverride property to false in jboss server 6 -

c - GStreamer 1.0 1.4.5 RTSP Example Server sends 503 Service unavailable -

Using ajax with sonata admin list view pagination -