Skip to content
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

Open
bddap opened this issue Nov 25, 2020 · 3 comments
Open

[optimization] parallelize #6

bddap opened this issue Nov 25, 2020 · 3 comments

Comments

@bddap
Copy link
Contributor

bddap commented Nov 25, 2020

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.

@bddap
Copy link
Contributor Author

bddap commented Jan 26, 2021

Initial experiments adding rayon.

ancestry benchmark, AMD Ryzen 9 3900X 12-Core Processor (24 logical cores), 50 entities

24 rules (22 of them duplicates) 2 rules
single threaded 294,074,410 ns/iter 20,142,490 ns/iter
rayon version 51,397,531 ns/iter 12,489,231 ns/iter
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.

@bddap
Copy link
Contributor Author

bddap commented Jan 26, 2021

Better to work on #1 first.

@bddap
Copy link
Contributor Author

bddap commented Apr 8, 2021

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
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant