Oink: An Implementation and Evaluation of Modern Parity Game Solvers
Abstract
Parity games have important practical applications in formal verification and synthesis, especially to solve the modelchecking problem of the modal mucalculus. They are also interesting from the theory perspective, as they are widely believed to admit a polynomial solution, but so far no such algorithm is known. In recent years, a number of new algorithms and improvements to existing algorithms have been proposed. We implement a new and easy to extend tool Oink, which is a highperformance implementation of modern parity game algorithms. We further present a comprehensive empirical evaluation of modern parity game algorithms and solvers, both on real world benchmarks and randomly generated games. Our experiments show that our new tool Oink outperforms the current stateoftheart.
1 Introduction
Parity games are turnbased games played on a finite graph. Two players Odd and Even play an infinite game by moving a token along the edges of the graph. Each vertex is labeled with a natural number priority and the winner of the game is determined by the parity of the highest priority that is encountered infinitely often. Player Odd wins if this parity is odd; otherwise, player Even wins.
Parity games are interesting both for their practical applications and for complexity theoretic reasons. Their study has been motivated by their relation to many problems in formal verification and synthesis that can be reduced to the problem of solving parity games, as parity games capture the expressive power of nested least and greatest fixpoint operators [17]. In particular, deciding the winner of a parity game is polynomialtime equivalent to checking nonemptiness of nondeterministic parity tree automata [33], and to the explicit modelchecking problem of the modal \(\mu \)calculus [14, 15, 23, 32].
Parity games are interesting in complexity theory, as the problem of determining the winner of a parity game is known to lie in \(\text {UP}\cap \text {coUP}\) [26], as well as in \(\text {NP}\,\cap \,\text {coNP}\) [15]. This problem is therefore unlikely to be NPcomplete and it is widely believed that a polynomial solution may exist. Despite much effort, no such algorithm has yet been found.
Motivated by recent publications with both novel approaches and improvements to known algorithms, we implement a number of modern solvers in our new tool Oink, which aims to provide a highperformance implementation of parity game solvers. Oink is designed as a library that integrates with other tools and can easily be extended. We use Oink to provide a modern empirical evaluation of parity game solvers based on both real world benchmarks and randomly generated games.
In past publications new and improved algorithms are often tested against the implementation of Zielonka’s algorithm in the PGSolver tool [19]. However, various recent publications [1, 34, 40] suggest that much better performance can be obtained. We combine a number of improvements from the literature [34, 40, 41] and propose additional optimizations. We show that our implementation of Zielonka’s algorithm outperforms PGSolver by several orders of magnitude.
We describe Oink in Sect. 3 and provide accessible descriptions of the implemented stateoftheart algorithms in Sects. 4–7. We implement the strategy improvement algorithm (Sect. 4), both the small progress measures and the recently proposed quasipolynomial progress measures algorithms (Sect. 5), the wellknown Zielonka algorithm (Sect. 6) as well as a number of related algorithms from the priority promotion family (Sect. 7). We also propose an alternative multicore implementation of strategy improvement.
2 Preliminaries
Parity games are twoplayer turnbased infiniteduration games over a finite directed graph \(G=(V,E)\), where every vertex belongs to exactly one of two players called player Even and player Odd, and where every vertex is assigned a natural number called the priority. Starting from some initial vertex, a play of both players is an infinite path in G where the owner of each vertex determines the next move. The winner of such an infinite play is determined by the parity of the highest priority that occurs infinitely often along the play.
More formally, a parity game Open image in new window is a tuple Open image in new window where Open image in new window is a set of vertices partitioned into the sets Open image in new window controlled by player Even and Open image in new window controlled by player Odd, and \(E\subseteq V\times V\) is a total relation describing all possible moves, i.e., every vertex has at least one successor. We also write E(u) for all successors of u and \(u\rightarrow v\) for \(v\in E(u)\). The function Open image in new window assigns to each vertex a priority, where d is the highest priority in the game.
We write \(\textsf {pr}(v)\) for the priority of a vertex v and \(\textsf {pr}(V)\) for the highest priority of a set of vertices V and Open image in new window for the highest priority in the game Open image in new window . Furthermore, we write \(\textsf {pr}^{1}(i)\) for all vertices with the priority i. A path \(\pi =v_0 v_1 \dots \) is a sequence of vertices consistent with E, i.e., \(v_i \rightarrow v_{i+1}\) for all successive vertices. A play is an infinite path. We write \(\textsf {pr}(\pi )\) for the highest priority in \(\pi \) is \(\pi \) is finite, or the highest priority that occurs infinitely often if \(\pi \) is infinite. Player Even wins a play \(\pi \) if \(\textsf {pr}(\pi )\) is even; player Odd wins if \(\textsf {pr}(\pi )\) is odd.
A strategy \(\sigma :V\rightarrow V\) is a partial function that assigns to each vertex in its domain a single successor in E, i.e., \(\sigma \subseteq E\). We typically refer to a strategy of player \(\alpha \) to restrict \(\sigma \) to all vertices controlled by player \(\alpha \). A player wins a vertex if they have a strategy such that all plays consistent with this strategy are winning for the player. A fundamental result for parity games is that they are memoryless determined [13], i.e., each vertex is winning for exactly one player, and both players have a strategy for each of their winning vertices.
2.1 Solvers
We briefly introduce several approaches to solving parity games. These approaches can be roughly divided into two categories.
First, several algorithms iteratively perform local updates to vertices until a fixed point is reached. Each vertex is equipped with some measure which records the best game either player knows that they can play from that vertex so far. By updating measures based on the successors, they play the game backwards. The final measures indicate the winning player of each vertex and typically a winning strategy for one or both players. The strategy improvement algorithm (Sect. 4) and the progress measures algorithms (Sect. 5) fall into this category.
Second, several algorithms employ attractor computation to partition the game into regions that share a certain property. This partition is refined until the winners of some or all vertices can be identified, as well as the strategy for the winning player(s). The recursive Zielonka algorithm (Sect. 6) and the recently proposed priority promotion algorithms (Sect. 7) fall into this category.
2.2 Empirical Evaluation
Our goal in the empirical study is threefold. First, we aim to compare modern algorithms and treat them fairly. We therefore need to establish that our implementation is competitive with existing work. Second, we compare the algorithms that are implemented in Oink directly. Third, as two algorithms have a parallel implementation, we also study the obtained parallel speedup and the parallel overhead when going from a sequential to a multicore implementation.

low outdegree random games (randomgame N N 1 2 x)
\(N \in \{\, 100, 200, 500, 1000, 2000, 5000, 10000, 20000 \,\}\)

fully random games (randomgame N N 1 N x)
\(N \in \{\, 100, 500, 1000, 2000, 4000 \,\}\)

lowdegree steady games (steadygame N 1 4 1 4)
\(N \in \{\, 100, 200, 500, 1000, 2000, 5000, 10000, 20000 \,\}\)
We generate 20 games for each parameter N, in total 420 random games. We include lowdegree games, since the solvers may behave differently on games where all vertices have few edges.
We present the evaluation in two ways. We compare runtimes of algorithms and penalize algorithms that do not finish on time (with a timeout of 15 min) by a factor \(2\times \) (PAR2), i.e., we assume that their runtime is \(2\times \) the timeout. This may still be quite optimistic. Compared to a timeout of 10 min, only few more games could be solved in 15 min. We also generate socalled cactus plots (often used to compare solvers in the SAT community) that show that a solver solved X models within Y seconds individually.
All experimental scripts and log files are available online via http://www.github.com/trolando/oinkexperiments. The experiments were performed on a cluster of Dell PowerEdge M610 servers with two Xeon E5520 processors and 24 GB internal memory each. The tools were compiled with gcc 5.4.0.
3 Oink
We study modern parity game algorithms using our research tool named Oink. Oink is written in C++ and is publicly available under a permissive license via https://www.github.com/trolando/oink. Oink is easy to extend, as new solvers subclass the Solver class and only require a few extra lines in solvers.cpp.
Apart from implementing the full solvers described below, Oink also implements several preprocessors similar to other parity game solvers. We base our choices mainly on the practical considerations and observations by Friedmann and Lange [19] and by Verver [41]. We always reorder the vertices by priority and renumber the priorities from 0 to eliminate gaps (not the same as compression). The former is beneficial for the attractorbased algorithms in Sects. 6 and 7. The latter may reduce the amount of memory required for the measuresbased algorithms in Sects. 4 and 5.
The following preprocessors are optional. Oink can perform priority inflation and priority compression, as described in [19]. We implement selfloop solving and winnercontrolled winning cycle detection, as proposed in [41]. Winnercontrolled winning cycle detection is a prerequisite for the strategy improvement algorithm of Sect. 4 but is optional for the other algorithms. We trivially solve games with only a single parity. Finally, we also implement SCC decomposition, which repeatedly solves a bottom SCC of the game until the full game is solved.
The correctness of an algorithm does not imply that implementations are correct. Although a formal proof of the implementations would be preferred, we also implement a fast solution verifier and verify all obtained solutions.
4 Strategy Improvement
Strategy improvement is a technique where each player iteratively improves their strategies until they are optimal. Strategy improvement algorithms were first explored for parity games by Jurdziński and Vöge [42] and have been subsequently improved in [7, 16, 20, 35, 38]. Recently, parallel implementations have been studied for the GPU [17, 24, 36]. Fearnley [17] also implements their parallel algorithm for multicore CPUs. Our treatment in this section is mostly based on [17, 35].
In the strategy improvement algorithm, player Even has a strategy \(\sigma \) and player Odd has a strategy \(\tau \) for all their vertices. They improve their strategies until a fixed point is reached, at which point the game is solved. Instead of choosing a successor, player Even may also end the play. In the specific algorithm here, player Even delays selecting a strategy for a vertex until there is a favorable continuation. As \(\sigma \) and \(\tau \) cover all vertices, they induce a fixed path from each vertex. This path is either infinite (a play) or ends at a vertex of player Even. The strategy is evaluated by computing a valuation for each vertex based on the current paths. Strategies are improved by choosing the most favorable successor.
The valuation used in e.g. [17, 35] assigns to (infinite) plays the value \(\top \) and to (finite) paths a function L(p) that records for each priority p how often it occurs in the path. To determine the best move for each player, a total order \(\sqsubset \) compares valuations as follows. For non\(\top \) valuations \(L_1\) and \(L_2\), \(L_1 \sqsubset L_2\) iff there exists a highest priority z that is different in \(L_1\) and \(L_2\), i.e., \(z = \max \,\{\, z \mid L_1(z) \ne L_2(z) \,\}\), and either \(L_1(z)<L_2(z)\) if z is even, or \(L_1(z)>L_2(z)\) if z is odd. Furthermore, \(L\sqsubset \top \) for any \(L\ne \top \). If \(L_1 \sqsubset L_2\), then \(L_2\) is more favorable for player Even and \(L_1\) is more favorable for player Odd.
Intuitively, player Even likes plays where higher even priorities occur more often. Furthermore, player Even will end the play unless the highest priority in the continuation is even. Thus infinite paths are won by player Even and the valuation \(\top \) represents this. Player Even will always play to \(\top \) and player Odd will always try to avoid \(\top \). This assumes that no winnercontrolled winning cycles exist where player Odd wins, which can be guaranteed using a preprocessing step that removes these cycles.
For every strategy \(\sigma \) of player Even, a socalled best response \(\tau \) of player Odd minimizes the valuation of each position. Player Even always plays against this best response. In each iteration, after player Odd computes their best response, player Even computes all switchable edges based on the current valuation L and the current strategy \(\sigma \). An edge (u, v) is switchable if \(L_v \sqsupset L_{\sigma (u)}\). Not all switchable edges need to be selected for the improved strategy, but as argued in [17], the greedy allswitches rule that simply selects the best edge (maximal in \(\sqsubset \)) for every position performs well in practice.
The valuations can be computed in different ways. Fearnley implements a parallel algorithm that uses list ranking in two steps. The first step computes an Euler tour of the game restricted to chosen strategies \(\sigma \) and \(\tau \) resulting in a list. The second step uses a threestep parallel reduction algorithm to sum all values of the list. The list is divided into sublists which are each summed independently in the first sweep, all subresults are then propagated in the second sweep and then the final values are computed in the third sweep. See further [17].
Runtimes in sec. (PAR2) and number of timeouts (15 min) of the three solvers PGSolver (pgsi), the solver by Fearnley [17] with sequential (parsiseq) and multicore variants, and Oink with sequential (psi) and multicore variants.
Model checking  Equiv checking  Random games  Total  

psi8  694  0  1078  0  315  0  2087  0 
psi  860  0  3262  0  480  0  4603  0 
psi1  1190  0  4090  0  487  0  5767  0 
parsiseq  1471  0  4199  0  1534  0  7204  0 
parsi8  2501  1  2908  0  56529  27  61938  28 
parsi1  4200  1  13867  6  71280  39  89347  46 
pgsi  167596  88  95407  49  58839  27  321842  164 
Empirical Evaluation. We compare the performance of Oink with the sequential and parallel solvers (1 or 8 threads) by Fearnley [17] and the “optstratimprov” solver in PGSolver. We disable optional preprocessing in all solvers. We only consider games without winnercontrolled winning cycles, which are 289 model checking, 182 equivalence checking and 279 random games, in total 750 games.
See Table 1. We observe that PGSolver is vastly outperformed by Oink and the sequential solver of Fearnley. PGSolver timed out for 160 games, whereas psi and parsiseq only timed out for 1 and 5 models, respectively. We observe similar parallel speedup for the parallel solvers, although Fearnley’s solver has more overhead from sequential to parallel with 1 thread. This might be due to the extra work to produce the Euler tour and to perform list ranking. The speedup we obtain with Oink is not very impressive, but the vast majority of the games are solved within 1 s already. Furthermore, psi and parsiseq are fairly close in performance. This is not a surprise, as their implementations are similar; the main difference is that Fearnley uses a forward search and we use a backward search. Hence, Oink is faster, but not by a large margin. Finally, we remark that Fearnley reports excellent results for list ranking on GPUs, whereas our algorithm is designed for a multicore architecture.
5 Progress Measures
Progress measures is a technique that assigns to each vertex a monotonically increasing measure. The measure of each vertex is lifted based on the measures of its successors. By lifting vertices, players Even and Odd essentially play the game backwards. The measure represents a statistic of the most optimal play so far from the vertex, without storing the plays explicitly.
While progress measures have been used elsewhere, they were introduced for parity games by Jurdziński [27]. Several improvements to the original algorithm are due to Verver [41] and Gazda and Willemse [22]. A number of parallel implementations have been proposed for the Playstation 3 [6], for multicore architectures [25, 37] and for GPUs [8, 24]. Furthermore, Chatterjee et al. proposed an implementation using BDDs [10]. Different types of progress measures were introduced after the recent breakthrough of a quasipolynomial time algorithm due to Calude et al. [9], which resulted in the progress measures algorithms by Jurdziński et al. [28] and by Fearnley et al. [18]. This section studies small progress measures [27] and quasipolynomial progress measures [18].
5.1 Small Progress Measures
The original small progress measures algorithm is due to Jurdziński [27]. We rely on the operational interpretation by Gazda and Willemse [22] and propose the capandcarryover mechanism to further understand the algorithm.
Progress measures record how favorable the game is for one of the players. W.l.o.g. we assume even progress measures. Given the highest priority d, define \(\mathbb {M}^\diamond \subseteq \mathbb {N}^d\cup \{\top \}\) to be the largest set containing \(\top \) (\(\top \notin \mathbb {N}^d\)) and only those dtuples with 0 (denoted as \(\_\)) on odd positions. An even progress measure \(m\in \mathbb {N}^d\) essentially records for a vertex v how often each even priority p is encountered along the most optimal play (starting at v) so far, until a higher priority is encountered, i.e., until p no longer dominates. Such a prefix of the play is called a pdominated stretch. Suppose that the sequence of priorities for a given play \(\pi \) is 0 0102120232142656201, then \(m=\{\, 2 \_ 3 \_ 1 \_ 2 \,\}\), since the play starts with a 0dominated stretch containing two 0s, with a 2dominated stretch containing three 2s, with a 4dominated stretch containing one 4, and with a 6dominated stretch containing two 6s. Furthermore, the special measure \(\top \) represents that the vertex can be won by player Even.
If we iteratively lift vertices from \(\rho =V\mapsto 0\) using \(\mathrm {Lift}\), eventually some vertex may have a measure m such that m(p) for some p is higher than the number of vertices with priority p, i.e., \(m(p) > \leftV_p \right\). In this case, we know that m represents a play that visits at least one vertex with priority p twice and thus contains a cycle dominated by p. Furthermore, player Odd cannot escape from this cycle unless by playing to a higher losing priority. This follows from the fact that if player Odd could escape from the cycle, then it would not lift to this measure. The option to play to the higher losing priority is not considered because a measure to a higher priority is \(\sqsupset \) a measure that records a cycle.
We need a mechanism to let player Odd play to the next higher priority if it is forced into a cycle. However, we cannot let just any vertex play to a higher priority when its measure records a cycle, since some other vertex may escape to a lower higher priority. Therefore we need a mechanism that finds the lowest escape for player Odd. Small progress measures achieves this using a capandcarryover mechanism. \(\mathbb {M}^\diamond \) is restricted such that values for each even priority p may not be higher than \(\leftV_p \right\). When this cap is reached, \(\text {Prog}\) will naturally find a next higher m by increasing the value of higher priorities and eventually reach \(\top \). For example, if we have two vertices of priority 2 and two vertices of priority 4 in a game and there is a selfloop of priority 2, measures increase as follows: \(\{ 0 \_ 2 \_ 0 \}\), \(\{ 0 \_ 0 \_ 1 \}\), \(\{ 0 \_ 1 \_ 1 \}\), \(\{ 0 \_ 2 \_ 1 \}\), \(\{ 0 \_ 0 \_ 2 \}\), \(\{ 0 \_ 1 \_ 2 \}\), \(\{ 0 \_ 2 \_ 2 \}\), \(\top \).
Thus all vertices involved in a cycle will find their measures slowly rising until the measure of some vertex controlled by Odd becomes equal to the measure when playing to a vertex that is not rising. This is the lowest escape. If no such escape is found, then the measures rise until \(\top \) and these vertices are won by player Even. The slowly increasing measures no longer follow the operational interpretation described above, but can be understood as player Odd looking for the lowest escape.
We refer to [27] for the proof that the fixed point of applying the above lifting operation solves the parity game, such that vertices with measure \(\top \) are won by player Even and all other vertices are won by player Odd with a strategy that chooses the successor for which \(\text {Prog}(\rho , v, w)\) is the lowest.
We implement three known improvements. Improvements 2 and 3 are also implemented by PGSolver [19].
 1.
When a vertex with some even priority p is raised to \(\top \), the cap of p may be lowered. The reason is that if a play records priority p \(\leftV_p \right\) times, it either contains a vertex now won by player Even or a cycle of priority p [41].
 2.
Small progress measures only computes the strategy for player Odd according to measures for player Even. We compute both even and odd measures simultaneously to compute the strategy for both players.
 3.
In addition, we occasionally halt the lifting procedure to perform an attractor computation for player Even to the set of evenliftable vertices. Any vertices not in this set are won by player Odd. We can immediately lift these vertices to \(\top \) in the odd measures. We perform this analysis also for oddliftable measures to potentially lift vertices to \(\top \) in the even measures.
5.2 Quasipolynomial Progress Measures
Runtimes in sec. (PAR2) and number of timeouts (15 min) of PGSolver (pgspm), pbespgsolve (pbesspm) and the implementations spm and qpt in Oink.
Model checking  Equiv checking  Random games  Total  

spm  3637  1  7035  0  168271  93  178944  94 
qpt  122549  64  65310  31  66303  35  254162  130 
pbesspm  38397  20  52422  27  183742  101  274561  148 
pgspm  88800  45  59885  30  320666  171  469351  246 
5.3 Empirical Evaluation
We compare our implementation of small progress measures and quasipolynomial progress measures to the small progress measures implementation of pbespgsolve that comes with the mCRL2 model checker [11, 41] and the implementation of small progress measures in PGSolver [19]. Unfortunately, the solver used in [18] contains proprietary source code and cannot be compiled and compared. For this comparison, we disabled optional preprocessing, i.e., removing selfloops, winnercontrolled winning cycles and solving singleparity games.
See Table 2. Although Fearnley et al. [18] say that the QPT solver is mainly interesting for the theoretical result rather than practical performance, we observe that qpt outperforms the other solvers for random games. Oink is faster than PGSolver, especially for model checking and equivalence checking.
6 Zielonka’s Recursive Algorithm
The algorithm by Zielonka [43] is a recursive solver that despite its relatively bad theoretical complexity is known to outperform other algorithms in practice [19]. Furthermore, tight bounds are known for various classes of games [21].
Zielonka’s recursive algorithm is based on attractor computation. At each step, given current subgame Open image in new window , the algorithm removes the attractor Open image in new window , i.e., all vertices attracted to the current highest vertices of priority Open image in new window for player \(\alpha =p \bmod 2\), and recursively computes the winning regions Open image in new window of the remaining subgame Open image in new window . If the opponent \({\overline{\alpha }}\) can attract vertices in A to \(W_{\overline{\alpha }}\), then \({\overline{\alpha }}\) wins Open image in new window and the solution for the remainder Open image in new window is computed recursively. Otherwise, \(\alpha \) wins A and no further recursion is necessary. The strategies for both players are trivially obtained during attractor computation and by assigning to winning pvertices in A any strategy to vertices in \(W_\alpha \cup A\).
Zielonka’s original algorithm has been extended and improved over the years. In his thesis, Verver [41] improves the partitioning of the game after computing A by extending A with the attractors of the next highest vertices if they are of the same parity. The original algorithm always recomputes the solution of Open image in new window if \(W_{\overline{\alpha }}\) is nonempty, even if no vertices are attracted to \(W_{\overline{\alpha }}\). Liu et al. propose that this is not necessary [34]. See Algorithm 3 for the recursive algorithm with these modifications. Other extensions that we do not consider here are the subexponential algorithm [29] and the big steps algorithm [39] that have been reported to perform slower than ordinary Zielonka [19]. Also, variations using BDDs have been proposed [2, 30].
The implementation in Oink is based upon the ideas described above. Furthermore, we improve the implementation using the following techniques.

Instead of creating copies of the “removed” array [40] for each recursive step, we use a single “region” array that stores for each vertex that it is attracted by the rth call to attr. This value is initially \(\bot \) for all vertices and is reset to \(\bot \) for vertices in Open image in new window (line 10). We record the initial r at each depth and thus derive that all vertices with a value \(\ge r\) or \(\bot \) are part of the subgame.

As a preprocessing step, we order all vertices by priority. We can then quickly obtain the highest vertex of each subgame.

We eliminate the recursion using a stack.

We implement an alternative lockfree attractor, relying on the workstealing library Lace [12] that provides finegrained load balancing.
Runtimes in sec. (PAR2) and number of timeouts (15 min) of the four solvers PGSolver (pgzlk), SPGSolver (spg), pbespgsolve (pbeszlk) and Oink (sequential zlk, multicore zlk1 and zlk8, unoptimized uzlk).
Model checking  Equiv checking  Random games  Total  

zlk8  94  0  415  0  11  0  521  0 
zlk  88  0  472  0  6  0  566  0 
zlk1  97  0  512  0  7  0  616  0 
uzlk  89  0  472  0  69  0  630  0 
pbeszlk  64  0  513  0  338  0  915  0 
spgseq  58  0  198  0  694  0  950  0 
spgmc  389  0  1451  0  72608  37  74447  37 
pgzlk  65905  33  68013  36  41629  14  175547  83 
Empirical Evaluation. We compare our implementation of Zielonka’s recursive algorithm with and without the optimizations of Algorithm 3 to PGSolver, to Verver’s implementation pbespgsolve [11, 41] and to SPGSolver [1, 40]. Unfortunately, the Java version of SPGSolver (all three variations) suffers from severe performance degradation for unknown reasons. They also provide a C++ implementation in their online repository, which we used instead. The multicore version of the SPGSolver tool relies on async tasks provided by C++11. Similar to the previous sections, we disable the optional preprocessors that solve single parity games, remove selfloops and solve winnercontrolled winning cycles.
See Table 3. The results show that the implementation in Oink outperforms PGSolver by several orders of magnitude on all benchmark types. PGSolver timed out for 83 of all 949 games. The solvers spgseq and pbeszlk are faster than Oink on the model checking and equivalence checking games, but are significantly outperformed on random games. We also observe severe performance degradation for spgmc on random games. It appears that our parallel implementation of Zielonka’s algorithm also does not scale well. Finally, there seems to be no significant difference between the optimized and unoptimized versions of Zielonka’s algorithm, except for random games.
7 Priority Promotion
In recent work, a new family of algorithms has been proposed based on priority promotion [5]. Priority promotion starts with a similar decomposition of the game as Zielonka’s recursive algorithm. Priority promotion is based on the insight that a recursive decomposition based on attractor computation leads to regions with a specific property related to the highest priority in the region, called its measure p. This property is that all plays that stay in the region are won by the player who wins the highest priority p, denoted by player \(\alpha \). The other player \({\overline{\alpha }}\) has three options. They either lose the game by staying in the region, or they can leave the region by playing to an \(\alpha \)region of higher measure, or they can leave the region to a lower region of either player via a vertex with priority p. The goal of \(\alpha \) is to find “closed” \(\alpha \)regions, where \({\overline{\alpha }}\) cannot escape to lower regions. The result is a region where player \({\overline{\alpha }}\) either loses, or leaves the region to a higher \(\alpha \)region which may or may not be closed. The measure of the closed \(\alpha \)region is then “promoted” to the measure of the lowest higher region to which \({\overline{\alpha }}\) can escape and the attractorbased decomposition is recomputed for all lower regions. The promoted region may now attract from regions with a measure between its original measure and its promoted measure, thus requiring recomputing the decomposition. When player \({\overline{\alpha }}\) cannot escape from an \(\alpha \)region to a higher \(\alpha \)region, player \(\alpha \) is the winner of all vertices in the region.
Runtimes in sec. (PAR2) and number of timeouts (15 min) of the five priority promotion solvers in Oink.
Model checking  Equiv checking  Random games  Total  

ppp  81  0  382  0  12  0  475  0 
pp  82  0  382  0  12  0  476  0 
rr  81  0  385  0  12  0  477  0 
dp  84  0  389  0  15  0  488  0 
rrdp  83  0  394  0  14  0  491  0 
Empirical Evaluation. We compare our implementation of five variations of priority promotion in Oink. As we do not compare with other solvers, we enable the optional preprocessors that solve single parity games, remove selfloops and solve winnercontrolled winning cycles.
Runtimes in sec. (PAR2) and number of timeouts (15 min) of the sequential implementations of the five solvers in Oink described in this paper.
Model checking  Equiv checking  Random games  Total  

pp  82  0  382  0  12  0  476  0 
zlk  78  0  393  0  10  0  481  0 
psi  231  0  2440  0  689  0  3359  0 
spm  1007  0  3079  0  156885  87  160971  87 
qpt  59559  31  60728  31  62104  33  182391  95 
8 Conclusions
See Table 5 for a comparison of the five main sequential algorithms in Oink, including the preprocessing that removes winnercontrolled winning cycles, selfloops and solves single parity games. The results show that the zlk and the pp solvers have similar performance and outperform the other solvers. See also Fig. 1 for a cactus plot of these five solvers.
Priority promotion is a powerful and attractive idea, as promoting closed \(\alpha \)regions is similar to capandcarryover in small progress measures. Attractor computation finds such regions directly whereas value iteration algorithms may require many iterations. We confirm the observations in [5] that the algorithm has a good performance but it is not faster than Zielonka’s algorithm.
In this work, we studied modern parity game algorithms using a new tool named Oink. Oink is publicly available via https://www.github.com/trolando/oink. We implemented a number of modern algorithms and provided a comprehensive description of these algorithms, introducing capandcarryover to understand small progress measures. We proposed improvements to strategy improvement and to Zielonka’s algorithm. We presented an empirical evaluation of Oink, comparing its performance with stateoftheart solvers, especially the popular PGSolver tool. The results demonstrate that Oink is competitive with other implementations and in fact outperforms PGSolver for all algorithms, especially Zielonka’s recursive algorithm. This result is particularly interesting considering that many publications compare the performance of novel ideas to Zielonka’s algorithm in PGSolver.
Notes
Acknowledgements
We thank Tim Willemse and John Fearnley for their helpful comments and Jaco van de Pol for the use of their computer cluster.
References
 1.Arcucci, R., Marotta, U., Murano, A., Sorrentino, L.: Parallel parity games: a multicore attractor for the Zielonka recursive algorithm. In: ICCS, Procedia Computer Science, vol. 108, pp. 525–534. Elsevier (2017)CrossRefGoogle Scholar
 2.Bakera, M., Edelkamp, S., Kissmann, P., Renner, C.D.: Solving \(\mu \)calculus parity games by symbolic planning. In: Peled, D.A., Wooldridge, M.J. (eds.) MoChArt 2008. LNCS (LNAI), vol. 5348, pp. 15–33. Springer, Heidelberg (2009). https://doi.org/10.1007/9783642004315_2CrossRefGoogle Scholar
 3.Benerecetti, M., Dell’Erba, D., Mogavero, F.: A delayed promotion policy for parity games. In: GandALF 2016. EPTCS, vol. 226, pp. 30–45 (2016)MathSciNetCrossRefGoogle Scholar
 4.Benerecetti, M., Dell’Erba, D., Mogavero, F.: Improving priority promotion for parity games. In: Bloem, R., Arbel, E. (eds.) HVC 2016. LNCS, vol. 10028, pp. 117–133. Springer, Cham (2016). https://doi.org/10.1007/9783319490526_8CrossRefGoogle Scholar
 5.Benerecetti, M., Dell’Erba, D., Mogavero, F.: Solving parity games via priority promotion. In: Chaudhuri, S., Farzan, A. (eds.) CAV 2016. LNCS, vol. 9780, pp. 270–290. Springer, Cham (2016). https://doi.org/10.1007/9783319415406_15CrossRefGoogle Scholar
 6.van der Berg, F.: Solving parity games on the playstation 3. In: Twente Student Conference (2010)Google Scholar
 7.Björklund, H., Vorobyov, S.G.: A combinatorial strongly subexponential strategy improvement algorithm for mean payoff games. Discret. Appl. Math. 155(2), 210–229 (2007)MathSciNetCrossRefGoogle Scholar
 8.Bootsma, P.: Speeding up the small progress measures algorithm for parity games using the GPU. Master’s thesis, Eindhoven University of Technology (2013)Google Scholar
 9.Calude, C.S., Jain, S., Khoussainov, B., Li, W., Stephan, F.: Deciding parity games in quasipolynomial time. In: STOC, pp. 252–263. ACM (2017)Google Scholar
 10.Chatterjee, K., Dvorák, W., Henzinger, M., Loitzenbauer, V.: Improved setbased symbolic algorithms for parity games. In: CSL, LIPIcs, vol. 82, pp. 18:1–18:21. Schloss Dagstuhl  LeibnizZentrum fuer Informatik (2017)Google Scholar
 11.Cranen, S., Groote, J.F., Keiren, J.J.A., Stappers, F.P.M., de Vink, E.P., Wesselink, W., Willemse, T.A.C.: An overview of the mCRL2 toolset and its recent advances. In: Piterman, N., Smolka, S.A. (eds.) TACAS 2013. LNCS, vol. 7795, pp. 199–213. Springer, Heidelberg (2013). https://doi.org/10.1007/9783642367427_15CrossRefzbMATHGoogle Scholar
 12.van Dijk, T., van de Pol, J.C.: Lace: nonblocking split deque for workstealing. In: Lopes, L., et al. (eds.) EuroPar 2014. LNCS, vol. 8806, pp. 206–217. Springer, Cham (2014). https://doi.org/10.1007/9783319143132_18CrossRefGoogle Scholar
 13.Emerson, E.A., Jutla, C.S.: Tree automata, \(\mu \)calculus and determinacy (extended abstract). In: FOCS, pp. 368–377. IEEE Computer Society (1991)Google Scholar
 14.Emerson, E.A., Jutla, C.S., Sistla, A.P.: On modelchecking for fragments of \(\mu \)calculus. In: Courcoubetis, C. (ed.) CAV 1993. LNCS, vol. 697, pp. 385–396. Springer, Heidelberg (1993). https://doi.org/10.1007/3540569227_32CrossRefGoogle Scholar
 15.Emerson, E.A., Jutla, C.S., Sistla, A.P.: On model checking for the \(\mu \)calculus and its fragments. Theor. Comput. Sci. 258(1–2), 491–522 (2001)MathSciNetCrossRefGoogle Scholar
 16.Fearnley, J.: Nonoblivious strategy improvement. In: Clarke, E.M., Voronkov, A. (eds.) LPAR 2010. LNCS (LNAI), vol. 6355, pp. 212–230. Springer, Heidelberg (2010). https://doi.org/10.1007/9783642175114_13CrossRefGoogle Scholar
 17.Fearnley, J.: Efficient parallel strategy improvement for parity games. In: Majumdar, R., Kunčak, V. (eds.) CAV 2017. LNCS, vol. 10427, pp. 137–154. Springer, Cham (2017). https://doi.org/10.1007/9783319633909_8CrossRefGoogle Scholar
 18.Fearnley, J., Jain, S., Schewe, S., Stephan, F., Wojtczak, D.: An ordered approach to solving parity games in quasi polynomial time and quasi linear space. In: SPIN, pp. 112–121. ACM (2017)Google Scholar
 19.Friedmann, O., Lange, M.: Solving parity games in practice. In: Liu, Z., Ravn, A.P. (eds.) ATVA 2009. LNCS, vol. 5799, pp. 182–196. Springer, Heidelberg (2009). https://doi.org/10.1007/9783642047619_15CrossRefGoogle Scholar
 20.Friedmann, O., Lange, M.: Local strategy improvement for parity game solving. In: GandALF. EPTCS, vol. 25, pp. 118–131 (2010)CrossRefGoogle Scholar
 21.Gazda, M., Willemse, T.A.C.: Zielonka’s recursive algorithm: dull, weak and solitaire games and tighter bounds. In: GandALF. EPTCS, vol. 119, pp. 7–20 (2013)MathSciNetCrossRefGoogle Scholar
 22.Gazda, M., Willemse, T.A.C.: Improvement in small progress measures. In: GandALF. EPTCS, vol. 193, pp. 158–171 (2015)MathSciNetCrossRefGoogle Scholar
 23.Grädel, E., Thomas, W., Wilke, T. (eds.): Automata Logics, and Infinite Games: A Guide to Current Research. LNCS, vol. 2500. Springer, Heidelberg (2002). https://doi.org/10.1007/3540363874CrossRefzbMATHGoogle Scholar
 24.Hoffmann, P., Luttenberger, M.: Solving parity games on the GPU. In: Van Hung, D., Ogawa, M. (eds.) ATVA 2013. LNCS, vol. 8172, pp. 455–459. Springer, Cham (2013). https://doi.org/10.1007/9783319024448_34CrossRefGoogle Scholar
 25.Huth, M., Kuo, J.H.P., Piterman, N.: Concurrent small progress measures. In: Eder, K., Lourenço, J., Shehory, O. (eds.) HVC 2011. LNCS, vol. 7261, pp. 130–144. Springer, Heidelberg (2012). https://doi.org/10.1007/9783642341885_13CrossRefGoogle Scholar
 26.Jurdzinski, M.: Deciding the winner in parity games is in UP \(\cap \) coUP. Inf. Process. Lett. 68(3), 119–124 (1998)MathSciNetCrossRefGoogle Scholar
 27.Jurdziński, M.: Small progress measures for solving parity games. In: Reichel, H., Tison, S. (eds.) STACS 2000. LNCS, vol. 1770, pp. 290–301. Springer, Heidelberg (2000). https://doi.org/10.1007/3540465413_24CrossRefGoogle Scholar
 28.Jurdzinski, M., Lazic, R.: Succinct progress measures for solving parity games. In: LICS, pp. 1–9. IEEE Computer Society (2017)Google Scholar
 29.Jurdzinski, M., Paterson, M., Zwick, U.: A deterministic subexponential algorithm for solving parity games. SIAM J. Comput. 38(4), 1519–1532 (2008)MathSciNetCrossRefGoogle Scholar
 30.Kant, G., van de Pol, J.: Generating and solving symbolic parity games. In: GRAPHITE. EPTCS, vol. 159, pp. 2–14 (2014)MathSciNetCrossRefGoogle Scholar
 31.Keiren, J.J.A.: Benchmarks for parity games. In: Dastani, M., Sirjani, M. (eds.) FSEN 2015. LNCS, vol. 9392, pp. 127–142. Springer, Cham (2015). https://doi.org/10.1007/9783319246444_9CrossRefGoogle Scholar
 32.Kozen, D.: Results on the propositional mucalculus. Theor. Comput. Sci. 27, 333–354 (1983)CrossRefGoogle Scholar
 33.Kupferman, O., Vardi, M.Y.: Weak alternating automata and tree automata emptiness. In: STOC, pp. 224–233. ACM (1998)Google Scholar
 34.Liu, Y., Duan, Z., Tian, C.: An improved recursive algorithm for parity games. In: TASE, pp. 154–161. IEEE Computer Society (2014)Google Scholar
 35.Luttenberger, M.: Strategy iteration using nondeterministic strategies for solving parity games. CoRR abs/0806.2923 (2008)Google Scholar
 36.Meyer, P.J., Luttenberger, M.: Solving meanpayoff games on the GPU. In: Artho, C., Legay, A., Peled, D. (eds.) ATVA 2016. LNCS, vol. 9938, pp. 262–267. Springer, Cham (2016). https://doi.org/10.1007/9783319465203_17CrossRefGoogle Scholar
 37.van de Pol, J., Weber, M.: A multicore solver for parity games. Electr. Notes Theor. Comput. Sci. 220(2), 19–34 (2008)CrossRefGoogle Scholar
 38.Schewe, S.: An optimal strategy improvement algorithm for solving parity and payoff games. In: Kaminski, M., Martini, S. (eds.) CSL 2008. LNCS, vol. 5213, pp. 369–384. Springer, Heidelberg (2008). https://doi.org/10.1007/9783540875314_27CrossRefGoogle Scholar
 39.Schewe, S.: Solving parity games in big steps. J. Comput. Syst. Sci. 84, 243–262 (2017)MathSciNetCrossRefGoogle Scholar
 40.Di Stasio, A., Murano, A., Prignano, V., Sorrentino, L.: Solving parity games in scala. In: Lanese, I., Madelaine, E. (eds.) FACS 2014. LNCS, vol. 8997, pp. 145–161. Springer, Cham (2015). https://doi.org/10.1007/9783319153179_9CrossRefGoogle Scholar
 41.Verver, M.: Practical improvements to parity game solving. Master’s thesis, University of Twente (2013)Google Scholar
 42.Vöge, J., Jurdziński, M.: A discrete strategy improvement algorithm for solving parity games. In: Emerson, E.A., Sistla, A.P. (eds.) CAV 2000. LNCS, vol. 1855, pp. 202–215. Springer, Heidelberg (2000). https://doi.org/10.1007/10722167_18CrossRefGoogle Scholar
 43.Zielonka, W.: Infinite games on finitely coloured graphs with applications to automata on infinite trees. Theor. Comput. Sci. 200(1–2), 135–183 (1998)MathSciNetCrossRefGoogle Scholar
Copyright information
<SimplePara><Emphasis Type="Bold">Open Access</Emphasis> This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.</SimplePara> <SimplePara>The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.</SimplePara>