Message-ID: <736317799.8155.1422218046662.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_8154_132416813.1422218046661" ------=_Part_8154_132416813.1422218046661 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Dealing with data frequently involves manipulating collections. Lists, a= rrays, sets, maps, iterators, strings and lot of other data types can be vi= ewed as collections of items. The common pattern to process such collection= s is to take elements sequentially, one-by-one, and make an action for each= of the items in row. Take, for example, the min() function, which= is supposed to return the smallest element of a collection. When you call = the min() method on a collection of numbers, the caller thread wil= l create an accumulator or so-far-the-smallest-value init= ialized to the minimum value of the given type, let say to zero. And then t= he thread will iterate through the elements of the collection and compare t= hem with the value in the accumulator . Once all elements have bee= n processed, the minimum value is stored in the accumulator .
This algorithm, however simple, is totally wrong on mul= ti-core hardware. Running the min() function on a dual-core chip c= an leverage at most 50% of the computing power of the chip= . On a quad-core it would be only 25%. Correct, this algorithm effectively = wastes 75% of the computing power of the chip.
Tree-like structures proved to be more appropriate for parallel processi= ng. The min() function in our example doesn't need to iterate thro= ugh all the elements in row and compare their values with the accumulat= or . What it can do instead is relying on the multi-core nature of you= r hardware. A parallel_min() function could, for example, compare = pairs (or tuples of certain size) of neighboring values in the collection a= nd promote the smallest value from the tuple into a next round of compariso= n. Searching for minimum in different tuples can safely happen in parallel = and so tuples in the same round can be processed by different cores at the = same time without races or contention among threads.
The GParsPool class enables a ParallelArray-ba= sed (from JSR-166y) DSL on collections.
Examples of use:
The GParsExecutorsPool class provides similar functionality to = the GParsPool class, however uses JDK thread pools instead of the = more efficient ParallelArray-based (from JSR-166y) impleme= ntation.
Examples of use:
See the Parallel Collection section in the U= ser Guide for more information.