Date post: | 18-Dec-2015 |
Category: |
Documents |
Upload: | susanna-joseph |
View: | 217 times |
Download: | 0 times |
Multilingual Debugging Support for Data-driven Parallel Languages
Parthasarathy Ramachandran
Laxmikant KaleParallel Programming Laboratory
Dept. of Computer Science
University of Illinois at Urbana Champaign
Data driven execution: motivation
• Latency – openMP: remote access– MPI: a blocking receive
• Response delay: remote processor may be busy
• Latency Tolerance:– Basic idea: have multiple items on your agenda– Overlap “wait for data” with useful
computation
Data driven systems
• Data flow machines
• Functional and Logic languages (1983-)– Rediflow (Keller/Lindstrom), ..– Prolog: Conery, Kale, ..
• Actors
• Charm/Chare Kernel: 1987– first implementation on parallel machines
• Multipol, Cid, Chant, Tulip, ..
What is data driven execution
• Multiple entities per processor– Objects, threads, handlers, …
• Scheduled based on availability of data
Data driven execution
Scheduler Scheduler
Message Q Message Q
Data driven execution
• Existence of scheduler : DDE pre-requisite
• Implicit control transfer– e.g. when a thread blocks for a recv, control
transfers to a module of system’s choice
Data driven execution
• Advantages:– Adaptive overlap of useful computation with
idle time– Multiple modules: efficiency and modularity
• overlap idle time in one module with useful computation from another
• MPI/PVM modules can’t do this (as well), without sacrificing modularity
Debugging problem
• Implicit control transfer leads to debugging difficulties– Unpredictable “jumps”– Need to observe scheduler’s queue– Need to use scheduling quanta
• I.e. step to the next event
• Here:– A general purpose framework for debugging
data-driven programs
Converse
• Many data-driven languages/paradigms– Which one is “right”?– Acceptance barriers– Coexistence with monsters (MPI/openMP)
• Our solution: interoperability– Not the same as C++/Fortran interoperabilty– Ability to integrate modules written in different
paradigms in a single program– E.g. MPI, Charm++, Chant
Converse
• Supports multi-paradigm programming
• Provides portability
• Makes it easy to implement RTS for new paradigms
• Several languages/libraries:– Charm++, Java, threaded MPI, PVM, md-perl,
pc++, Nexus, Path, Tempo, Cid, CC++,..– More info: http://charm.cs.uiuc.edu
Example application:
Debugging Multi-paradigm Multi-lingual Programs
• New problems:– Scheduler entities belong to different languages– Need ability to set language specific
breakpoints
• Also:– Integration with “normal” debugging methods
• Source level debugging: e.g. gdb
– Need to freeze execution properly
Inadequacy of current methods
• Can we use gdb? (for example)– Scheduler code inaccessible– Cannot focus on specific breakpoints
• If we set a breakpoint in the scheduler
– Scheduler entities belong to different languages• How to view them uniformly?
• Need support for language implementors
Converse debugging framework
• Freeze and Thaw:– External intervention– Freeze schedulers (on one or all processors)– Ensure bookkeeping tasks continue– Scheduler processes debugging commands only
• Scheduler level language-specific breakpoints
• Language-specific viewing – of scheduler entries (e.g. method invocation, msg)– of resident entities (e.g. objects, threads)
Architecture
• Uses converse’ client-server interface– Can inject messages into running programs– Can send responses via TCP sockets– Used for other purposes as well:
• E.g. Web based submission/monitoring
Architecture
• Debugger client:– Java based, GUI/communication
• Debugger runtime library– A module in Converse runtime– Provides hooks for languages/libraries
• GDB interface– Integrates source level debugging– Can customize for other debuggers
Viewing multilingual entities
• Scheduler’s view:– Each entry– The header contains a handler index– Handlers are registered by languages
• Language runtimes register callback functions• showHeader: returns a short string
• showContent: returns a long string with newLines
– On “freeze” scheduler sends list of headers– On demand, sends the result of showContent
header
gibberish
Non scheduler entities
• Objects and other data structures– Not in the scheduler’s queue– But still important to view– Same problem: multiple languages
• Solution– Each language registers each of its objects– For C++ object, use virtual inheritance– For others, registered callbacks
Breakpoints
• Are language specific– Charm++: list of remotely invokable methods– Multipol: handler function names, Chant: Code
• Each language supplies– A list of breakpoints (names and indices)– RTS maintains list of set breakpoints– note: a handler may represent multiple breakpoints– Given a scheduler entry,
• language RTS identifies breakpoint number
Optimizations
• Data transfer between the runtime and client– Chunking: send only a viewable screenful of
information at a time– Caching:
• use idle time while user inspects data to collect and prepare information
Summary
• Debugger is in operational use on – Workstation clusters– Parallel machines (Origin 2000, T3E)
• Complements source level debuggers
• Provides a useful functionality for all data-driven languages/libraries
• If you use Converse for your RTS, you will get this functionality for free…
http://charm.cs.uiuc.edu