2 research outputs found

    Predicting Memory Demands of BDD Operations using Maximum Graph Cuts (Extended Paper)

    Full text link
    The BDD package Adiar manipulates Binary Decision Diagrams (BDDs) in external memory. This enables handling big BDDs, but the performance suffers when dealing with moderate-sized BDDs. This is mostly due to initializing expensive external memory data structures, even if their contents can fit entirely inside internal memory. The contents of these auxiliary data structures always correspond to a graph cut in an input or output BDD. Specifically, these cuts respect the levels of the BDD. We formalise the shape of these cuts and prove sound upper bounds on their maximum size for each BDD operation. We have implemented these upper bounds within Adiar. With these bounds, it can predict whether a faster internal memory variant of the auxiliary data structures can be used. In practice, this improves Adiar's running time across the board. Specifically for the moderate-sized BDDs, this results in an average reduction of the computation time by 86.1% (median of 89.7%). In some cases, the difference is even 99.9\%. When checking equivalence of hardware circuits from the EPFL Benchmark Suite, for one of the instances the time was decreased by 52 hours.Comment: 25 pages, 11 Figures, 2 Tables. Extended version of paper published at ATVA 202

    SSoelvsten/adiar: v2.0.0-beta.5

    No full text
    New Features Functional Bridge: Fully generalised and committed to the use of functions to bridge between Adiar and the user's code (as was started in v2.0-beta.2). To this end, Adiar now provides the types predicate and generator to pass information into Adiar and consumer to pass information back out again. All functions of v1.x that used some file, e.g. bdd_restrict, zdd_onset, bdd_varprofile etc. all now provide one (or more) of these functions instead. Execution Policy: Each algorithm (when relevant) has been overloaded with an exec_policy as its first argument. This class provides a thread-safe way of passing options into an algorithm, e.g. whether the algorithm should use internal or external memory data structures. This replaces the use of the globally set enum values, e.g. memory_mode. bdd_top(), bdd_bot(), zdd_top(...), and zdd_bot(...): Provide a uniform interface for getting the top and the bot value of the lattice. This provides a more uniform and interchangeable interface between BDDs and ZDDs where you do not need to think about the reduction rules. Optimisations bdd_satmin and bdd_satmax Stores the intermediate result in an internal memory stack (since it can at most be 8 MiB in size) rather than writing it out to disk. This should improve their performance slightly. Breaking Changes The function overloads with an auxiliary file as an input, e.g. bdd_restrict, zdd_onset, bdd_varprofile, have been removed in favour of the new functional input instead. The enums memory_mode, access_mode, and quantify_mode have been removed in favour of using the new Execution Policy. Removed the functions bdd_counter and zdd_sized_set. They may be added anew, assuming someone sends in a feature request. Fixed inconsistency of naming scheme in predicates. For example, the function is_true(const bdd &) has been renamed to bdd_istrue(const bdd&) to be consistent with the rest of the API. Removed the map_pair class introduced in v2.0-beta.2 as it has become redundant with the simpler function interface. Contributors Steffan Sølvsten ( @SSoelvsten
    corecore