Comments (10)
Not physics related, but the bevy project indicated in their most recent blog post that they measured some considerable performance wins by moving from rayon to a custom async task system.
It's probably very important to note that the blog post talks about I/O and networking, which are areas where you're likely to see major improvements from async. I'm personally pretty skeptical that a purely-cpu bound task like physics will benefit at all from async - as far as I can tell, the whole physics step is a blocking operation, right?
That being said, I'd be glad to be proven wrong.
from rapier.
To be clear, I do see that the task pool uses async but I'm interpreting that as an implementation detail of the thread pool, rather than making the tasks themselves async (if the distinction makes sense).
That would explain it in Bevy's case, so maybe we just use Bevy's thread pool for Rapier then.
Agreed. That's probably worth looking into before trying to make all of Rapier async just to see. It does make me want to do a general comparison between the two thread pool implementations - if Bevy's is so much better than Rayon's, what's stopping Rayon from using it?
Hopefully I'll find time to investigate.
from rapier.
Currently parallelism is done with Rayon. Can this be mixed with async easily?
One difficulty with supporting async is that I guess this would require modifying most code to use the async/await syntax. It would be great if we could think of an easy, quick way to determine whether or not using async will be beneficial performance-wise.
from rapier.
Currently parallelism is done with Rayon. Can this be mixed with async easily?
I'm not sure how easily this can be accomplished. I'm going to finally pull down rapier
and take a look at the overall architecture and get back to you.
To your point about performance, to see if there was any benefit, it's pretty much going to be an all-or-nothing, but I'm willing to take a stab at it to at least figure out if it's worth perusing further in the future.
Not physics related, but the bevy project indicated in their most recent blog post that they measured some considerable performance wins by moving from rayon
to a custom async task system.
from rapier.
FWIW: I personally would rather keep the rapier api synchronous, as it would force users to run their physics asynchronously. If the user api would be unaffected and there are performance gains then I would consider internal async to be a win.
from rapier.
I think that the performance that would be gained by Rapier when switching to async would be related to replacing Rayon, which uses thread pools for work and therefore could have a performance disadvantage due to thread context switching. Like @devnought mentioned, async brought some great gains in Bevy, which is by no means network or IO heavy ( after the game is done loading assets anyway ).
Still, we really would have to try it to find out I think.
from rapier.
Still, we really would have to try it to find out I think.
Absolutely! I'm definitely not trying to say this shouldn't be investigated. And I'm not trying to sound too argumentative about this - I'm trying to learn why this might be an improvement, not shoot it down.
I think that the performance that would be gained by Rapier when switching to async would be related to replacing Rayon, which uses thread pools for work and therefore could have a performance disadvantage due to thread context switching.
I just don't see the point in Rapier where .await
would be invoked. Without that, won't it still delegate to a thread pool (what Rayon does) or run it serially (which would be a loss in performance)? I've just never seen a case where async has benefited compute-heavy loads and this is the first time I've ever heard someone argue for it.
@devnought mentioned, async brought some great gains in Bevy, which is by no means network or IO heavy ( after the game is done loading assets anyway ).
In the linked post, async is only ever mentioned alongside I/O and network. Do you know if there is someplace I can read about how Bevy is applying async to CPU-based tasks? As far as I can tell Bevy doesn't use async for compute tasks - the benefits it has gained from moving away from Rayon was due to a change in the thread pool, not by using async.
from rapier.
I just don't see the point in Rapier where .await would be invoked...As far as I can tell Bevy doesn't use async for compute tasks - the benefits it has gained from moving away from Rayon was due to a change in the thread pool, not by using async.
That's a good point. I haven't done a ton of investigation myself into it, but I think you might be right. That would explain it in Bevy's case, so maybe we just use Bevy's thread pool for Rapier then. ;)
You seem to be in the right line of thought I think.
from rapier.
Hey @neachdainn just found another project that might be worth looking into: https://github.com/BVE-Reborn/switchyard.
It's an async executor actually designed for optimizing comput task.
from rapier.
Closing this issue as not planned. During the past few years I have gained much more experience with async
and am convinced it has little to no benefit for compute-only tasks. In my experience Rayonโs parallelism tends to outperform the existing async executors for compute. In addition async
introduces a non-negligible amount of code complexity and compilation time.
from rapier.
Related Issues (20)
- Panics when setting collider via `ColliderSet::get_mut()` HOT 2
- Typo in Clippy fix
- Crashes iOS 14 Safari
- Benchmarks webpage is not working HOT 1
- Need predict_position_using_velocity() without forces
- panic_bounds_check when solving spring joint HOT 2
- How do you simulate refraction? HOT 5
- Objects retain all velocity while moving through a Sensor HOT 4
- `KinematicCharacterController` climbing and sliding along along vertical walls are broken
- `KinematicCharacterController` doesn't respect `offest` HOT 1
- `dyn PhysicsHooks` cannot be shared between threads safely --> WASM compile fails HOT 1
- Perfectly Elastic Ball Loses Velocity After Bounces in Zero Gravity Environment HOT 2
- 2D Rigidbody type changing from Kinematic->Dynamic at runtime doesn't work HOT 2
- Bug: Incrementally-updated `QueryPipeline` memory usage linearly grows over time.
- How do I properly enable parallel in rapier3d? HOT 2
- Feature: Add support for custom friction and bounce CombineRules HOT 2
- Very large 2d cuboid "ground" destabilizes simulation
- Perfectly elastic objects gain energy with TGS soft in Newton's cradle example HOT 1
- parry2d v0.15.0 yanked HOT 5
- rapier3d doesn't compile with simd-nightly HOT 6
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. ๐๐๐
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google โค๏ธ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rapier.