Our great sponsors
-
free-gophers-pack
✨ This pack of 100+ gopher pictures and elements will help you to build own design of almost anything related to Go Programming Language: presentations, posts in blogs or social media, courses, videos and many, many more.
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
-
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
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.