Windows 7 multi-processing

[johnbsayles]

Am I nuts, or is all this flap about PC "multi-processing" just smoke and mirrors? I'm running Windows 7 and I like it from a user standpoint. But from a programmer view, I see small clues that tell me Microsoft is once again fundamentally blowing smoke and telling me that I love it. Small clue: on Windows XP/Vista/7, there is no Fork() process/thread...if there is I haven't found it. When I'm programming, in Rexx (why? because I like it), there is no "immediate return" from anything...not I/O, not after calling an independent process/program, not even allowing execution from a stack after my program has terminated...the system doesn't read the stack between program/process executions.

NONE of this stuff is true when I'm running a Linux/Un*x OS. Rexx itself has a Fork() function on those platforms, you can do overlapping I/O, and schedule an immediate execution of a process/program via the stack. So whatever the limitations are, they are not in the hardware...although I have some misgivings about that...the limitations are in the Windows Operation Systems whatever the flavor. And I think I know why...and it sucks for all of us.

First of all, let me back up and define some terms. What does "multi-core" mean?...it means NOT stacking all of a CPU's circuits on one chip, because of heat considerations. They are spread out on thinner chips because they cool faster when running. They are NOT multiple CPU's. What is "parallel processing"? That is the scheduling of independent processes which are part of the same overall problem set, that eventually have to be serialized when putting together the entire answer to the problem set. And what is "multiprocessing"? That is the utilization of several CPU's which have been logically bound together for the efficient scheduling of subtasks within an operating system.

So what do we have today? We have multi-core systems that imply they are multi-processors (not true!). Some
claim to run parallel processing but what they really do is run "distributive processing" among the chips in a multi-core CPU. (For "distributive processing" see SETI@home, a brilliant concept for worldwide processing.)

Having said all this, I understand that in human terms there isn't any difference today between a display that takes 1 millisecond to propagate and one that takes 100 milliseconds. It's normally faster than we can think. But tomorrow, it might make a huge difference...see Moore's and Amdahl's laws. And gamers already know what CPU speed means.

So my rant is with Microsoft and its inability to step up to the state of the art. They cannot bring themselves to do that because...if any of its operating systems were coded as true multiprocessing systems, then Windows XP, for example, would never need an upgrade to Vista or 7, it would run just fine forever, or at least a long time between upgrades, and Microsoft will not tolerate that. It means big $$$$ to them and big expenditures for you and me.

 

[sminlal]

> The important point that Kewlx omitted was the performance overhead of processes compared to threads.
True, but to be fair he was comparing Windows threads/processes to *nix where process creation is significantly lighter than in Windows.

> I think the reasoning behind the fork call is that the child inherits the complete environment of it's parent - including file handles.
Yes, I think you're totally correct there. You can do the same thing with the CreateProcess API call in Windows, but then of course that call has about a zillion parameters so it's not as straightforward as fork.

 

[Kewlx25]

I really like how this thread turned out. It could have easily turned into a flame war, but instead there was lots of good input.

> The important point that Kewlx omitted was the performance overhead of processes compared to threads.
True, but to be fair he was comparing Windows threads/processes to *nix where process creation is significantly lighter than in Windows.

Pretty much what you said. I did not feel comfortable making too much more of a comparison than I already did because of my lack of in-depth *nix knowledge. I also know that *nix goes about the same problem in a different way than Windows(eg. threads vs processes), and are optimized for their different ways.

Also, in my limited experience with Linux+Apache, Apache would pre-load processes before they were required. This meant processes didn't need to be created in real time, which kept access times snappy. The other thing I noticed about Apache at that time, is each spawn/fork had VERY low memory usage, so it's not like Linux was wasting more memory having forks instead of threads.

 

[Ijack]

Apache is something of a special case becasue it can be configured to use different MPMs (Multi-Processing Modules) which will affect exactly how it handle multiple connections.

 

[sminlal]

The other thing I noticed about Apache at that time, is each spawn/fork had VERY low memory usage, so it's not like Linux was wasting more memory having forks instead of threads.

Yeah - you can't call yourself a decent multiprogramming OS these days unless you do sensible memory management such as sharing read-only pages containing the program code between all the processes that use them. Windows also does that for multiple processes, of course. But Windows programs tend to use CreateThread() where *nix programs use fork(), so you don't see that many multi-process programs. But the underlying system DLLs do get a major benefit from memory sharing.