3 ms·

Which is also one of the reasons why WSL1 was so slow. Windows lacks this cache so programs doing unixy filesystem access patterns perform poorly there.

dspillett 3y ago
The biggest reason for that for many complex processes is that creating a new process (and tearing one down after use) is relatively expensive under Windows. Under Linux (and Unix-a-like OSs generally) creating a process isn't much slower that creating a thread in an existing process, so child processes tend to get used with relative abandon – when an application or script running this way get used under WSL1 (or other wrapping layers over Windows like Cygwin) they were much slower than in their more native environments. It goes hand-in-hand with unix-y filesystem access patterns: creating temporary files and named pipes all over the place as the cost is relatively low. This is also why Unix targetted servers tended to use multi-process models rather than threaded ones: if there is little performance advantage in creating threads, and you don't need the more performant IPC that they offer (not actually IPC: they offer in-process data sharing), the relative simplicity of spawning process makes them more attractive. This has changed a bit over time though: the ubiquity of multi-core CPUs and changes in scheduling practices & such to take better advantage of them has made threads a bit more attractive than they once were under Unix-a-likes too (even when you still don't need the in-process data sharing).
- aseipp 3y ago
  WSL1 did not use the NT codepath in order to spawn processes. WSL1 had its own direct support in the kernel for its own process type ("nanoprocess" is what they called it IIRC) managed independently from NT processes; and it even supported features/APIs for them that NT ones did not have, such as a compatible fork() call
  - dspillett 3y ago
    IIRC that support was still noticeably heavier than starting a thread. Much faster than the unix-y fork() emulation in cygwin/msys/similar, or in things more directly ported to Windows that use native fork equivalents directly, but still not closing the thread/process efficiency difference to that seen away from Windows. This performance difference was one of the reasons (though I think a minor one) that they switched to a managed VM instead of an emulation layer for WSL2.
- pjmlp 3y ago
  As someone that was a big fan of multi-threading, it is somehow ironic that we are going back to multi-process models, not only due to microservices (basically the rebranding of "The network is the computer" for newer generations), but also due to security considerations. UNIX was designed for servers, that was what PDP-11 was good for, and even when workstations came to be, X Windows and other similar protocols, were basically an extension of server workflows anyway. Multithreading was bolted on, and even if all UNIXes ended up converging into pthreads, there is enough stuff on POSIX that doesn't go well with threads.

dspillett 3y ago

The biggest reason for that for many complex processes is that creating a new process (and tearing one down after use) is relatively expensive under Windows. Under Linux (and Unix-a-like OSs generally) creating a process isn't much slower that creating a thread in an existing process, so child processes tend to get used with relative abandon – when an application or script running this way get used under WSL1 (or other wrapping layers over Windows like Cygwin) they were much slower than in their more native environments. It goes hand-in-hand with unix-y filesystem access patterns: creating temporary files and named pipes all over the place as the cost is relatively low. This is also why Unix targetted servers tended to use multi-process models rather than threaded ones: if there is little performance advantage in creating threads, and you don't need the more performant IPC that they offer (not actually IPC: they offer in-process data sharing), the relative simplicity of spawning process makes them more attractive. This has changed a bit over time though: the ubiquity of multi-core CPUs and changes in scheduling practices & such to take better advantage of them has made threads a bit more attractive than they once were under Unix-a-likes too (even when you still don't need the in-process data sharing).

aseipp 3y ago
WSL1 did not use the NT codepath in order to spawn processes. WSL1 had its own direct support in the kernel for its own process type ("nanoprocess" is what they called it IIRC) managed independently from NT processes; and it even supported features/APIs for them that NT ones did not have, such as a compatible fork() call
- dspillett 3y ago
  IIRC that support was still noticeably heavier than starting a thread. Much faster than the unix-y fork() emulation in cygwin/msys/similar, or in things more directly ported to Windows that use native fork equivalents directly, but still not closing the thread/process efficiency difference to that seen away from Windows. This performance difference was one of the reasons (though I think a minor one) that they switched to a managed VM instead of an emulation layer for WSL2.
pjmlp 3y ago
As someone that was a big fan of multi-threading, it is somehow ironic that we are going back to multi-process models, not only due to microservices (basically the rebranding of "The network is the computer" for newer generations), but also due to security considerations. UNIX was designed for servers, that was what PDP-11 was good for, and even when workstations came to be, X Windows and other similar protocols, were basically an extension of server workflows anyway. Multithreading was bolted on, and even if all UNIXes ended up converging into pthreads, there is enough stuff on POSIX that doesn't go well with threads.