skl
crossbeam
| skl | crossbeam | |
|---|---|---|
| 1 | 43 | |
| 57 | 7,800 | |
| - | 1.8% | |
| 8.6 | 7.9 | |
| 2 months ago | 17 days ago | |
| Rust | Rust | |
| Apache License 2.0 | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
skl
crossbeam
-
Towards fearless SIMD, 7 years later
Sure! However, the work-stealing queue in rayon [1] uses three atomic operations instead of the two atomic operations for a mutex for a global lock. The difference, however, is the three atomic operations for the thread-local queue should be uncontended, whereas a global lock on a global work queue would experience contention from every thread trying to access it for jobs.
Between the choices of "single work sharing queue with a big mutex on it that all threads access for work" vs "per-thread work-stealing queue that's uncontended for the cost of one extra atomic," in what situations would the work-sharing queue with the global mutex outperform? Perhaps if there's a small number of jobs, and there's not enough time for the work-stealing algorithm to distribute jobs to the worker threads before the work-sharing algorithm has already finished.
[1]: https://github.com/crossbeam-rs/crossbeam/blob/423e46fe20471...
-
Hyperbridge: Fast multi-producer, multi-consumer unbounded channel in Rust
Crossbeam isn't async[0]. It can multiplex with itself (via the `select!` macro), but not with anything else.
[0]: https://github.com/crossbeam-rs/crossbeam/issues/896
-
Where can I read about how to write a safe API for unsafe code?
Shooting from the hip, crossbeam might be a good candidate for understanding the thread safety aspects of Rust. I kind of feel like this is probably "too big" of a project if you're just learning, but I can't think of something smaller off the top of my head that would be suitable.
-
multi-producer multi-consumer channels for message passing python library
I am familiar with crossbeam channels, but now I need to work with python, and I was looking for a similar library.
-
I needed to write a simple multi-threaded message processing queue in C++ today. Makes me really appreciate how easy this is to do in Rust.
In the C++ example you create a naive mpsc queue using a std queue and a mutex, while in the rust example you use `std::sync::mpsc` which is now implemented internally using https://github.com/crossbeam-rs/crossbeam .
-
crossbeam VS scalable-concurrent-containers - a user suggested alternative
2 projects | 13 Apr 2023
-
Ergonomic Communication with a tokio::task::spawn
There are more in the ecosystem like in https://crates.io/crates/crossbeam
-
Rust Tips and Tricks #PartOne
The crossbeam crate offers a powerful alternative to standard channels with support for the Select operation, timeouts, and more.
-
How would one go about updating in-memory storage lock free, while other threads read?
From this project: https://github.com/crossbeam-rs/crossbeam
- This implementation is actually unsafe since we don't check if the index is in-bounds. But this is fine since this is only used internally.
What are some alternatives?
amqprs - Async & Lock-free RabbitMQ Rust Client, Easy-to-use API
rayon - Rayon: A data parallelism library for Rust
griddle - A HashMap variant that spreads resize load across inserts
tokio - A runtime for writing reliable asynchronous applications with Rust. Provides I/O, networking, scheduling, timers, ...
sled - the champagne of beta embedded databases
libfringe - a Rust library implementing safe, lightweight context switches, without relying on kernel services