Actas JP2011 - Universidad de La Laguna

Actas XXII Jornadas de Paralelismo (JP2011) , La Laguna, Tenerife, 7-9 septiembre 2011(Fig. 1.4B). Biblio-MetReS implements parsers forHTM, PDF and ASCII documents.Each node or vertex in the graphs is a gene/proteinand each edge refers to an instance of co-occurrencebetween different genes in sentences, paragraphs, ordocuments. The thickness of the edge is proportional tothe mutual information between two genes and the colorof the edge is proportional to a p-value that measureshow much more enriched is the co-occurrence betweentwo genes in sentences or paragraphs with respect todocuments. See [14] for more details.The whole process described above is done on the fly.The serial time in executing all the Biblio-MetReSprocesses can be very high, and it would strongly benefitfrom parallelization.III. P-BIBLIO-METRESIn this section we describe the main decisions taken inthe design of the parallel version of Biblio-MetReS, P-Biblio-MetReS.As was pointed out in the Introduction, there areseveral forms of parallel computing: bit-level,instruction level, data, and functional parallelism.Biblio-MetReS is written in a high-level language, Java.Parallelization in the bit or instruction level will bealmost impossible. Instead, parallelism was performedin an upper level, at the Java code.As P-Bilbio-MetReS is designed to be executed on amultithreading machine, the following aspects must betaken into account:• We cannot assume that any running thread has thehighest priority. A higher-priority thread may berunning on a different processor.• We cannot assume that a low-priority thread willnot run. There may be enough processors to give ita chance at execution.• We cannot assume that threads of differentpriorities will not be running at the same time.• We cannot assume that a given race conditions canbe ignored, just because it is unlikely to occur. Raceconditions in a multiprocessor system present a realproblem, whereas race conditions in a singleprocessorsystem are more dependent on thescheduling engine of the Java virtual machine.Taking these issues into account, the key question ofthe parallelization problem at hand is a) theidentification of the Java code to be executed in paralleland b) implementing this code in one class (or object)that can be run in multiple threads. Multiple threads arecreated, one for each copy of the object, and then theyare executed in parallel. As all the threads are executedin the same machine, our parallel implementationrequires defining an optimal multithreading policy.Without redesigning a program, the parts of the codewhose execution is most likely to benefit fromparallelization are those where the application is CPUbound - that is, the sets of instructions where theprogram is mainly using processing cycles, and at thesame time E/S resources (network and secondarystorage) are idle -.We discard the parallelization of E/S parts of codebecause Biblio-MetReS does not deal with an amount ofinformation that makes it necessary to increase the speedof access to the secondary storage. If we would want toincrease the network bandwidth, P-Biblio-MetReS couldalso be simultaneously executed in different machines,each with an individual IP. Distributed environments(for example Grid, Volunteer, Cloud or P2P computing)could be considered for such an execution.Thus, first and foremost, we are interested indetermining the CPU bound objects in Biblio-MetReS.By taking into account the class architecture of Biblio-MetReS (see Fig. 2), we identified the objects where a)documents are obtained from different data sources, andb) the parsing of those documents is made as thosewhere the application is CPU-bounded. These objectsare thus the natural candidates to be executedconcurrently in multiple threads.Fig. 2. Class diagram representing relationships betweenclasses used in the parallelization.Second, we must also consider that there is no reasonto execute the serial program ‘Biblio-MetReS’ CPUboundobjects in parallel if, during its run, the programdoes not use 100% of the available single physicalthreads. We should control for this possibility whenchoosing a parallelization policy to execute P-Biblio-MetReS.Third, we are interested in getting the appropriatenumber of threads to be created and executed in parallel,so that an optimal run time is obtained. More precisely,we are interested in understanding the relationshipbetween the available processing power (the number ofhardware threads) and the number of logical threads wecan create at once in order to identify the ratio R optimalbetween the two quantities that optimizes execution timeof the program. Identifying this ratio will allow us tocreate an application that scales well.Because there is, to our knowledge, no systematicmethod to identify R optimal , we test three heuristicpolicies to determine which of these gives the bestperformance:1. The first method (S1) consists in creating a threadfor every search engine. Each thread handles thelinks returned by the search engine. Then, it parsesthe returned documents. The various threads areJP2011-59