[Paper Review] Profiling parallel Mercury programs with ThreadScope

Paul Bone, Zoltán Somogyi|arXiv (Cornell University)|Sep 7, 2011

Parallel Computing and Optimization Techniques10 references3 citations

TL;DR

This paper proposes adapting the ThreadScope profiler—originally designed for parallel Haskell programs—to profile parallel Mercury programs. By extending ThreadScope to capture Mercury-specific metrics such as call sequence counts, garbage collection statistics, and task-level performance data, the authors enable detailed visualization and analysis of parallel execution behavior, aiding application developers, runtime system implementors, and autoparallelization tool researchers.

ABSTRACT

The behavior of parallel programs is even harder to understand than the behavior of sequential programs. Parallel programs may suffer from any of the performance problems affecting sequential programs, as well as from several problems unique to parallel systems. Many of these problems are quite hard (or even practically impossible) to diagnose without help from specialized tools. We present a proposal for a tool for profiling the parallel execution of Mercury programs, a proposal whose implementation we have already started. This tool is an adaptation and extension of the ThreadScope profiler that was first built to help programmers visualize the execution of parallel Haskell programs.

Motivation & Objective

• To address the difficulty of diagnosing performance bottlenecks in parallel Mercury programs, which are exacerbated by issues unique to parallelism such as task overhead and load imbalance.
• To enable application programmers to understand and optimize the behavior of their parallel Mercury programs through visual and metric-based profiling.
• To support runtime system implementors in measuring and improving low-level behaviors like worker-thread responsiveness and cache affinity.
• To assist autoparallelization tool developers in calibrating cost-benefit heuristics by providing accurate, measurable performance data from real program executions.

Proposed method

• Extending the ThreadScope profiler to collect Mercury-specific execution metrics, including call sequence counts (CSCs), garbage collection (GC) statistics, and mutator vs. GC time ratios.
• Adapting ThreadScope’s visualization framework to display parallel conjunctions and their individual conjuncts with color-coded timelines showing CPU usage and task lifetimes.
• Adding interactive GUI features to allow users to hover over events and query dynamic metrics such as NANOSECS_PER_CALL, GC_STATS, and MUTATOR_VS_GC_TIME.
• Implementing a feature to list all dynamic occurrences of parallel conjunctions and enable navigation to their timeline representations.
• Designing a machine-readable output format to export all relevant metrics for use in tuning automatic parallelization tools.
• Leveraging existing ThreadScope infrastructure to minimize development overhead while ensuring extensibility and compatibility with Mercury’s runtime semantics.

Experimental results

Research questions

• RQ1 How can existing profiling tools for functional languages be adapted to support the unique execution model of logic programming languages like Mercury?
• RQ2 What specific performance metrics are most valuable for diagnosing issues in dependent AND-parallel logic programs?
• RQ3 Can ThreadScope’s visualization and metric collection capabilities be extended to support the dynamic behavior of Mercury’s parallel conjunctions and task scheduling?
• RQ4 How can profiling data be used to improve the accuracy of autoparallelization heuristics in logic programming?
• RQ5 What insights into runtime system behavior—such as worker-thread responsiveness and cache locality—can be extracted from profiled executions?

Key findings

• The adaptation of ThreadScope to Mercury enables visualization of parallel execution with timelines that reflect CPU usage, task creation, and blocking behavior, similar to its use in Haskell.
• The system successfully captures and exposes key performance metrics such as NANOSECS_PER_CALL, GC_STATS, and MUTATOR_VS_GC_TIME, which are essential for performance tuning.
• Interactive GUI features allow users to query dynamic metrics at the level of individual parallel conjunctions or their conjuncts, enabling fine-grained analysis.
• The tool supports the generation of machine-readable output files containing all relevant performance metrics, facilitating integration with autoparallelization tools for calibration.
• The authors have implemented at least one-third of the proposed metrics by the time of the workshop, with full support expected by year’s end.
• The approach demonstrates that leveraging existing, proven profiling infrastructure can significantly reduce the cost of building domain-specific performance analysis tools for complex parallel systems.