-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[optimization] parallelize #6
Comments
Initial experiments adding rayon. ancestry benchmark, AMD Ryzen 9 3900X 12-Core Processor (24 logical cores), 50 entities
benchmark source#[bench]
fn ancestry_high_bench(b: &mut Bencher) {
let mut next_uniq = 0u32;
let parent = inc(&mut next_uniq);
let ancestor = inc(&mut next_uniq);
let nodes: Vec<u32> = (0usize..50).map(|_| inc(&mut next_uniq)).collect();
let facts: Vec<Claim<u32>> = nodes
.iter()
.zip(nodes.iter().cycle().skip(1))
.map(|(a, b)| [*a, parent, *b])
.collect();
let arule: [&[Claim<Entity<_, _>>]; 2] = [
&[
[Unbound("a"), Bound(ancestor), Unbound("b")],
[Unbound("b"), Bound(ancestor), Unbound("c")],
],
&[[Unbound("a"), Bound(ancestor), Unbound("c")]],
];
let rules = decl_rules(&[
[
&[[Unbound("a"), Bound(parent), Unbound("b")]],
&[[Unbound("a"), Bound(ancestor), Unbound("b")]],
],
[
&[
[Unbound("a"), Bound(ancestor), Unbound("b")],
[Unbound("b"), Bound(ancestor), Unbound("c")],
],
&[[Unbound("a"), Bound(ancestor), Unbound("c")]],
],
]);
let composite_claims = vec![
[nodes[0], ancestor, *nodes.last().unwrap()],
[*nodes.last().unwrap(), ancestor, nodes[0]],
[nodes[0], ancestor, nodes[0]],
[nodes[0], parent, nodes[1]], // (first node, parent, second node) is a premise
];
b.iter(|| {
prove::<&str, u32>(&facts, &composite_claims, &rules).unwrap();
})
} Looks like, the parallel implementation improves performance when rule count is high, otherwise it hiders performance. |
Better to work on #1 first. |
Better to work on #9 before working on this. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
During each single round of reasoning, the RDF store does not receive writes. Instead, new inferences are queued for addition. This structure should lend itself well to a multi threaded reasoner. Each rule can be processed by a separate thread. Once all rules are processed for a round, merge all resulting inferences together an insert them into the RDF store.
Maybe work can be split up more granularly than per-rule but perhaps not worth the complexity.
The text was updated successfully, but these errors were encountered: