Proto-Runtime on the Grid

Project Information

Discipline

Computer Science (401) 

Subdiscipline

11.07 Computer Science 

Orientation

Research 

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.

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.

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.

Project Contact

Project Lead

Sean Halle (kshalle) 

Project Manager

Sean Halle (kshalle) 

Resource Requirements

Hardware Systems

• alamo (Dell optiplex at TACC)
• foxtrot (IBM iDataPlex at UF)
• hotel (IBM iDataPlex at U Chicago)
• india (IBM iDataPlex at IU)
• sierra (IBM iDataPlex at SDSC)

 

FutureGrid will provide the distributed memory hardware upon which the distributed version of the proto-runtime toolkit will be developed

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.

Project Timeline

Submitted

04/23/2014 - 15:58