CHAPTER 5. VISUALISING EDEN PROGRAM RUNS: EDENTV
physical ones), the message traffic between these PEs, and the low-level behaviour of the underlying middleware like PVM [PVM] MPI [MPI97]. But the large gap between abstract language concepts and concrete runtime behaviour needs cus-tomisedhigh-leveltools for runtime analysis. The basic runtime and computation units of thelanguage, under programmer control and on top of the RTE, are hard to identify from this low-level view.
The Eden trace viewer tool (EdenTV) presented in this chapter visualises the execution of parallel functional Eden programs at a higher level of abstraction.
EdenTV shows the activity of the Edenthreads and processes, their mapping to the machines, stream communication between Eden processes, garbage collection phases, and the process generation tree, i.e. information specific to the Eden pro-gramming model. This supports the programmer’s understanding of the parallel behaviour of an Eden program.
EdenTV enables a post-mortem analysisof program executions at the level of the Eden RTE. The steps of profiling are trace generation and trace representa-tion, separated as much as possible in EdenTV, so that single parts can easily be maintained and modified for other purposes.
EdenTV has been developed as a supplement in the context of our work on the Eden implementation. Two versions of the trace representation tool are currently available. A Java implementation has been developed by Pablo Rold´an G´omez [RG04]. Bj¨orn Struckmeier [Str06] did a re-implementation in Haskell which provides additional features. Both tools had to undergo major revisions after the new implementation of Eden in GHC 6.
In this chapter, we will describe implementation concepts of EdenTV, and present examples of how the high-level EdenTV profiling tool can be profitably used to optimise and spot errors in high-level parallel programs (our related pub-lication [BL07b] contains similar case studies). Typical reasons for bad perfor-mance in our lazy functional setting are delayed evaluation or poor load balanc-ing between processes, easily identified by the trace visualisations. In addition, EdenTV works for EdI programs (it is based on the basic runtime computation units) and can thereby help detect bugs and weaknesses of the language imple-mentation itself. EdenTV timeline diagrams will be used throughout the rest of this thesis to support analysis and discussion of our skeleton implementations.
5.2. HOW EDENTV WORKS
Trace generation. To profile the execution of an Eden program, the RTS con-tinuously writesevents into a trace file. These trace events, shown in Figure 5.2, indicate the creation or a state transition of a computational unit. Trace events are emitted from the RTE, using the Pablo Trace Capture Library [Dan91] and its portable and machine-readable “Self-Defining Data Format”. Eden programs need not be changed to obtain the traces.
Runnable
Running
Finished
Blocked
new thread deblock thread
run thread
suspend thread
kill thread
kill thread block thread kill thread
Figure 5.1: Thread state transitions Start Machine End Machine
New Process Kill Process New Thread Kill Thread Run Thread Suspend Thread Block Thread Deblock Thread Send Message Receive Message Start Communication End Communication
Label Process GC done Figure 5.2: EdenTV trace events
The events which are traced during a program run collect information about the behaviour of machines, processes, threads and messages. Concurrent threads are the basic unit for the implementation, so the central task for profiling is to keep track of their execution. Threads are scheduledround-robinand run through the straightforward state transitions shown in Figure 5.1. An Eden process, as a purely conceptual unit, consists of a number of concurrent threads which share a common graph heap (as opposed to processes, which communicate via channels).
The Eden RTE does not support the migration of threads or processes to other machines during execution, so every thread is located on exactly one machine during its lifetime. The machines form a third category, and a self-suggesting one, since one file per machine is generated by the trace library.
Additional events (written in italics in Fig. 5.2) record underlying RTE ac-tions, garbage collection and communication phases, and allow to label new pro-cesses with a name (corresponding trace viewer features are only partially imple-mented).
CHAPTER 5. VISUALISING EDEN PROGRAM RUNS: EDENTV
(a) Machines graphic (b) Processes graphic
(c) . . . with messages overlay
Thread Count: 0≤Runnable Threads + Blocked Threads≤Total Threads Condition Machine Process Thread Black/White Colour
Total Threads = 0 Idle n/a n/a smaller bar Blue
Blocked + Runnable<Total Running Running Running dark grey Green Runnable Threads>0 System Time Runnable Runnable light grey Yellow
Runnable Threads = 0 Blocked Blocked Blocked black Red
(d) Explanation of colour codes
Figure 5.3: Examples of EdenTV diagrams and colour codes table
Trace representation. In the timeline diagrams generated by EdenTV, ma-chines, processes, and threads are represented by horizontal bars, with time on the x axis. EdenTV offers separate diagrams formachines,processes, andthreads.
The machines diagrams correspond to the view of profiling tools observing the parallel machine execution. Figure 5.3 shows examples of the machines and pro-cesses diagrams for a parallel divide-and-conquer program with limited recursion-depth. The trace has been generated on 8 Linux workstations connected via fast Ethernet. The diagram lines have segments in different colours, which indicate the activities of the respective logical unit in a period during the execution.
5.2. HOW EDENTV WORKS
Thread states can be directly concluded from the emitted events. Machine and process states are assigned following a fundamental equation for the thread count inside one process or machine:
0≤Runnable Threads + Blocked Threads≤Total Threads
Colour codes for processes and machines are assigned as a result of comparing these numbers. In general, the first condition checked by EdenTV is complete equality, i.e. whether the machine or process is inidlestate (Total Processes resp.
Total Threads= 0). Otherwise, a difference between the thread counts (inequality on the right) implies that a thread isrunning. If the thread counts on both sides are equal, the state is either runnable orblocked, depending on the number of runnable threads (the state isrunnable if Runnable Threads >0). This context information for all units is the basis of the graphical representations.
The example diagrams in Figure 5.3 show that the program has been executed on 8 machines (virtual PEs). While there is some continuous activity on machine 1 (the bottom line), where the main program is started, machines 6 to 8 (the upper three lines) are idle most of the time. The corresponding processes graphic (see Figure 5.3(a)) reveals that several Eden processes have been allocated on each machine. The diagrams show that the workload on the parallel machines was low — there were only small periods when threads were running. Messages between processes or machines can optionally be shown by arrows which start from the sending unit line and point at the receiving unit line (see Figure 5.3(c)).
The diagrams can be zoomed in order to get a closer view on the activities at critical points during execution.
Machine Runtime Processes Messages
(sec) sent received
1 0.287197 4 6132 6166
2 0.361365 18 1224 1206
...
8 0.362850 6 408 402
Total 0.371875 66 14784 14784
Additional features. Several ex-tensions to EdenTV have been made to provide additional information about the program run, beyond the basic ma-chine, process, thread and communica-tion informacommunica-tion. All EdenTV versions provide a summary of the messages sent and received by processes and ma-chines (on the right for the trace in
Figure 5.3). In the Haskell version, stream communication is indicated by shad-ing the area between the first and the last message of a stream (see Figure 5.3(c)), garbage collection phases and memory consumption can be shown in the activ-ity diagrams, and the process generation tree can be drawn and labelled with process names. In turn, the Java version offers to indicate the communication phases (when the RTE is receiving messages) by an additional color in the bar.
EdenTV is still under active development to add useful information, improve the efficiency of trace analysis, and continuously adapt to new RTE versions (main-taining backward compatibility whenever possible).
CHAPTER 5. VISUALISING EDEN PROGRAM RUNS: EDENTV