Profiling large-scale lazy functional programs

Morgan, Richard G.; Jarvis, Stephen A.

doi:10.1017/s0956796898003013

Cited by 18 publications

(7 citation statements)

References 26 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Our model is based on the notion of cost centers, inspired from the work of Sansom and Peyton Jones [26] and Morgan and Jarvis [18]. This approach was also applied to Logic Programs and extended to perform run-time checking of non-functional properties in [17].…”

Section: From Dynamic Profiling To Static Profilingmentioning

confidence: 99%

A Transformational Approach to Parametric Accumulated-Cost Static Profiling

Haemmerlé

López-García

Liqat

et al. 2016

Functional and Logic Programming

View full text Add to dashboard Cite

Abstract. Traditional static resource analyses estimate the total resource usage of a program, without executing it. In this paper we present a novel resource analysis whose aim is instead the static profiling of accumulated cost, i.e., to discover, for selected parts of the program, an estimate or bound of the resource usage accumulated in each of those parts. Traditional resource analyses are parametric in the sense that the results can be functions on input data sizes. Our static profiling is also parametric, i.e., our accumulated cost estimates are also parameterized by input data sizes. Our proposal is based on the concept of cost centers and a program transformation that allows the static inference of functions that return bounds on these accumulated costs depending on input data sizes, for each cost center of interest. Such information is much more useful to the software developer than the traditional resource usage functions, as it allows identifying the parts of a program that should be optimized, because of their greater impact on the total cost of program executions. We also report on our implementation of the proposed technique using the CiaoPP program analysis framework, and provide some experimental results.

show abstract

Section: From Dynamic Profiling To Static Profilingmentioning

confidence: 99%

A Transformational Approach to Parametric Accumulated-Cost Static Profiling

Haemmerlé

López-García

Liqat

et al. 2016

Functional and Logic Programming

View full text Add to dashboard Cite

show abstract

“…Thus, rather than aggregating the cost of all executing steps, it is more useful to treat execution steps that occur on different computing infrastructures separately. With this aim, we adopt the notion of cost centres , proposed for profiling functional programs. Because the concurrency unit of our language is the object, cost centres are used to charge the cost of each step to the cost centre associated to the object where the step is performed.…”

Section: Cost and Cost Models For Concurrent Programsmentioning

confidence: 99%

“…The main contributions of this work are as follows: We present a flow‐sensitive object‐sensitive points‐to analysis for concurrent programs that adapts Milanova's analysis framework for Java to the concurrent object setting. We introduce a sound size analysis for concurrent execution. The analysis is field‐sensitive , that is, it tracks data stored in the heap whenever it is sound to do so; the accuracy of the field‐sensitive size analysis can be increased by means of class invariants that contain information on the shared memory. We leverage the definition of cost used in sequential programming to the distributed setting by relying on the notion of cost centres , which represent the (distributed) components and allow separating their costs. We present a novel form of object‐sensitive recurrence relations that relies on information gathered by the previous object‐sensitive points‐to analysis in order to generate the cost equations. Interestingly, the resulting recurrence relations can still be solved to closed‐form upper/lower bounds using standard solvers for cost analysis of sequential programs. We report on the SACOsystem, a prototype implementation of a cost analyser for programs written in ABS (an Abstract Behavioural Specification language based on concurrent objects).…”

Section: Introductionmentioning

confidence: 99%

Object‐sensitive cost analysis for concurrent objects

Albert

Arenas

Fernández

et al. 2015

Software Testing Verif & Rel

View full text Add to dashboard Cite

This article presents a novel cost analysis framework for concurrent objects. Concurrent objects form a wellestablished model for distributed concurrent systems. In this model, objects are the concurrency units that communicate among them via asynchronous method calls. Cost analysis aims at automatically approximating the resource consumption of executing a program in terms of its input parameters. While cost analysis for sequential programming languages has received considerable attention, concurrency and distribution have been notably less studied. The main challenges of cost analysis in a concurrent setting are as follows. First, inferring precise size abstractions for data in the program in the presence of shared memory. This information is essential for bounding the number of iterations of loops. Second, distribution suggests that analysis must infer the cost of the diverse distributed components separately. We handle this by means of a novel form of object-sensitive recurrence equations that use cost centres in order to keep the resource usage assigned to the different components separate. We have implemented our analysis and evaluated it on several small applications that are classical examples of concurrent and distributed programming. consider different types of resources of interest. For instance, we can measure traditional cost measures like number of executed instructions or memory consumption. In the former case, we will infer that 3 C elems .7 C hdRead inst C update inst / instructions will be executed. In the expression, elems corresponds to the maximum number of iterations of the loop; at each iteration, seven instructions are executed (the loop condition, the two increments, two method invocations, the get and the await), and the number of instructions of executing methods hdRead and update, denoted hdRead inst and update inst respectively, are added as well. For simplicity, we ignore here the values of the parameters. Besides, three instructions are executed outside the loop. The analysis will need to infer also the cost of the methods hdRead and update and plug them in the aforementioned expression. With regard to memory consumption, a new memory is not created in the loop; hence, we would output an expression of the form elems .hdRead heap C update heap / that relies on the memory created by the invoked methods (denoted hdRead heap and update heap ). Interestingly, we can also consider concurrency-related measures like the number of tasks spawned. In the aforementioned method, we spawn one task directly (but the method invocations might also spawn new tasks transitively). Therefore, we will compute an expression of the form elems .1ChdRead tasks Cupdate tasks / that relies on the number of tasks spawned by the calls to hdRead and update. Observe that the types of resources we have considered are platform independent (unlike WCET or energy consumption), that is, they can be inferred by inspecting the program, and the hardware on which the program will be executed can be ignored. Platform depend...

show abstract

“…Morgan and Jarvis [11] noticed that users of profilers often want to change the granularity. For example, they might start with a few cost centres, but on noticing that one cost centre has particularly high costs, they might introduce more cost centres to break down the costs of the conspicuous cost centre.…”

Section: Ghc's Cost Centre Stacks For Profilingmentioning

confidence: 99%

“…In contrast to debugging, time and space profiling of lazy functional programs is not only well-studied [9,11,19], but the Glasgow Haskell Compiler 1 (GHC) also provides reliable profiling for real-world Haskell programs. Trace stacks are key for it attributing time and space costs to parts of a program.…”

Section: Introductionmentioning

confidence: 99%

Algorithmic debugging of real-world haskell programs: deriving dependencies from the cost centre stack

Faddegon

Chitil

2015

Proceedings of the 36th ACM SIGPLAN Conference on Programming Language Design and Implementation

View full text Add to dashboard Cite

Existing algorithmic debuggers for Haskell require a transformation of all modules in a program, even libraries that the user does not want to debug and which may use language features not supported by the debugger. This is a pity, because a promising approach to debugging is therefore not applicable to many real-world programs. We use the cost centre stack from the Glasgow Haskell Compiler profiling environment together with runtime value observations as provided by the Haskell Object Observation Debugger (HOOD) to collect enough information for algorithmic debugging. Program annotations are in suspected modules only. With this technique algorithmic debugging is applicable to a much larger set of Haskell programs. This demonstrates that for functional languages in general a simple stack trace extension is useful to support tasks such as profiling and debugging.

show abstract

Profiling large-scale lazy functional programs

Cited by 18 publications

References 26 publications

A Transformational Approach to Parametric Accumulated-Cost Static Profiling

A Transformational Approach to Parametric Accumulated-Cost Static Profiling

Object‐sensitive cost analysis for concurrent objects

Algorithmic debugging of real-world haskell programs: deriving dependencies from the cost centre stack

Contact Info

Product

Resources

About