1 / 15

Master-Worker Paradigm Support in Software Component Models

This research paper explores the support for the master-worker paradigm in software component models, such as CCM, CCA, and Fractal. The study discusses the different infrastructures, resource-dependent properties, request delivery policies, and features of the model. It also presents a case study of experimenting with a master-worker application using DIET and CCM components and discusses the challenges and future directions.

leclerc
Download Presentation

Master-Worker Paradigm Support in Software Component Models

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Master Worker Paradigm Support in Software Component ModelsHinde Bouziane, Christian PérezPARIS Research TeamINRIA/IRISARennes ANR CIGC LEGO (ANR-05-CICG-11) Bordeaux, 2006, December 11th

  2. Master-worker applications Understanding very high energy cosmic rays AUGER Project (LRI/LAL-IN2P3) XtremWeb Neuron Simulation with MCELL CRPC Rice University NetSolve

  3. Master worker worker worker Workers collection Requests transport Scheduling Fault tolerance worker Problem overview • Simultaneous independent computations (~ForAll loop) • Dedicated API/environments • BOINC, XTremWEB, DIET, NetSolve, Nimrod/G, ...

  4. master worker W W W W request delivery policy master worker Limits with current component models • Different infrastructures • Multi-core processors, SMP, clusters, grids, etc. • Resources dependant properties • Number of workers • Request transport and scheduling policy • At the burden of the programmer • Complex • No transparence • Objectives • Transparency • Re-use existing MW environments

  5. Features of the model • Resources infrastructure independence • Transparency • No dealing with the number of workers • No dealing with request delivery concerns • An initial number of workers depending on the current resources infrastructure • Introduction of a request delivery policy depending on the current resources infrastructure

  6. W1 Wn W2 Wi worker T3z Type3 Type3 Type1 T1x Type1 Type3 Type2 Type2 T2y T2y Abstract master and worker composition (1/2): a collection • Collection definition • Collection at execution Exposed provided port Instantiation Instantiation

  7. m X Type1 Type3 Type2 Abstract master and worker composition (2/2): abstract assembly Composing componentswith collections ≈ Component composition

  8. Round-Robin Round-Robin Deployment environment Integration of a request delivery policy (1/2): transformation • Abstract ADL ->concrete ADL Transformation process

  9. MA LA LA LA MA MA Random Round-Robin Round-Robin M M M w w w w w w w w w w Round-Robin / Random Integration of a request delivery policy (2/2): patterns Simple component based pattern Hierarchical scheduling pattern DIET pattern

  10. Round-Robin #workers + Pattern selection deployment environment Set of patterns Sum up Programmer/designer view During deployment phase Transformation Components Collections Abstract assembly

  11. Extending the CORBA Component Model

  12. Master and workercomponent definition Interface Description Language (IDL3) Collection definition in two steps External view: IDL3 extension Internal content and bindings: Collection Description Language (CDL) in XML format interface Compute {..} ; component master { uses Compute m_port; }; component worker { provides Compute w_port; }; collection coll { provides Compute c_port; }; <element type=“worker"/> <binding> <externPort portRef=“c_port"/> <internPort elemType=“worker“ port=“w_port"/> </binding> master worker worker Case of study: CCM m_port w_port c_port

  13. Experimenting MW in CCM • Synthetic MW application • Benchmark • Several flavor of the master • Sequential or parallel operation invocations • Latency & bandwidth oriented request • Regular or irregular request bench • Work generated by one request • Several transport request policy component • None (direct connection from master to workers) • Round-robin proxy • Random proxy • DIET

  14. MW CCM & DIET M • Client & Server-side DIET Component • Wrapper • Conversion between IDL & DIETdata representation • Home-made CCM compiler • DIET support • Generate adequate codefor client & server sidecomponents • Control with special commentsin IDL3 Client Component MA MA MA LA LA LA Server component w w w w

  15. Discussion • MW support for Component Model • Map to CCM, CCA & Fractal • Easy to port application • All the work is to componentize the applications • Two applications have been ported • Experiments are in progress • What to measure? • Which API? • Data dypes • Bunch of calls (~ForAll loops?) • DIET deployed as CCM executable • CSD supports executable • DIET hierarchy described in CAD files! • Current ADAGE planner is not aware of DIET specificity • Deployment control through associate element of the ADAGE control parameters

More Related