Open AntoniusW opened 6 years ago
I am slightly confused why it would need need a full system like clingo
and a grounder like gringo
would not suffice. Sorry...
However, under the assumption that actually a pure grounder would suffice: This could be a quick-win, since what you propose sounds like it would be fully compatible with the Grounder
interface.
Firstly, implement an "eager" component that just wraps an existing system like gringo
in a subclass of Grounder
.
Secondly, implement a subclass of Grounder
that takes two other grounders (one eager, one lazy): This hybrid should then run the eager grounder with some cutoff time/memory constraint. If it reaches the cutoff, it should fall back to the lazy grounder, otherwise the result from the eager grounder is returned.
class HybridGrounder implements Grounder {
public HybridGrounder(
Grounder eager,
Grounder lazy,
Duration timeCutoff,
long memoryCutoff
) {
...
}
@Override
... getNogoods(...) {
if (!triedEager) {
// Run this.eager with timeCutoff/memoryCutoff
} else {
// Delegate to this.lazy
}
}
...
}
Note that this way we can use either of these components separately, so we may experiment in the following modes without any code duplication:
This is a nice solution, unfortunately the reasons for Alpha being slower than Clingo on easy-to-ground instances lies mostly in the solving component. Due to the lazy-grounding, we have some restrictions (like not knowing all rules that could derive p(a)
and subsequently lacking the full Clark-completion) and those make the solving slow, together with other similar issues. In the ground-and-solve case there is simply more information available to the solver than in the lazy-grounding case. So this issue is actually targeted at getting a faster solver component in the short-term.
I doubt that some hybrid approach could be possible with the solver component (although it would be awesome).
The sketched hybrid approach looks like a future work with promising long-term gains, however, and also might be worth pursuing.
I see, so the wrapper needs to be one level higher, at what currently is the Alpha
class (which is not so flexible right now). An abstraction that encapsulates a whole ASP system (combine Grounder
and Solver
vs. "run clingo
") could make use of a similar delegation pattern.
The wrapper might be even outside Alpha
, which could avoid JVM startup time (and memory). At the cost of having further dependencies (on bash or something similar). Maybe this whole wrapper idea is better put in another repo.
Alpha is currently employing lazy-grounding for any given input program. For easy-to-ground ASP programs, however, lazy-grounding is not needed and thus the overhead of running it could be avoided.
The idea is to create a wrapper script that first starts a ground-and-solve ASP system like Clingo and checks after a few seconds whether it finished grounding. If it did not finish, the input program is likely hard to ground and running lazy-grounding will be advantageous, i.e., the ground-and-solve system is stopped and Alpha is started. If grounding did finish, then the ground-and-solve system likely computes answer sets faster than Alpha and we simply let it run and report its outputs.