4 ms·

You can. This is what the demo does. The scheduler takes that amount and schedules is, which is the point. Every game engine does that (for instance frustrum cu

You can. This is what the demo does. The scheduler takes that amount and schedules is, which is the point. Every game engine does that (for instance frustrum culling). Games face an impossible amount of data, and schedule it. This is also true for native dev where you have priority dispatchers and threads. What React does is exciting because it schedules at the very root.

kilburn 7y ago
I put cannot in cursive because yes, you can schedule over the processing capacity limits. However, the CPU acts as a rate limiter in and of itself. If your CPU cannot process 2_000 updates per second, you will not be doing more than that, period. You can schedule 4_000 updates, but they will take 2s to process, no way around it. If you keep scheduling over the processing app capabilities, you will just run out of memory to hold the queue. Nobody is interested in doing that. What games do is fundamentally different than what react is doing here. In games there are many places where you can trade off quality for speed (for instance frustrum culling). You can decide to compute less to fit within your computation time slice. Likewise, physics can take into account the update rate to adjust to the CPU/GPU's processing capability (i.e: you can use a delta_t in your computations to adjust for frame differences). In the website there are some such opportunities (you could do it with animations for instance), but you cannot do it in general because most apps logic would not tolerate it (yeah sorry I dropped your request callback bad luck). For this reason I would be very surprised if React went that route.
bathtub365 7y ago
Frustum culling is completely unrelated to scheduling. It’s just a technique for avoiding spending processing or rendering time on things that can’t be seen by the camera. It existed before games were multithreaded, during the time when they typically had a single main loop. Games are not using complex scheduling and multithreading to achieve acceptable performance updating 2000 entities. You can achieve that easily on a single thread by laying your data out to take advantage of locality of reference and the CPU cache.
gdxhyrd 7y ago
No game engine does that and they don't face an "impossible" amount of data. A game designer may choose to spread work over several frames, but that is done on purpose by the developer. And frustum culling has nothing to do with this nor it reduces any amount of updates.
Jasper_ 7y ago
Games don't face an impossible amount of data. It might look like an impossible amount of data, but they play all sorts of cheats. In you have a crowd with 8k people, there might be 50 animations being computed and shared between the rest of the skeletons. All members of the staff -- environment artists, character artists, level designers, animators, FX artists -- are all very technical and have the power and wisdom to use the framerate wisely. I'm not even sure why you're bringing up frustum culling -- you're suggesting that we have too many objects to run the cull math on so we schedule across frames? But we don't; that results in visual popping. If culling is a bottleneck, we usually solve by broad-phase data structures like octrees, or ask the artists to condense multiple separate models into one so we have less objects to manage (another big cheat, artist labor).

kilburn 7y ago

I put cannot in cursive because yes, you can schedule over the processing capacity limits. However, the CPU acts as a rate limiter in and of itself. If your CPU cannot process 2_000 updates per second, you will not be doing more than that, period. You can schedule 4_000 updates, but they will take 2s to process, no way around it. If you keep scheduling over the processing app capabilities, you will just run out of memory to hold the queue. Nobody is interested in doing that. What games do is fundamentally different than what react is doing here. In games there are many places where you can trade off quality for speed (for instance frustrum culling). You can decide to compute less to fit within your computation time slice. Likewise, physics can take into account the update rate to adjust to the CPU/GPU's processing capability (i.e: you can use a delta_t in your computations to adjust for frame differences). In the website there are some such opportunities (you could do it with animations for instance), but you cannot do it in general because most apps logic would not tolerate it (yeah sorry I dropped your request callback bad luck). For this reason I would be very surprised if React went that route.

bathtub365 7y ago

Frustum culling is completely unrelated to scheduling. It’s just a technique for avoiding spending processing or rendering time on things that can’t be seen by the camera. It existed before games were multithreaded, during the time when they typically had a single main loop. Games are not using complex scheduling and multithreading to achieve acceptable performance updating 2000 entities. You can achieve that easily on a single thread by laying your data out to take advantage of locality of reference and the CPU cache.

gdxhyrd 7y ago

No game engine does that and they don't face an "impossible" amount of data. A game designer may choose to spread work over several frames, but that is done on purpose by the developer. And frustum culling has nothing to do with this nor it reduces any amount of updates.

Jasper_ 7y ago

Games don't face an impossible amount of data. It might look like an impossible amount of data, but they play all sorts of cheats. In you have a crowd with 8k people, there might be 50 animations being computed and shared between the rest of the skeletons. All members of the staff -- environment artists, character artists, level designers, animators, FX artists -- are all very technical and have the power and wisdom to use the framerate wisely. I'm not even sure why you're bringing up frustum culling -- you're suggesting that we have too many objects to run the cull math on so we schedule across frames? But we don't; that results in visual popping. If culling is a bottleneck, we usually solve by broad-phase data structures like octrees, or ask the artists to condense multiple separate models into one so we have less objects to manage (another big cheat, artist labor).