Hello,

I was reading the code of reactjs and it uses fibers to process the virtual dom. And I found that fibers are green threads i.e. they are like threads but not actually backed by OS or hardware threads by default. I feel like they are pretending to be threads but are actually run sequentially?

So, then if there is only one OS thread that will be executing N fibers, then how does it make sense that the program broken down to execute in those N fibers will be faster than the program that just runs in a straight line from beginning to end? I'm not getting how it can become faster.

I'm imagining that I have only one actual thing that runs code. Then I'm splitting the code I need to run so different parts of it run out of sequence with each other, but still they are all run by that same underlying singular thing that can run code. And that one thing can only run things one by one, even if I ask it to run out of sequence things. So, then how can the end result become faster?

So, then if there is only one OS thread that will be executing N fibers, then how does it make sense that the program broken down to execute in those N fibers will be faster than the program that just runs in a straight line from beginning to end? I'm not getting how it can become faster.

It is not faster. What it allows to do is to interleave execution of such fibers thus making it appear executing all at the same time. Also it allows to split large executions over multiple of frames. If you would do one huge linear execution all at once, then your UI would freeze. Which is bad. Instead you split your large linear execution into multiple parts that get scheduled over multiple frame updates. And because there are multiple N fibers executing you can see updates from different ones happening "at the same time" and not waiting until previous one finishes.

This article helped me to understand how React works: https://pomb.us/build-your-own-react/

This execution model is known as "concurrency" - using threads is not mandatory to have concurrent execution. There are many different ways to implement it: https://en.wikipedia.org/wiki/Concurrent_computing

That article is really nice, I can recognize some of the function names from the codebase of react.

So, I had not understood what that phrase "split large executions over multiple frames", meant. Now I see that this is to give the browser the opportunity to paint frames while the virtual dom computations have not yet finished.

This feels to me like its taking the opposite direction of games where the focus is to hit the fps. Because the physics computation being done between the frames becomes useless once the deadline expires. I haven't gotten to stuff after day 100 in HMH so I don't know what the episodes on SIMD and optimization stuff teach. I guess Ill come back to this once I have seen those episodes and think about it some more.