Well, I don't know how you'd test that, but you should really consider testing the other half of the post you're responding to which you ignored, because that's much easier to test:
Spin up and tear down a million pthreads in C, and see how long that takes and how much memory it takes. Then spin up and tear down a million processes in C and see your computer grind to a halt until you kill the process that is starting the processes, if you can even get your computer to do that without power-cycling.
It's Notably, my confidence here comes from the fact that I don't generally get into performance arguments without having actually tested what I'm saying. I've written this code before--it's what I do whenever I'm checking out a new programming language or threading library. Given the complexity of modern computers, nobody really can predict how a program will behave without testing it (except maybe in assembly) there's just too many variables. So you should stop doing that.
If you decide to try the same thing in Java (the other language mentioned), probably drop the number of threads/processes down to 100,000, since Java's lightweight threads aren't quite as efficient. 100,000 processes will probably still be enough to crash your computer.
I'm sure you can find some language/library which implements threads particularly inefficiently, so let's stick to pthreads/C and avoid that straw man.
EDIT: Here ya go, I had ChatGPT write this one for ya:
#include
#include
#include
void* threadFunction(void* arg) {
// Sleep for 10 seconds
sleep(10);
pthread_exit(NULL);
}
int main() {
int numThreads = 1000000;
pthread_t threads[numThreads];
// Create threads
for (int i = 0; i
And...
#include
#include
#include
#include
int main() {
int numProcesses = 1000000;
pid_t childPID;
// Create processes
for (int i = 0; i 0);
return 0;
}
It looks like the latter just crashes the program without taking down my whole machine now, which is an improvement over the last time I tried this with processes.