free-gophers-pack VS gokoban

Gopher credits

OK, no more surprises. I promised with that, we now have a full understanding of the main ideas, both big and sneaky, behind the Go scheduler. We started out with a list of goals. How did we do with our goals? Use a small number of kernel threads. We can support high concurrency and we can leverage parallelism. We scale to N-cores and this falls out of those three ideas that we discussed. Let's move on to the harder questions. What are the limitations of the scheduler? Well, for one, there is no notion of goroutine's priority. It uses a first in, first out runQueue vs Linux scheduler which uses a priority queue. Now the cost-benefit tradeoff is doing this might not actually make sense for go programs. The second limitation is there's no strong preemption, so there is no strong fairness in latency guarantees. It's entirely possible for a goroutine in certain cases to bring the inspire system to slow down in a fault. And finally, the third limitation that I want to touch upon today is the scheduler is not aware of the actual hardware topology, so there's no real guaranteed locality between the data and the Goroutine computation, and with that we have come to an end and thank you for reading. Gopher Artwork credit Maria Letta Ashley Mcnamara

I used the Gophers from here - https://github.com/MariaLetta/free-gophers-pack/ and did give a credit to the author in the video and put a link in the description