“ ”: executable extensions of the bookshelf marius eriksen and igor markov university of...
DESCRIPTION
Making the Bookshelf More Dynamic Existing bookshelf: –A static collection of data and implementations –Manual addition of material –No automatic evaluations, reporting of results Those limitations are not fundamental –Artifacts of the current implementation Proposal for improvement: “Bookshelf.exe”TRANSCRIPT
“Bookshelf.exe”: Executable Extensions of the Bookshelf
Marius Eriksen and Igor MarkovUniversity of Michigan, EECS
Outline• Making the bookshelf more dynamic
– Implementations + data = algorithm evaluations– Potentially more than that…
• Related efforts– SatEx, PUNCH, NEOS, OmniFlow
• Proposed solution: ``Bookshelf.exe’’– Services offered:
• online execution, ASP, sharing of results, flow scripting,…– Interfaces
• Support for optimization-specific concepts• Power versus ease-of-use and modularity
– Architecture and implementation details
Making the Bookshelf More Dynamic
• Existing bookshelf:– A static collection of data and implementations– Manual addition of material– No automatic evaluations, reporting of results
• Those limitations are not fundamental– Artifacts of the current implementation
• Proposal for improvement: “Bookshelf.exe”
Related Efforts • SatEx http://www.lri.fr/~simon/satex/satex.php3
– Specialized in satisfiability problems• PUNCH http://punch.ece.purdue.edu
– Very broad selection of software• From StarOffice and gnulot to Capo and Feng Shui
– Local to Purdue Univ.• NEOS http://www-neos.mcs.anl.gov/neos
– Open-source, distributed architecture– Used primarily for linear and non-linear optimization
• OmniFlow: DAC 2001, Brglez and Lavana– http://www.cbl.ncsu.edu/OpenProjects/OmniFlow– Distributed Collaborative Design Framework for VLSI– GUI-based flow control, chaining of design tools
SatEx• Continual evaluation and ranking of submitted
implementations– Results produced and posted on the Web automatically– Intuitive interface
• Popular– 93,707 hits since March, 2000– 23 SAT provers, 32,610 executions
• Limited scalability– Runs on one workstation – 529 days, 17 hours, 53 minutes and 20 seconds of CPU
time– Specialized to one application
PUNCH• Very general execution framework
– Everything from domain-specific algorithm implementations to GUI-based office applications
– Custom-designed filesystem (restricts to Purdue hosts)– 241,458 executions in 5 years
• 8,152 on VLSI CAD related applications– 20+ publications
• Only maintainer can add executables• No support for evaluation and chaining/flows
– No stats for results of runs (cf. “top 20” on SatEx )– No MIME-like data types (even IE/netscape need them!)
• Difficult to use when multiple tools are involved
NEOS• Open-source, distributed framework• Wide use, a solid library of implementations• Adding new implementations requires maintainer
intervention (but less than on PUNCH)– Each new implementation must come with a host– Distributed maintenance
• Loose data typing– No type system for data and implementations
• Compare to MIME
NEOS (what can be improved)
• Independent eval. and verification of results– E.g., PUNCH offers a WL-eval. From the bookshelf
• Real-time on-line reporting of results + stats• Provisions for chaining multiple
implementations– Scripts to control the execution and evaluation flows
• Provisions for pairing exec’s with benchmarks– Goal: SatEx-like evaluation,
but for multiple data types
OmniFlow• Context: collaborative VLSI Design
– collaboration in terms of computational resources
– no provisions for sharing results on the Web• Distributed over multiple hosts• Provides GUI-based flow control
– supports chaining of design tools– several hard-coded conditions for flow control– no support for execution conditional on results– no scripting language; limited by GUI
• Cannot dynamically add hosts
Bookshelf.exe• Best of SatEx, PUNCH, NEOS and OmniFlow
– Reporting style similar to SatEx (+ alternatives)– The versatility of PUNCH– Scalability and distributed nature of NEOS (or better)– Flow control as in OmniFlow or better
• New features– MIME-like data types and optimization-specific concepts – Automatic submission of binaries and source code– Chaining of implementations; scripting for flow control– Support for use models with proprietary data or code
Bookshelf.exe (2)• Scalability
– Computation is distributed (unlike in SatEx)– Maintenance is automated (unlike in NEOS)
• Support for multiple use models– “adapts to users”– Multiple levels of expertise– Multiple levels of commitment – Sharing of public data– Hiding/protection of proprietary data– “Screen-saver” mode, similar to SETI@Home,
Entropia, etc
Bookshelf.exe (3)
• Provides basic algorithm evaluation infrastructure to research groups – Avoid large maintenance costs– Just as usable for larger groups
End-user Interface
• Web site– Using CGI/PHP for interactive content and
database interaction– Submission through the web site (email is ok)– Dynamic addition of computation hosts– Stores data locally or uploads on demand– Automatic Web-based reports and statistics
End-user Interface (2)• User accounts (including anonymous)
– Every user has private resource-limited “workspace” – Job submissions must be from accounts– Results of jobs stored on accounts– Anonymous jobs possible, but can use fewer resources
• users are encouraged to register
• Many policy questions (no roadblocks seen)– e.g., can different owners chain their jobs?
• Transparent error diagnostics– Greatly improves learning curve
End-user Interface (3)
• Result notification (similar to NEOS)– E-Mail– Web reports
• Script composer for making run flows without needing to know a scripting language– less flexibility, but better learning curve– GUI implemented as form that POSTs scripts
Script Composer• HTML Form interface – basic flow with
fundamental predicates and functions– All API functions
• E.g. “run algorithm ‘optimizer 2’ and store the results”– Several common Perl functions– Conditional statements
• E.g. “verify if quality is more than 60”– Iteration support
• E.g. “iterate until quality is 100 or the number of iterations is 100”, “run randomized solver 3 timers, report the best result”
– Start with one ‘step’ – add an arbitrary number of steps
Optimization-specific Concepts in Bookhelf.exe
• Type system (similar to MIME) for all types of submissions
• Rules for matching submissions of different types– E.g., match a placer with a LEF/DEF benchmark
• Types include– Algorithm implementations
• Deterministic and randomized optimizers, etc.
– Input data, results– Common benchmarks
Architecture Overview
Component Types
• Where relevant, components also have types
• Data– Data format
• E.g. Cadence LEF/DEF, DIMACS CNF
• Implementations– Architecture (solaris, linux, ‘source code’, etc.)– Class (optimizer, randomized solver, etc.)
Component Descriptors• Unique id, name and description for each component• Owner field• Component history
– E.g. usage of a certain implementation, piece of data or benchmark
• Component specific fields– Associated expert for implementation, incremental diff for
data• Component version• Component changelog
Data Controller• Backing store
– Permanent storage of all involved components• Backed by database and file system
– Data, results suited for database– Implementations suited for file system storage
• Components may be deferred to local storage– Proprietary, non-disclosed components on a host owned
by the proprietor of the component• All data stored with complimentary descriptor
Job Controller• Responsible for communicating with and
controlling all agents (and thus jobs and implementations)
• Initiates jobs• Delivers user instructions• Handles data retrieval and storage
– Interfaces with data controller• Keeps track of node load, etc. for proper
distribution
Host Job Controller• Resides on each node in the distributed network
– Basic token of presence of DS-OSS• Reports statistics to job controller
– Load, memory usage• Signals when ready to take jobs• Launches agents as necessary• Performs self upgrades
– New software revisions, bugfixes
The Agent
• Responsible for running job on node• Provides environment for script to run in
– API– Script sandbox/jail
• For security reasons– Provides common callbacks if not provided by
scripts• Data storage/retrieval
The Agent (2)
• Input/Output of data from script• Job notification and control
– Start, stop, termination• Maintains local demands
– Resource usage– Stop on local demand
Scripts
• In Perl• Interfaces directly with an algorithm, or
expert handling it• API support
– Full Perl library– Job control functionality– Data storage and retrieval
Scripts (2)
• Checks for conflicting input data types and algorithm input type– Generates appropriate, understandable errors
• A number of automatic tasks– Pass thru data storage (e.g. results of a single
run)– Can provide all steps automatically, leaving the
user to do exactly what he/she wants
The Expert
• Wrappers for proprietary implementation interfaces– Knows how to deal with a particular interface
• E.g. command line options, configuration files– Translates from well known parameters
(specified from the API) to proprietary interface
In Conclusion
• DSS-OS provides features that are missing in current systems– Existing systems are limited by their
architecture and thus cannot provide these needed features.
• Provides an infrastructure that is scalable– Computationally scalable– Scalable to proprietary vendors
In Conclusion (2)
• Scripting support allows for flexible execution flows– Conditional flows, iterative flows
• Provides an established infrastructure for smaller research groups– Enjoying advantages that only large
proprietary, high-maintenance systems previously could provide.