Efficient implementations of Alignment-based algorithms Efficient storage! Efficient CPU use! Implementation effort? Efficient implementations of Alignment-based algorithms B.F. van Dongen

Introduction: Alignments Alignments are used for conformance checking Alignments are computed over a trace and a model: A trace is a (partial) order of activities A model is a labeled Petri net or a labeled Process Tree, labeled with activities An alignment explains exactly where deviations occur: A synchronous move mean that an activity is in the log and a corresponding transition was enabled in the model A log move means that no corresponding activity is found in the model A model move means that no corresponding activity appeared in the log

Introduction: Computing Alignments To compute alignments, an A-star algorithm is used A-star is an efficient algorithm for finding the shortest path in a graph: Initialize PriorityQueue q While (head(q) is not target t) VisitedNode n = head(q) For each edge in the graph from node(n) to m If m was considered before, or is in the queue with lower cost, continue If m is in the queue with higher cost, update and reposition it If m is new, compute an estimate for the remaining distance to t V = new VisitedNode(m) set n a predecessor for v add v to the priority queue Return head(q)

Important realizations This allows for caching of the estimate The remaining distance from node m to the target node t should be independent of the path from the initial node to m The estimate for the remaining distance has to be an underestimate, preferably a very good underestimate Tradeoff between CPU time and quality of the estimate can be made

Essential elements Node Necessary to store efficiently Node combination of a marking, parikh vector and estimate Visited Node The node, the predecessor and the distance Edge move on model move on log move synchronously Considered nodes lookup node visits add node visits Priority queue insert node visits update node visits inspect/remove head Estimation function tradeoff between CPU and quality Necessary to store efficiently Necessary to compute fast Necessary to store efficiently and have fast operations Necessary to store efficiently and have fast operations Necessary to cache efficiently and compute fast

Java: pitfalls Java collections framework: Easy to use, nicely typed code, but: Very generic and often too generic Hopelessly inefficient w.r.t. memory PriorityQueue<T> : Add, Poll: O(log(n)) Remove, Contains: O(n) Peek: O(1) Map<K,V> is unsuitable for multisets (marking, parikh vector) as each value is an Integer, requiring about 384 bits instead of just 32

Necessary to store efficiently A Closer Look: Nodes A node is a combination of a multiset of places, a multiset of activities and an estimate Assume a total order on the places and a total order on the activities Assume at most 256 tokens in a place, and at most 256 occurrences of the same activity in one trace Assume the estimate to be an integer (4 bytes) A Node becomes an array of bytes: p1 p2 p3 p4 p5 p6 a b c Estimate 1 3 21 5 2 4

A Closer Look: Lists of nodes Necessary to store efficiently A Closer Look: Lists of nodes List<byte[]> should not be used here! A list of nodes is an array of bytes, where the first byte of a node n is stored at index n*13 (in our example) Add: O(1) Remove: O(n) Lookup: O(n) Update: O(n) p1 p2 p3 p4 p5 p6 a b c Estimate 1 3 21 5 2 4 11 -2 10 9

A Closer Look: Hashsets of nodes Necessary to store efficiently A Closer Look: Hashsets of nodes A hashset of nodes requires an array of bytes for the nodes, a strong hash operation and an equality function In the storage, we add a hashmap, from node to nodeID Add: O(1+k/n) Remove: Lookup: O(≈1) p1 p2 p3 p4 p5 p6 a b c Estimate 1 3 21 5 2 4 11 -2 10 9 13 39 26

Implementations: Collections vs. Own CPU Efficient Memory Efficient The Node objects are stored in a List<Node> The index is stored in a TObjectIntMap<NodeID> Uses much more memory The Node objects are stored in a byte array using compressed storage Requires compressor and a decompressor

Memory use storing 224 objects of 28 bytes (448 MB) CPU Efficient Memory Efficient Wasted space: 64 MB Free space: 2 MB (74,898 objects)

Compressing byte arrays Necessary to store efficiently Compressing byte arrays Markings and parikh vectors consist mainly of 0’s, 1’s and 2’s We represent 0,1, and 2 by two bits and >2 by 2 bits and a byte for the actual value Compression-factor: 1.75, but compression takes time! p1 p2 p3 p4 a b c 1 2 21 4 byte 1 byte 2 byte 3 byte 4 00 01 10 11 00 01 01 01 01 10 11 00 00 00 01 00 (0,1,2,3) 21 (1,2,4,0) 4

A Closer Look: VisitedNode Necessary to store efficiently A Closer Look: VisitedNode A node visit is simply an object containing: A pointer to the corresponding node (the NodeID) An object-pointer to the predecessor A bitmask for the executed events in the trace (necessary to allow for partially ordered traces) and optionally (The moves made to reach the state) (The estimate of the remaining cost)

Necessary to compute fast A Closer Look: Edges An edge is essentially: the execution of a transition in a model moving forward by one activity in the trace both simultaneously For Petri nets: consider each transition given the marking and check all connected places for a transition O(T*P) For Process trees: consider all nodes and check if they are enabled in the marking O(N)

A Closer Look: Considered Nodes Necessary to store efficiently and have fast operations A Closer Look: Considered Nodes HashSet<Node> : Add: O(1) Contains: O(1+k/n) However, the java collections hashset would require pointers to the actual nodes, which do not exist... Node visits are identified by the ID of the node, i.e. we use a TLongHashSet from the GNU Trove libraries Storing longs instead of pointers requires the same space, but Node visits can be removed from memory

A Closer Look: PriorityQueue Necessary to store efficiently and have fast operations A Closer Look: PriorityQueue PriorityQueue<T> : Add, Poll: O(log(n)) Remove, Contains: O(n) Peek: O(1) Update: O(n+log(n)) In A-star the priority queue is constantly searched. The object searched for is uniquely identified by a long (the node ID) Elements of the queue need constant updating If a node visit is queued and the node is reached again with lower cost

A Closer Look: PriorityQueue Necessary to store efficiently and have fast operations A Closer Look: PriorityQueue Solution: - A balanced binary heap for the queue - A TLongIntMap mapping nodeID’s to locations in the heap FastLookupPriorityQueue : Add, Poll, Remove : O(log(n)+k/n) Contains: O(1) Peek: O(1) Update: O(log(n)) Two implementations: Breadth-first: second order sorting on least cost so far Depth-first second order sorting on most cost so far

Complexity w/ Java Collections O(log(n)) Initialize PriorityQueue q While (head(q) is not target t) VisitedNode n = head(q) For each edge in the graph from node(n) to m If m was considered before, continue If m is in the queue with lower cost, continue If m is in the queue with higher cost, update and reposition it If m is new, compute an estimate for the remaining distance to t V = new VisitedNode(m) set n a predecessor for v add v to the priority queue Return head(q) O(1) O(n) O(n+log(n)) Expensive? O(log(n))

Complexity w/ Own Collections O(log(n)+k/n) Initialize PriorityQueue q While (head(q) is not target t) VisitedNode n = head(q) For each edge in the graph from node(n) to m If m was considered before, continue If m is in the queue with lower cost, continue If m is in the queue with higher cost, update and reposition it If m is new, compute an estimate for the remaining distance to t V = new VisitedNode(m) set n a predecessor for v add v to the priority queue Return head(q) O(1) O(1) O(log(n)) Expensive? O(log(n)+k/n)

A Closer Look: Estimation Necessary to compute fast A Closer Look: Estimation Stupid estimation: 0 (fast!) Smarter estimation: size of parikh vector (fast!) Both for process trees and Petri nets, we can use an estimation function based on Linear Programming Form is the same: Minimize c.x Where A.x = r c and A are the same for all traces r depends on the current node

A Closer Look: Estimation Necessary to compute fast A Closer Look: Estimation If we store the vector x, we can derive one solution from the other, since x represents the various moves. if xi>=1 and we execute move i, then c.x–c.1i is optimal and the x–1i is a new optimal solution for the problem Minimize c.x Where A.x = r-A.1i Otherwise, if we execute move i, then c.x–c.1i is a lower bound for c.x So, we get the problem: Minimize c.x Where A.x = r c.x >= v

A Closer Look: Estimation Necessary to compute fast A Closer Look: Estimation Technically, the vector x is an integer vector, since you cannot do half a modelmove or half a synchronous move Hence, our LP (polynomial complexity) is an ILP (exponential complexity) Fortunately, the LP provides a lower bound on the ILP (and we need an underestimate!) For Petri nets: we use ILP as it’s more precise For Process Trees: we use LP since we need the speed

Implementations: Estimator versions Petri nets Process Trees Dijkstra (estimator 0) Naive (estimator parikh) ILP (estimator using ILP) Naive (estimator parikh) LP (estimator using LP) Hybrid ILP (estimator using ILP for at most 1 second before reverting to LP)

Some performance results 179 random process trees of 16.7 nodes on average 120 short traces over 6 activities

Conclusion Fast, memory efficient implementations can be essential Memory efficiency comes at a cost of code readability There’s negligible performance overhead for memory efficiency A-star efficiency required good estimation functions, but Good estimation functions can be expensive There’s always a tradeoff between CPU time, memory consumption and implementation effort

Strong Hash functions There are many ways to hash an array of bytes Collision test on 33,554,432 semi-random arrays. Expecting 130,731 collisions. Algorithm Time Collisions JAVA31 12.08 130,721 Bernstein 12.23 130,428 MurMur3 12.46 131,519 Jenkings 23.06 131,031 FNV1 14.10 130,695 FNV1a 14.01 130,606 OAT 16.97 130,546 Incremental 9.41 238,423