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

Question - Do the native Mutex, RwLock used affect performance ? #60

Open
szagi3891 opened this issue Jul 31, 2022 · 4 comments
Open

Question - Do the native Mutex, RwLock used affect performance ? #60

szagi3891 opened this issue Jul 31, 2022 · 4 comments

Comments

@szagi3891
Copy link

I noticed that native mutexes were used for state synchronisation
use std::sync::{Arc, Weak, Mutex, RwLock }

Doesn't this affect performance ?
Wouldn't it be better to use a mutex from tokio ?

@Pauan
Copy link
Owner

Pauan commented Jul 31, 2022

You mean parking_lot? This crate is designed to be portable, it can work on any platform (including Wasm). There are various issues with parking_lot that make it not feasible right now. At least on Wasm, the stdlib Mutexes are much faster.

There have been substantial efforts in integrating parking_lot into the stdlib:

rust-lang/rust#56410
rust-lang/rust#93740

Most of the performance improvements seem to have already been merged, so I'm curious whether parking_lot is actually faster or not.

@dbsxdbsx
Copy link

dbsxdbsx commented Sep 25, 2022

You mean parking_lot? This crate is designed to be portable, it can work on any platform (including Wasm). There are various issues with parking_lot that make it not feasible right now. At least on Wasm, the stdlib Mutexes are much faster.

There have been substantial efforts in integrating parking_lot into the stdlib:

rust-lang/rust#56410 rust-lang/rust#93740

Most of the performance improvements seem to have already been merged, so I'm curious whether parking_lot is actually faster or not.

I don't know whether the std mutex is faster than parking_lot either. I came from here when I decided to use spin at first. And now I think the std mutex and parking_lot would be better for most synchronization cases.

But between std mutex and parking_lot, I think std mutex should be preferred at first unless you have an extremely time-efficiency sensitive case.

@SchrodingerZhu
Copy link

While I do remember parking_lot speeds up my toy nbody simulation a lot 5 years ago, on modern CPUs (I tested apple M1, Zen3+), I really see no performance gain from parking_lot (or even worse, parking_lot has a large negative performance impact).

@dbsxdbsx
Copy link

While I do remember parking_lot speeds up my toy nbody simulation a lot 5 years ago, on modern CPUs (I tested apple M1, Zen3+), I really see no performance gain from parking_lot (or even worse, parking_lot has a large negative performance impact).

Things may change a lot in the past 5 years. I do think that trying the built-in one is a good practice at first.

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

4 participants