Speed

Abstract

This paper describes an inter-procedural technique for computing symbolic bounds on the number of statements a procedure executes in terms of its scalar inputs and user-defined quantitative functions of input data-structures. Such computational complexity bounds for even simple programs are usually disjunctive, non-linear, and involve numerical properties of heaps. We address the challenges of generating these bounds using two novel ideas. We introduce a proof methodology based on multiple counter instrumentation (each counter can be initialized and incremented at potentially multiple program locations) that allows a given linear invariant generation tool to compute linear bounds individually on these counter variables. The bounds on these counters are then composed together to generate total bounds that are non-linear and disjunctive. We also give an algorithm for automating this proof methodology. Our algorithm generates complexity bounds that are usually precise not only in terms of the computational complexity, but also in terms of the constant factors. Next, we introduce the notion of user-defined quantitative functions that can be associated with abstract data-structures, e.g., length of a list, height of a tree, etc. We show how to compute bounds in terms of these quantitative functions using a linear invariant generation tool that has support for handling uninterpreted functions. We show application of this methodology to commonly used data-structures (namely lists, list of lists, trees, bit-vectors) using examples from Microsoft product code. We observe that a few quantitative functions for each data-structure are usually sufficient to allow generation of symbolic complexity bounds of a variety of loops that iterate over these data-structures, and that it is straightforward to define these quantitative functions. The combination of these techniques enables generation of precise computational complexity bounds for real-world examples (drawn from Microsoft product code and C++ STL library code) for some of which it is non-trivial to even prove termination. Such automatically generated bounds are very useful for early detection of egregious performance problems in large modular codebases that are constantly being changed by multiple developers who make heavy use of code written by others without a good understanding of their implementation complexity.

A Comprehensive Review of Direction-of-Arrival Estimation and Localization Approaches in Mixed-Field Sources Scenario

“…The last column of Table 3 shows the total computational complexity of each method. Computational complexity is another quantitative comparison measure that indicates the number of arithmetic operations of an algorithm and determines the amount of resources required to execute that algorithm [374]. The total computational complexities of the algorithms in Table 3 are calculated by considering the major multiplications involved in the construction of statistics matrices, eigendecomposition, spectral search, sparse signal recovery process, matrix inversion, selecting of tuning factor, constructing matrix, whitening reduction dimension, diagonalizing and orthogonal propagation [375].…”

An Automatic Transformer from Sequential to Parallel Java Code

“…Therefore, the last part of the proposed analysis determines if the amount of work that will be assigned to both threads is balanced and adequately large to make it worth the effort required to start a new thread. Several studies show how the number of statements is significant in evaluating the computational complexity of an algorithm [39,40]. Our approach uses the control flow graph theory to inspect the execution paths and evaluate the number of instructions that compose each path.…”

A modular cost analysis for probabilistic programs

“…Finally, we also point out that eco-imp is competitive with regards to automated complexity analysis tools on deterministic programs. For illustration, we complemented the experimental evaluation from Carbonneaux et al [2015], comparing their tools 4 , KoAT [Brockschmidt et al 2014], Rank [Alias et al 2010] and Speed [Gulwani et al 2009], on the 34 deterministic integer programs from their benchmark. 3 Here, 4 outperforms the mentioned tools by a great margin, as 4 can solve at least 10 more examples in each comparison.…”

“…This resulted in significant success stories showing that resource analysis can be practicable and scalable, cf. [Frohn and Giesl 2017;Gulwani et al 2009;Wilhelm et al 2008;Wilhelm and Grund 2014]. Modularity of the analysis turned out as a key ingredient to the scalability of automated resource analysis, as modularity allows for code fragments to be analysed in full independence, so that, whole-program analyses can be overcome.…”