4 ms·

> is very similar. Except that the threads share the exact same virtual address space, and processes do not, which makes the thread context switch faster. And

> is very similar. Except that the threads share the exact same virtual address space, and processes do not, which makes the thread context switch faster. And that is to say nothing about the setup and teardown process, which for a process involves copy-on-demand'ing the entire memory, but for a thread merely setting up its own stack.

commonlisp94 3y ago
> Except that the threads share the exact same virtual address space, and processes do not, which makes the thread context switch faster That's what I said. But it's really not much. I'm afraid we will need numbers now to continue the conversation. If I measured would you be open to changing your opinion? Or are you committed to this topic, so that it would have no bearing?
- kerkeslager 3y ago
  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 <50 lines of code for each, so I'm eagerly waiting for your response! 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 <stdio.h> #include <pthread.h> #include <unistd.h> 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 < numThreads; i++) { int result = pthread_create(&threads[i], NULL, threadFunction, NULL); if (result != 0) { printf("Failed to create thread %d\n", i); return 1; } } // Join threads for (int i = 0; i < numThreads; i++) { int result = pthread_join(threads[i], NULL); if (result != 0) { printf("Failed to join thread %d\n", i); return 1; } } return 0; } And... #include <stdio.h> #include <sys/types.h> #include <sys/wait.h> #include <unistd.h> int main() { int numProcesses = 1000000; pid_t childPID; // Create processes for (int i = 0; i < numProcesses; i++) { childPID = fork(); if (childPID < 0) { printf("Failed to create process %d\n", i); return 1; } else if (childPID == 0) { // Child process sleep(10); return 0; } } // Wait for all child processes to finish int status; pid_t pid; while ((pid = wait(&status)) > 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.
  - commonlisp94 3y ago
    I just tried your tests on Debian. For some reason the threads one was failing at about 3000 (probably my config), so I bumped it down for both. Here are the results: $ gcc threads.c $ time ./a.out real 0m10.097s user 0m0.035s sys 0m0.239s $ gcc process.c $ time ./a.out real 0m10.168s user 0m0.579s sys 0m0.347s Were you running on something besides linux, or not natively? Is this something that degrades with the large numbers? Also, spawning is not context switching. That's the overhead that matters. But according to your own test, spawning in reasonable numbers will be about the same.
    - kerkeslager 3y ago
      > Were you running on something besides linux, or not natively? Running on MacOS, but I've run this in Linux. > Is this something that degrades with the large numbers? The concern here is memory--once you push into pagefile your processes will become extremely slow. > Also, spawning is not context switching. Thank you obviousman. > That's the overhead that matters. Why do you think you know every use case? You don't. There are tons of use cases where having to be concerned about creating and destroying threads places a large burden on the developer. > But according to your own test, spawning in reasonable numbers will be about the same. You didn't run my test. Running 3000 processes is a few orders of magnitude less than running 1000000, and you don't get to determine what "reasonable" is for every application that exists.
      - commonlisp94 3y ago
        It's your own test, I don't need see why you need to respond in this manner. > Running 3000 processes is a few orders of magnitude less than running 1000000 I didn't decide on the limit, my OS did. So they must think it's unreasonable. > Running on MacOS, but I've run this in Linux. Well your test works fine on linux. MacOS is not designed to run large multi-process server loads. Linux has specifically optimized forking and context switching for processes. > Why do you think you know every use case? Why do you think you can't handle most cases by using processes? The goal isn't for a tool to handle every use case, it's to handle a specified set of use cases well. Python itself doesn't work for every use case. Looks like we are safe to ignore overhead of launching processes for programs with fewer than 3000 threads. > Thank you obviousman. I wanted to compare context switch, you decided to measure something else. I am pleasantly surprised anyway.

commonlisp94 3y ago

> Except that the threads share the exact same virtual address space, and processes do not, which makes the thread context switch faster That's what I said. But it's really not much. I'm afraid we will need numbers now to continue the conversation. If I measured would you be open to changing your opinion? Or are you committed to this topic, so that it would have no bearing?

kerkeslager 3y ago
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 <50 lines of code for each, so I'm eagerly waiting for your response! 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 <stdio.h> #include <pthread.h> #include <unistd.h> 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 < numThreads; i++) { int result = pthread_create(&threads[i], NULL, threadFunction, NULL); if (result != 0) { printf("Failed to create thread %d\n", i); return 1; } } // Join threads for (int i = 0; i < numThreads; i++) { int result = pthread_join(threads[i], NULL); if (result != 0) { printf("Failed to join thread %d\n", i); return 1; } } return 0; } And... #include <stdio.h> #include <sys/types.h> #include <sys/wait.h> #include <unistd.h> int main() { int numProcesses = 1000000; pid_t childPID; // Create processes for (int i = 0; i < numProcesses; i++) { childPID = fork(); if (childPID < 0) { printf("Failed to create process %d\n", i); return 1; } else if (childPID == 0) { // Child process sleep(10); return 0; } } // Wait for all child processes to finish int status; pid_t pid; while ((pid = wait(&status)) > 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.
- commonlisp94 3y ago
  I just tried your tests on Debian. For some reason the threads one was failing at about 3000 (probably my config), so I bumped it down for both. Here are the results: $ gcc threads.c $ time ./a.out real 0m10.097s user 0m0.035s sys 0m0.239s $ gcc process.c $ time ./a.out real 0m10.168s user 0m0.579s sys 0m0.347s Were you running on something besides linux, or not natively? Is this something that degrades with the large numbers? Also, spawning is not context switching. That's the overhead that matters. But according to your own test, spawning in reasonable numbers will be about the same.
  - kerkeslager 3y ago
    > Were you running on something besides linux, or not natively? Running on MacOS, but I've run this in Linux. > Is this something that degrades with the large numbers? The concern here is memory--once you push into pagefile your processes will become extremely slow. > Also, spawning is not context switching. Thank you obviousman. > That's the overhead that matters. Why do you think you know every use case? You don't. There are tons of use cases where having to be concerned about creating and destroying threads places a large burden on the developer. > But according to your own test, spawning in reasonable numbers will be about the same. You didn't run my test. Running 3000 processes is a few orders of magnitude less than running 1000000, and you don't get to determine what "reasonable" is for every application that exists.
    - commonlisp94 3y ago
      It's your own test, I don't need see why you need to respond in this manner. > Running 3000 processes is a few orders of magnitude less than running 1000000 I didn't decide on the limit, my OS did. So they must think it's unreasonable. > Running on MacOS, but I've run this in Linux. Well your test works fine on linux. MacOS is not designed to run large multi-process server loads. Linux has specifically optimized forking and context switching for processes. > Why do you think you know every use case? Why do you think you can't handle most cases by using processes? The goal isn't for a tool to handle every use case, it's to handle a specified set of use cases well. Python itself doesn't work for every use case. Looks like we are safe to ignore overhead of launching processes for programs with fewer than 3000 threads. > Thank you obviousman. I wanted to compare context switch, you decided to measure something else. I am pleasantly surprised anyway.