Great work! While I agree with most of it, I think you might have missed something. And that is, the benefit of multiprocessing is not really 'true' parallelism. This is because you get 'true' parallelism with multithreading as well. In fact, multithreading will often be the right way to go as opposed to multiprocessing because of how resource intensive it tends to be. Especially with CPU-bound tasks as you mentioned, multithreading can be extremely beneficial in that respect. Even more beneficial than multiprocessing.
In fact you can use shared memory in IPC and run threads in different cores in C using pthreads. I thinks this exposition is very biased towards modern software technologies and not towards the fundamentals of operating system concepts.
I’m learning C after right now so I might not fully understand pthread yet. I think the approach of this video is to surface basic concept between MP and MT from newcomers POV. Considering scalability of processing power, it’s easier to think about each CPU as one processing unit. This train of thought carry us well into later stage of scalability where we just simply add more units to do more work concurrently where multi-core CPU would hit the core limit sooner or later. Considering the core audiences of this video it made sense to me. One thing I have been trying to fully understand is how the application works in clustered setup say K8s. Can you still lock a core for one process alone? I know that we can set to 1k millicore but how that works under the hood is beyond me today.
@@RobGThai Well. A lot of information and English is not my native language. I will try to do my best. First, when teaching newcomers, you should not talk about concepts related to I/O, etc beforehand because a lot of background information is needed first. With the above examples I simple saying that MP and MT concepts are poorly explained (not so much) because this is valid in some contexts and not in all contexts per se. If you talk to the general public, the simple thing to do is to say that a thread is a lightweight process and stop there. This is the fundamentals of concurrency course at the university that i have been teaching for the past 28 years. In fact, from an architecture perspective, it is more important to understand how much can be parallelized and what the concurrency issues are. From there, you can adjust the number of threads and processes your application need. And of course, you need to understand your production environment where your application is deployed. As for the question about k8s, it is a container question. Assigning specific cores or vcores is a trick. What you're really fine tuning is how the kernel scheduler and cgroups work in an MP context. This is really efficient because the I/O is also virtualized. Threads in a container with low resources are not a good practice. But from an architectural perspective you need to balance your design from the perspective of different types of I/O in addition to the computational needs. If you have a lot of of blocking system calls in your application, you may be better served by more containers like microservices, but if you I/O is not blocking you can benefit from MT. Special considerations must be taken if your running your code in GPUs. Another talk.
truly interesting. thanks for sharing. anyway, I found asyncio is a more lightweight solution to handle heavy I/O bound concurrent processes. could you later make a comparison just like this multithreading VS multiprocessing?
I think it's a classic tradeoff one makes when designing a piece of technology. Python's philosophy is to keep things simple, less error-prone and faster dev time. It's easy to pick up and most of Python's applications (e.g. web servers, ML) are I/O bound so this wouldn't matter.
@@SystemDesignSchooli dont think python is less error prone, because it is dynamic language, meaning less useful snippets, possible misinterpretation of black box output and input and that many errors can be detected only at the runtime. So its not as robust as c#, java or rust for example. But i agree with everything else, and want to add that python is really great for prototyping and simple one-shot utility applications, as it significantly reduces boilerplate.
Great work! While I agree with most of it, I think you might have missed something. And that is, the benefit of multiprocessing is not really 'true' parallelism. This is because you get 'true' parallelism with multithreading as well. In fact, multithreading will often be the right way to go as opposed to multiprocessing because of how resource intensive it tends to be.
Especially with CPU-bound tasks as you mentioned, multithreading can be extremely beneficial in that respect. Even more beneficial than multiprocessing.
If this video was released just a few days ago, i would have passed my OS exam :)
Nice explanation!
These are good and simple explanations, and the BGM is relaxing!
In fact you can use shared memory in IPC and run threads in different cores in C using pthreads. I thinks this exposition is very biased towards modern software technologies and not towards the fundamentals of operating system concepts.
I’m learning C after right now so I might not fully understand pthread yet. I think the approach of this video is to surface basic concept between MP and MT from newcomers POV. Considering scalability of processing power, it’s easier to think about each CPU as one processing unit. This train of thought carry us well into later stage of scalability where we just simply add more units to do more work concurrently where multi-core CPU would hit the core limit sooner or later. Considering the core audiences of this video it made sense to me.
One thing I have been trying to fully understand is how the application works in clustered setup say K8s. Can you still lock a core for one process alone? I know that we can set to 1k millicore but how that works under the hood is beyond me today.
@@RobGThai Well. A lot of information and English is not my native language. I will try to do my best. First, when teaching newcomers, you should not talk about concepts related to I/O, etc beforehand because a lot of background information is needed first. With the above examples I simple saying that MP and MT concepts are poorly explained (not so much) because this is valid in some contexts and not in all contexts per se. If you talk to the general public, the simple thing to do is to say that a thread is a lightweight process and stop there. This is the fundamentals of concurrency course at the university that i have been teaching for the past 28 years. In fact, from an architecture perspective, it is more important to understand how much can be parallelized and what the concurrency issues are. From there, you can adjust the number of threads and processes your application need. And of course, you need to understand your production environment where your application is deployed.
As for the question about k8s, it is a container question. Assigning specific cores or vcores is a trick. What you're really fine tuning is how the kernel scheduler and cgroups work in an MP context. This is really efficient because the I/O is also virtualized. Threads in a container with low resources are not a good practice. But from an architectural perspective you need to balance your design from the perspective of different types of I/O in addition to the computational needs. If you have a lot of of blocking system calls in your application, you may be better served by more containers like microservices, but if you I/O is not blocking you can benefit from MT. Special considerations must be taken if your running your code in GPUs. Another talk.
I think what is missing is a preface that this is a Python specific video.
truly interesting. thanks for sharing.
anyway, I found asyncio is a more lightweight solution to handle heavy I/O bound concurrent processes.
could you later make a comparison just like this multithreading VS multiprocessing?
Introducing #Golang *(Goroutines)* 👑
cool videos
good work, but please remove the BGM
Agreed
Sumarizing, don't use python.
😂
I think it's a classic tradeoff one makes when designing a piece of technology. Python's philosophy is to keep things simple, less error-prone and faster dev time. It's easy to pick up and most of Python's applications (e.g. web servers, ML) are I/O bound so this wouldn't matter.
@@SystemDesignSchool And then someone said "why not both?", and Go was born 😂
@@SystemDesignSchooli dont think python is less error prone, because it is dynamic language, meaning less useful snippets, possible misinterpretation of black box output and input and that many errors can be detected only at the runtime. So its not as robust as c#, java or rust for example.
But i agree with everything else, and want to add that python is really great for prototyping and simple one-shot utility applications, as it significantly reduces boilerplate.
@@mek_Morok pydantic enters the chat
Lets go😊
Annoying music 😮