Proto-Runtime on the Grid

Project Details

Project Lead
Sean Halle 
Project Manager
Sean Halle 
Institution
CWI, Netherlands, Formal Methods Group  
Discipline
Computer Science (401) 
Subdiscipline
11.07 Computer Science 

Abstract

The Proto-Runtime Toolkit (http://opensourceresearchinstitute.org/pmwiki.php/PRT/HomePage) makes it quick and easy to create the runtime behavior of new parallel programming constructs. For example, the behavior of Cilk was created in an afternoon, likewise the behavior of pthreads. OpenMP behavior required a week of part time effort. And the performance is higher (except in the case of Cilk on single-chip machines). In this project we extend the proto-runtime toolkit to run on distributed hardware.

Intellectual Merit

Proto-runtime provides a number of benefits: fast exploration of new parallel programming models at high performance, automated specialization of language runtime code to new hardware, modularizing runtime system construction, separating runtime system from executable, enabling multiple languages/programming-models to be intimately mixed within the same application. These benefits, are currently only available for coherent shared memory hardware, and this project will extend the benefits to distributed memory hardware.

Broader Impacts

Having a distributed memory version of the Proto-Runtime Toolkit will enable more rapid exploration of new parallel programming models and allow the new models to safely and performantly be mixed with pre-existing ones within the same code base. This will bring enhanced productivity benefits to a wide class of programmers and developers of scientific and other applications.

Scale of Use

interactive use while developing the toolkit. The toolkit is like a middleware in one sense, and developing it means establishing basic functionality and debugging the distributed messages flowing between machines. There won't be any intensive computation, but I need interactive use while debugging. Most of the activity will be interactive testing of short runs, at most a few seconds each, separated by think time of several minutes or more. Multiple machines are required, and it is best if the physical machines in use don't change during a session -- IE, if the code runs inside of VMs, then it is best if the VMs do not migrate between machines while interactive debugging is taking place.

Results

Supplied as they become available: Stay tuned!