Sleep and Cpu Usage: Going forward

Development Engine
#1

As this https://github.com/amethyst/amethyst/pull/2479 pull request puts into light, there are still issues with sleeping and spinning where we get the timings wrong. Along with this, we also receive issues from time to time about the cpu usage of the spin loop.

Currently, we are replicating the behavior of the https://crates.io/crates/spin_sleep.
Moving to it would allow us to work on other things than trying to get the sleeping and spinning behavior just right. However, spin_sleep doesn’t support wasm (I don’t think amethyst does either, to be honest.).

My suggestion would be that we add wasm compatibility in spin_sleep, integrate it in amethyst and remove our custom sleep/spin constructs.

Before this, I want to gather some opinions. Is there any reason we wouldn’t want to do this?

2 Likes
#2

I think this is a good idea. I can’t think of any reason to maintain our own platform-specific sleep code.

#3

Relying on a dedicated external crate for cross-platform sleeping and spinning sounds ideal to me. I’m not familiar with spin_sleep itself.

Given that Amethyst doesn’t support wasm yet, the order of operations could just as well be 1) switch to spin_sleep, and then 2) add wasm support to spin_sleep, rather than the other way around.

1 Like
#4

I favor CleanCuts proposed way, as this would bring us better behavior instantly.
Depending on how long it takes to get something upstream: Can we create a wrapper around spin_sleep, and provide a makeshift wasm alternative inside of amethyst? Or make it pluggable with adding a Trait and implementing that one on the wrapper?

1 Like