Comments (6)
Great observations.
- add some support for incrmentalized computation, so that you could indicate 'I've added facts to this relation' and 'I've removed facts from this relation', causing some of the indices to be recomputed?
This is what is done now. Ascent conservatively assumes that all relations may have changed, and recomputes all indices for the program. Here, it seems that this recomputing of indices is very expensive for some reason. This is something that can potentially be addressed. Although I'd have to think about its ramifications for BYODS.
- prevent the user from calling .run() multiple times, by making run take ownership of the program instead of taking it by mutable reference.
This is also a possibility. But I prefer the other option.
from ascent.
@s-arash thanks.
But there isn't only a performance issue.
At least in my last example, where input facts are removed, the result isn't consistent after calling run at the second time.
from ascent.
I have yet to run into a case where calling run() multiple times does not cause a subsequent geometric increase in eval time, even when the row counts don't actually change.
My programs are large but not super complex, and I don't think I'm doing anything too off the beaten path (using enum instances for values).
My solution for now is to manage caches myself and break things down into multiple one-off ascent_run! calls.
from ascent.
At least in my last example, where input facts are removed, the result isn't consistent after calling run at the second time.
Right, I can't think of a good way to prevent removing facts from relations. Even replacing the Vec<T>
type for relations with an append-only vec type will not prevent removing facts.
I have yet to run into a case where calling run() multiple times does not cause a subsequent geometric increase in eval time.
Ascent wasn't really designed for incremental processing of data.
I can just disallow calling run()
multiple times. But I feel like it may prevent a few legitimate use cases.
I have purposefully not hidden the internals of Ascent's relations and indices so they can be tinkered with by those who know what they are doing.
from ascent.
@s-arash
I think if there is one way (calling once) that is the normal and designed for use of the API, and one that is more for power users who really know what they are doing, it may make sense to separate them, like:
fn run(self) -> ResultSet
(where ResultSet provides the contents of the relations after run, and the indices, but can't be used to run again)
and
/// Runs the program and allows it to be run later. Runs in general are not incremental, and may take longer time than rerunning from scratch, or may fail to account for facts manually removed from the input relation after the first run.
fn run_and_keep(&mut self)
Alternatively, there could be some switch attribute on the macro itself, which would generate the fields by default as private, with appropriate getters (handing out shared references), but would allow advanced users to request an 'exposed internals' ascent program.
from ascent.
I think mod/rerun will require add provenance (like add fact/remove fact) semantic.
for example in query
edge(1,2).
path(a, b) :- edge(a, b).
changing edge (like remove edge(1,2)) will cause datalog rule not holds logically (some path(1,2), can't be inferred).
with some semantic support like semi-ring should help with incremental computation.
from ascent.
Related Issues (20)
- Private type `…` in public interface (error E0446) HOT 3
- Compiling ascent at runtime HOT 2
- New release with parallel Ascent HOT 2
- ascent_macro: Upgrade syn to >= v2 HOT 1
- MISP computation HOT 8
- ascent_macro: Fix minimal versions (by upgrading syn to v1.0.109, itertools to v0.12) HOT 5
- Non-final lattice results visible to downstream rules HOT 6
- Ascent should omit trait bounds on the generated program's type declaration HOT 5
- Project's current formatting makes it hard to contribute non-trivial changes HOT 4
- Lattice constrains not enforced on input in ascent_run HOT 2
- Incorrect result? HOT 2
- Please add a license HOT 1
- Macro limitations HOT 1
- WASM compatibility: `std::time` HOT 3
- Unsoundness in `util::update` HOT 1
- Arash's current email address? HOT 1
- Composition Feature
- ascent = "0.2" broke? HOT 4
- Comparison to Crepe? HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ascent.