-
Notifications
You must be signed in to change notification settings - Fork 43
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
Performance of triomphe::Arc
is sometimes worse than std::sync::Arc
#74
Comments
No idea; this crate was written quite a while ago. |
If I take a look at the |
I was browsing |
This comment suggests Lines 546 to 549 in f78899c
|
I would be happy to get patches, I can't guarantee I'll be able to review and merge them in a timely manner but if they map closely to upstream code that would make it easier. Would also love help reviewing them |
triomphe::Arc
is sometime worse than std::sync::Arc
triomphe::Arc
is sometimes worse than std::sync::Arc
I concur, I am working on Typst (as a contributor not owner/creator) and specifically on performance, we don't use weak refs to I figured swapping out std arcs for triomphe would help but performance is around 30% worse using triomphe so there is something here, perhaps an optimization that exists in the std lib and not here? As someone said, they have (apparently) relaxed the ordering in the std lib, perhaps we could do the same in Triomphe? |
The two differences I can see are:
Are you benchmarking heavily contended accesses or mostly single threaded? |
@jmspiewak The |
Something to keep in mind: although orderings don't lead to different ASM on x86 in isolation, LLVM will still use them when optimising when functions are inlined, so weaker orderings can allow LLVM to reorder and generate better ASM. |
Hi,
@michaelsproul and I ran some benchmarks in rpds . Most results improved when switching from
std::sync::Arc
totriomphe::Arc
, but I was surprised that some benchmarks regressed significantly (> 30%). I'm wondering if there are optimizations onstd::sync::Arc
that were never ported totriomphe
and that could improvetriomphe
and all projects that use it.This is the PR with the benchmark results: orium/rpds#88
The text was updated successfully, but these errors were encountered: