Marcin Zalewski

A comparison of c++ concepts and haskell type classes

Earlier studies have introduced a list of high-level evaluation criteria to assess how well a language supports generic programming. Since each language that meets all criteria is considered generic, those criteria are not fine-grained enough to differentiate between languages for generic programming. We refine these criteria into a taxonomy that captures differences between type classes in Haskell and concepts in C++, and discuss which differences are incidental and which ones are due to other language features. The taxonomy allows for an improved understanding of language support for generic programming, and the comparison is useful for the ongoing discussions among language designers and users of both languages.

Change Impact Analysis for Generic Libraries

Since the standard template library (STL), generic libraries in C++ rely on concepts to precisely specify the requirements of generic algorithms (function templates) on their parameters (template arguments). Modifying the definition of a concept even slightly, can have a potentially large impact on the (interfaces of the) entire library. In particular the non-local effects of a change, however, make its impact difficult to determine by hand. In this paper we propose a conceptual change impact analysis (CCIA), which determines the impact of changes of the conceptual specification of a generic library. The analysis is organized in a pipe-and-filter manner, where the first stage finds any kind of impact, the second stage various specific kinds of impact. Both stages describe reachability algorithms, which operate on a conceptual dependence graph. In a case study, we apply CCIA to a new proposal for STL iterator concepts, which is under review by the C++ standardization committee. The analysis shows a number of unexpected incompatibilities and, for certain STL algorithms, a loss of genericity

Generic programming with c++ concepts and haskell type classes: A comparison

Earlier studies have introduced a list of high-level evaluation criteria to assess how well a language supports generic programming. Languages that meet all criteria include Haskell because of its type classes and C++ with the concept feature. We refine these criteria into a taxonomy that captures commonalities and differences between type classes in Haskell and concepts in C++ and discuss which differences are incidental and which ones are due to other language features. The taxonomy allows for an improved understanding of language support for generic programming, and the comparison is useful for the ongoing discussions among language designers and users of both languages.

A Semantic Definition of Separate Type Checking in C++ with Concepts

We formalize the informal definition of C++ concepts that is currently considered by the C++ standardization committee for inclusion in the next version of the language. Our definition captures the basic semantics of separate type checking, where conceptconstrained templates are checked separately from their uses and comprises of three main parts: non-standard name lookup, type checking of constrained templates, and implementation binding in concept maps. The formalization reveals two possible problems in the informal definition: hiding of names is not respected and incompatible implementations can be bound to concept entities. Furthermore, our definition allows formulating intuitively correct code that is rejected by the informal specification.

C++ concepts as institutions: a specification view on concepts

With the recent developments in the C++ language, concepts are mostly discussed as a form of constrained polymorphism. Yet, concepts also allow for an alternative, implementation-independent view that comes from their origin in (algebraic) specification languages. In this paper, we return to this specification view on concepts and formalize C++ concepts as institutions, a well-established notion for precise specifications of software components. We argue that institutions form a suitable theoretical framework for software systems like libraries where the different parts establish relations that are captured by different logics, or no formal logic at all. Assuming the C++ concept descriptions, concept maps, and axioms as in the draft currently accepted by the C++ standardization committee, we show that concept descriptions and axioms form an institution (with equational logic) but also, and perhaps surprisingly, that concept descriptions and concept maps form an institution (with no formal logic).

Generic Libraries in C++ with Concepts from High-Level Domain Descriptions in Haskell

A class of closely related problems, a problem domain, can often be described by a domain-specific language, which consists of algorithms and combinators useful for solving that particular class of problems. Such a language can be of two kinds: it can form a new language or it can be embedded as a sublanguage in an existing one. We describe an embedded DSL in the form of a library which extends a general purpose language. Our domain is that of vulnerability assessment in the context of climate change, formally described at the Potsdam Institute for Climate Impact Research. The domain is described using Haskell, yielding a domain specific sublanguage of Haskell that can be used for prototyping of implementations. In this paper we present a generic C++ library that implements a domain-specific language for vulnerability assessment, based on the formal Haskell description. The library rests upon and implements only a few notions, most importantly, that of a monadic system, a crucial part in the vulnerability assessment formalisation. We describe the Haskell description of monadic systems and we show our mapping of the description to generic C++ components. Our library heavily relies on concepts , a C++ feature supporting generic programming: a conceptual framework forms the domain-specific type system of our library. By using functions, parametrised types and concepts from our conceptual framework, we represent the combinators and algorithms of the domain. Furthermore, we discuss what makes our library a domain specific language and how our domain-specific library scheme can be used for other domains (concerning language design, software design, and implementation techniques).

Importance of Runtime Considerations in Performance Engineering of Large-Scale Distributed Graph Algorithms

Due to the ever increasing complexity of the modern supercomputers, performance analysis of irregular applications became an experimental endeavor. We show that runtime considerations are inseparable from algorithmic concerns in performance engineering of large-scale distributed graph algorithms, and we argue that the whole system stack, starting with the algorithm at the top down to low-level communication libraries must be considered.

A scalable distance-1 vertex coloring algorithm for power-law graphs

We propose a distributed, unordered, label-correcting distance-1 vertex coloring algorithm, called Distributed Control (DC) coloring algorithm. DC eliminates the need for vertex-centric barriers and global synchronization for color refinement, relying only on atomic operations and local termination detection to update vertex color. We implement our DC coloring algorithm and the well-known Jones-Plassmann algorithm in the AM++ AMT runtime and compare their performance. We show that, with runtime support, the elimination of waiting time of vertex-centric barriers and investing this time for local ordering results in better execution time for power-law graphs with dense local subgraphs.

Improving Performance of Distributed Graph Traversals via Application-Aware Plug-In Work Scheduler

Unordered graph algorithms can offer efficient resource utilization that is advantageous for performance in distributed setting. Unordered execution allows for parallel computation without synchronization. In unordered algorithms, work is data-driven and can be performed in any order, refining the result as the algorithm progresses. Unfortunately, a sub-optimal work ordering may lead to more time spent on correcting the results than on useful work. On HPC systems, the issue is compounded by irregular nature of distributed graph algorithms which makes them sensitive to the whole software/hardware stack, collectively referred to as runtime. In this paper, we consider an example of such algorithms: Distributed Control (DC) single-source shortest paths (SSSP). DC relies on performance gains stemming from the inherent asynchrony of unordered algorithms while optimizing work ordering locally. We demonstrate that distributed runtime scheduling policy can prevent effective work ordering optimization. We show that lifting and delegating some scheduling decisions to the algorithm level can result in significantly better performance. We propose that this strategy can be useful for performance engineering.