> 14 jul 2015 kl. 07:04 skrev Maatary Okouya <[email protected]>: > > Hi, > > I was just wondering as a general advise if the following made sense. > > > I have a list, that i need to filter according to the following criteria: Let > say the list contain things of type A, B, C and D and i want to take n0 elt > of A, n1 elt of B, n2 elt of C and n3 elt of D and then make one list out of > it. > > the iterative approach is pretty clean (i.e. going over the all list, using 4 > counters, adding elt to each list until each respective counter reached it > limit i.e. n1, n2, n3, n4), but a colleague at work told me to take advantage > of multiple cpu and parallelize the operation using future. > > in other words, launching 4 future operation that filter the list, and drop > if it applies (i.e.resultinglist > nx), "resultinglist.size - n0 or n1 or n2 > or n3 or n4". then await the result and combine the list. > > I think this is an overkill for something we use to do iteratively pretty > easily. I just wonder what people think about that. Yes i can run a test and > compare the speed, but it raise the question of, when exactly can we ensure > that we are taking advantage of the multiple cpu architecture. Because indeed > i understand the motivation behind the suggestion. However, i did not know > how to tell that it might be counter productive. We were both stuck in debate > and enable to state if it is good situation or a bad situation to use > parallelization. In other word we did not have a criterion. Is testing the > only way to know ?
One way to look at such problems is to figure out what the costly part is and then ask yourself if that can meaningfully be partitioned (which is the prerequisite for benefiting from parallelism). In this case the expensive part is to traverse the list (touching all those memory locations) and the best you can do is to traverse it once, no partitioning possible. In general parallelism for processing collections is an allure that seldom leads to faster or more efficient programs—the collection would have to be huge and partitionable or the operation to be run needs to be expensive in order to realize gains. Occupying more CPUs is not a good purpose in itself. Regards, Roland > > > Many thanks, > > M > > -- > >>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/> > >>>>>>>>>> Check the FAQ: > >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html > >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html> > >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user > >>>>>>>>>> <https://groups.google.com/group/akka-user> > --- > You received this message because you are subscribed to the Google Groups > "Akka User List" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] > <mailto:[email protected]>. > To post to this group, send email to [email protected] > <mailto:[email protected]>. > Visit this group at http://groups.google.com/group/akka-user > <http://groups.google.com/group/akka-user>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. Dr. Roland Kuhn Akka Tech Lead Typesafe <http://typesafe.com/> – Reactive apps on the JVM. twitter: @rolandkuhn <http://twitter.com/#!/rolandkuhn> -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
