Windows 7 multi-processing

Toggle sidebar Toggle sidebar
johnbsayles

johnbsayles

Distinguished
Jan 27, 2010
7
0
18,510
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.
 
Sort by date Sort by votes
REXX? Really? You're basing an argument on how capable Windows is on some implementation of an interpreted scripting language?

The native Windows API which is accessible to practitioners using >ahem< real programming languages includes full support for multithreading which means true parallel instruction execution on multicore (chips with multiple processing units) and multiprocessor (motherboards with multiple chips) systems. This support also includes a rich suite of thread synchronization capabilities and interprocess commnication functions. See: http://msdn.microsoft.com/en-us/library/ms684852%28VS.85%29.aspx

If your version of REXX doesn't include multiprocessing support then it's a limitation of the implementation, not of Windows.

 
Upvote 0 Downvote
No idea what you are ranting about, but while i am running W7 on my dual core i can see both cores utilised, hence i am satisfied by Microsoft's claim of "multi-processing".
Bottom end: The OS is very fluid and the CPU is doing what is supposed to do, so i am happy!
 
Upvote 0 Downvote
Hey John, I didn't mean to hit on you too hard. Judging from your age and your use of REXX I'm wondering if you come from a mainframe background - perhaps MVS or VSE? My roots go back to System/360 DOS - and then some.

I don't really have anything against scripting languages per se, and in fact I use scripting fairly heavily myself (although not REXX). But I recognize the limitations of scripting languages and use C# or C++ to do the heavy lifting when it's needed.

To put it another way - saying that Windows is useless because of limitations in REXX is like saying IBM mainframes are useless because of limitations in RPG. Don't blame the OS, blame the tool.

It may be that REXX supports multiprocessing on other platforms, but that doesn't mean that Windows is somehow limiting what REXX can do. It's really just an omission on the part of whoever ported REXX to Windows, nothing more.
 
Upvote 0 Downvote


Hey, that's OK. I'm glad to get a response. Yes, I'm a dinosaur...I'll send you my resume sometime. I did come from a mainframe background. It was where I learned to really program. I read Dijkstra's treatise on modular programming and it changed my programming life. I never used a GOTO ever again. Still don't. That kind of "black box" thinking was the forerunner of Object Oriented Programming, which, I have to say, I have problems with (don't get me started).

Anyway, yes, mucho systems and applications in my life: MVT, MVS, TPF, VM/CMS, S/390, but before them I learned true multiprocessing on a Univac 1108, as a boy wonder in the Systems group (I was 20 years old). What I know is that design hasn't changed. It is still based on Von Neumann logic circuits, no matter how small they get, no matter how short the paths are. Operating systems HAVE TO be designed the same old way, until some "quantum" breakthrough occurs...pun intended. The same old Lock-Spin mechanisms, same old interrupt handling, same old dispatcher priority scheduling, all have to occur just like forever ago.

I was very fortunate then, to step right into a world of very hot mainframes...the fastest and biggest things going at the time in the commercial world. I never looked back. It was all I ever knew until I got my first PC. And I was appalled. PC design was a step back into the Stone Age. Whereas on a mainframe I designed and coded to solve a business problem, on a PC I had to do basic things...things I took for granted on a mainframe...handle the specifics of I/O, scheduling, memory, well, it was all evil brain damage. I eventually stopped trying to program at home after a day of programming at work. I just became a PC user.

And I still am, and for the most part happily so. But in the last couple of years I have taken up programming again, just to keep my mind in the life game. Why Rexx? Because I originally found it in the early '80s, at a time when I needed something more out of programming. And it had a Compiler. And it was a natural language, it was Von Neumann on steriods, but I could talk to it in understandable words. It was so easy to get a job done without syntax and language rules getting in the way, as I find occurs with most other high-level languages, yesterday or today. BTW, here is a list of my languages: Fortran(II,III,IV), 1108 Assembler, 360/370 Assembler, PL/1, COBOL (I hate it), Rexx(of course), Commodore64(I'm not even kidding). I've looked at instruction sets for AMD and Intel and their different flavors...all the same stuff, load-add-store, etc. with some fancy instructions added for each model /brand of processor.

And BTW, I NEVER said that Windows was useless, just that Microsoft was not very honest with us about the capabilities of ANY of its operating systems. MS's view: Let them think what they(us) want to think. We remain silent.

So we geeky consumers out here have to know what is going on...that's why we have Tom's Hardware.
--- 30 ---
 
Upvote 0 Downvote

I can only say that you haven't looked very hard. The API call to create a process is, imaginatively, called "CreateProcess"; and the one to create a thread is...I'll leave you to guess what it might be called.

All NT versions of Windows are true multi-process, multi-thread Operating Systems. In fact Windows had multi-threaded programming long before most UNIX variants did.
 
Upvote 0 Downvote


Thanks, darkguset. He looked up my age and felt badly about dissing his (grand)father. But that's OK. I can give it right back when I need to. I just don't need to right now.

And hey, if you're happy with the way Windows 7 works, I'm happy for you. So far I am too...except for the Blue Screen Of Death when I try to reawaken it from sleep. I must have a bad driver out there somewhere. I 'll look it up sometime.

What I like is that it boots up really fast!...much faster than XP...and the same with shutdown. So the BSOD is avoidable by me telling it to never sleep. I can shutdown and reboot so easily. And I like the appearance of the panels...softer edges, more pleasant-to-look-at fonts. At the very least, Windows 7 is a nice cosmetic enhancement to XP. I don't even count Vista...it was a cartoonish disaster, as well as having new internal problems of its own.

Thinking of multi-core's, we are fast approaching a Ghz limit on CPU's due to heat dissipation problems. So eventually, Microsoft is going to HAVE TO take the wraps off its OS and make it go true multi-processing. When that happens you will see many MS personnel jumping ship...they will know that MS's days are numbered. It's not an accident that Bill Gates "retired". He saw the future, with CPU's, OS's, with "cloud computing", and he ran away. If I was him, I would too.

Talk to you later...and that's --- 30 ---
 
Upvote 0 Downvote


Thanks, ijack. I have looked up the "CreateProcess" and "CreateThread" API calls before, and they're not telling me what I want to know. When you say Windows NT OS's are true "multi-process" and "multi-thread", that's absolutely true. But neither one is what I'm after. In Microsoft's world, "multi-process" is a term used to represent "multi-program", i.e., the running of several programs at the same time in the system...NOT instantaneously simultaneous. Instead, two or more programs are shown to be "active" in the system...NOT actually RUNNING and executing instructions at the same time. They can't. The OS cannot schedule more than one of them on more than one CPU, because there is only one CPU on the system. The term "multi-core" does not refer to different CPU's, only to different sections of the same CPU, spread out in the circuit matrix to dissipate heat more readily. The dispatcher in the OS only sees one CPU, but multiple programs/processes/threads on-queue in various wait conditions, except for the one the OS is about to give up control to. And BTW, "multi-thread" is just a subset of "multi-process", using some portion of a process's memory/resource space. In order for MS's OS's to be multiprocessing, they have to be rebuilt/compiled/assembled to recognize more than one CPU, and dispatch accordingly. And this is something MS is loathe to do, because...the Windows PC will have greatly improved throughput, and hence, upgrades will occur much less frequently than they do now. MS will lose control of upgrades, and will eventually go down as they lose market share. So the bottom line is...as always...the bottom line.

And that's --- 30 ---
 
Upvote 0 Downvote


I was a late convert to OO programming - for years I resisted and stuck with good 'ol C++. Even my GUI programs all used native Windows API calls and message handling to do their work. But of late I've started using Microsoft's C# with the .Net framework and I've found it to be a very capable, well-implemented environment. I think the difference is that the entire architecture was designed as OO from the ground up and no real concessions were made in the name of backwards compatibility.
 
Upvote 0 Downvote

I'm afraid that I'd have to say that you misunderstand multi-core processors which are, indeed separate processors in one package (although closely linked - a good thing as it makes communication between the separate cores more efficient) unlike hyperthreaded processors which were more like what you describe. So a quad-core Intel processor really does have four CPUs which can all run at the same time, and will do so on a Windows 7 system.

But let's leave that aside and just consider actual separate chips. I used to run Windows NT on dual processors; two actual processors and you could run Windows 7 on four separate processors if you could find an appropriate motherboard. Microsoft limit the number of processors that can be used by the different editions of Windows, but this is purely a marketing thing. The maximum that any edition of Windows can address is, I believe, 64 processors. Rest assured that this does not represent a single 64-core chip!

If you look at the internals of NT you'll find that the dispatcher can indeed schedule threads on separate processors - in fact you can even specify which processor a thread runs on. Normally you just leave it up to the OS to decide this sort of detail, but if you watch task manager you'll find that some processes only use one core (defragging seems to be an example if I remember correctly), whereas others will use two or more cores.
 
Upvote 0 Downvote

What you're saying is true of a single CPU with a single core. But you're mistaken about multi-core CPUs such as the Core i7 series. These chips literally do have multiple CPUs on the same piece of silicon. A 4-core CPU has four complete sets of program registers, four program counters (PSW's in mainframe-speak), four sets of condition codes, and can execute four instructions AT THE SAME TIME. (Actually, because each CPU is superscalar it can execute MORE than 4 instructions at once).

Here's a diagram of the Nehalem microarchitecture in the Core i7 series of CPUs:

480px-Intel_Nehalem_arch.svg.png


This diagram represents the circuitry required to run a program - it includes the registers, logic to fetch instructions, decode them, detect dependencies, queue or reorder them if necessary for execution, do the actual work, and then store the results in the registers or memory. Aside from the shared cache and bus interface which is shown in orange in the upper-right part of the diagram, a Core i7 CPU has this entire set of circuitry replicated four times on the CPU die. It really can run four completely independent instruction streams at the same time. Not by switching between them, but by feeding each of the four streams of instructions into it's own instance of this microarchitecture - all on the same piece of silicon.

And Windows really, really can schedule threads and processes on all of the cores and they really, really do run simultaneously. And if you have a multiprocessor system, say a system with four Core i7 chips, each one containing four cores, then Windows really, truly can run sixteen different threads of execution at the same time. And it's been able to do this ever since the original version of NT back in the 90's.

I'm not sure what else I can say to convince you, other than to ask if you still don't think Windows can do this, why not?
 
Upvote 0 Downvote
> In Microsoft's world, "multi-process" is a term used to represent "multi-program", i.e., the running of several programs at the same time in the system...

Just to be clear, in Windows the difference between a thread and a process is that each process contains one or more threads. Each process has it's own, separate memory space which is protected from other processes (although two processes can elect to map a shared region of memory if they want to communicate in this way). Multiple threads in the same process all share the same common memory space.

In most modern usage, "Multiprogramming" means the ability to run multiple programs at once, whether or not the CPU is actually capable of running simultaneous instruction streams (if not, the programs are executed "round robin" or on a priority basis). "Multiprocessing" means a system with multiple physical processors and an operating system capable of scheduling programs to run on them. "Multiprocessing" is a bit blurred these days because of multi-core CPUs, but the industry seems to be using it to refer to systems that have more than one CPU chip in them. Thus a system with dual 4-core CPUs seems to be labeled as a multiprocessor whereas one with only one 4-core chip isn't.

But it's important to understand that, aside from some performance implications related to things like caching or bus contention, if other factors like microarchitecture and clock speed are equal then one 4-core CPU can do the same amount of work as four 1-core CPUs.
 
Upvote 0 Downvote


I am currently banging my head on OOP, attempting to dislodge all the old procedural thinking I've accumulated over the years. But it's difficult. I'm trying to learn both ooRexx and Java at the same time. That's not as hard a task as it might seem. The concepts are the same, the differences are just cosmetic. My son, who is a Website creator/engineer, gave me a book call "Object-Oriented Data Structures Using Java", which I studied. It was very helpful. It gave me a stepwise approach to designing ever more complex OO programs. I needed that. An interesting aspect of the book was that most of the functional approaches...things like searches, fast indexing, lists, etc...were things that my (our) generation of programmers had invented. We didn't know it then but we were on the bleeding edge of software design as it appears today. It was a time in which we knew the tools we didn't have, and so we went and made them up. Now they exist as code in a million Java libraries. And now I have to re-learn programming so that I can speak OO. What I have to do, I realize, is break a problem down into parts that are amenable to using different libraries. I have to memorize the names of libraries, classes, and methods useful for a subset of a given type of problem. That to me is what most of OO is about. Is this programming?...I don't know. Maybe. I'll see.

--- 30 ---
 
Upvote 0 Downvote


Thanks, ijack, for setting me straight. But my paradigm won't require as much of a shift as I think. I just have to read the fine print on all the CPU boxes at MicroCenter a little more closely.
--- 30 ---
 
Upvote 0 Downvote


Thanks, sminlal. Oh I'm OK. I'm just hardheaded. As I told ijack, I need to read the fine print on the CPU boxes at MicroCenter a little more closely. My paradigm shift won't be that great. And yes, I believe you guys.
--- 30 ---
 
Upvote 0 Downvote
That's what programming is today, no doubt about it. No more coding linked lists, you just use a container class that provides the services you need.

As an old-school guy, I still harbour the secret attitude that all these layers just aren't as efficient as if I coded it myself. The whole concept of a runtime environment having to do garbage collection on my stuff because I'm not allowed to free it myself still irks me. But I've finally accepted the fact that CPU power and memory space really, really are cheap (4 cores in one CPU chip! :ouch:), and the productivity gains are enormous. I can create stuff now in less time that looks better and is more functional than ever before.

But the class libraries are huge and daunting. I've found four things that help a lot in handling with the vast amount of information you have to deal with:

1) With a decent environment, the names of the objects, properties and methods are largely self-documenting. No more "IEFBR14" ;-)

2) The better integrated development environments do a really good job of providing autocompletion suggestions. So when you type a class name or the name of a class variable, you get a list of the properties and methods it supports. This, combined with (1) above gets you most of the way there.

3) Hyperlinked help information is a lot more productive to use than manuals were. And you can cut/paste boilerplate right into your program. It took me a while to wean myself off paper, but a really large monitor helped a lot.

4) Google brings examples of almost any kind of solution to your fingertips.
 
Upvote 0 Downvote
Of course, if you have a problem with the prebuilt libraries and classes you're not forced to use them. Nothing to stop you still programming to the basic Win32 API and ignoring the work that has been done over the years to produce these libraries for you. And that's not what OOP is about - it just makes resue of existing code easier and more versatile. But you can program the Windows API in a fully OO way if you want to without using any additional frameworks.

I'd recommend that anyone interested in OOP look at Smalltalk; as for johnbsayles, have you looked at Object REXX?
 
Upvote 0 Downvote
*nix and Windows handle multi-threaded programming differently. *nix make it easy to "fork" a process into another process, Windows makes it easy to spawn a new thread, but it's still under the same process. Each model has good and bad points.

The biggest change to Win7 was the thread scheduler. The kernel team made some major changes to let Win7 scale much better. At 128 CPUs, 15% of the CPU time was spent in kernel spin locks, which meant about 19 CPU doing nothing but waiting on locks. The changes to Win7/2k8 R2 about completely negated that.

On a lowly quad core, you won't notice much, but the system will be "appear" to be faster in certain situations since the new locking reduced GUI contention a bit.

Wait until 16+ CPUs and see which OS can handle them the best.
 
Upvote 0 Downvote
OO programming

The best part about OO programming is when I make an object, that object is a "black box" to the caller.

I don't need to know what's going on at all, all I need to know is what I want it to do.

When doing multi-threaded programming, this helps a ton. I can design an object with all the thread management in a "black box". If I want to add a new task to a queue, I just make an object that creates tasks and a queue object to hold tasks. Then all I have to do is something simple like "Queue.add(Task.get());". But behind those simple calls is a very complex system of checks-and-balances that I spent a lot of time debugging.

It makes managing code easy because there's only one place to look for it.
 
Upvote 0 Downvote
Windows programs can also create separate processes quite easily.


> The best part about OO programming is when I make an object, that object is a "black box" to the caller.

The classic procedural programming paradigm can do that just as easily. The biggest benefit of OOP is inheritance and polymorphism - those capabilities are very difficult to implement in a traditional procedural language.
 
Upvote 0 Downvote


We're both right on that one, but obviously you pointed out a better reason why. Nice thing about polymorphism is I can have the same call to different child objects and I don't need to worry so much about it because most the details are hidden behind the abstract layer from the parent.

I can describe my thoughts better in code than in English.. :-|

I remember seeing a benchmark several years ago comparing Windows vs Linux and Windows could spawn threads many times faster than Linux and Linux could spawn processes many times faster than Windows.

In *nix land, if you need another connection for a web client, you just fork the processes and spawn another copy. In Windows, you create a new thread. I'm not a *nix expert and I work mostly with Windows, but based on my readings, these were the major points. Not to say these points aren't over simplified.

The benefit of threads is they're in the same protected memory which makes for very fast inter-thread communication. The benefits of processes is one doesn't take them all down making them much more stable as a whole. just pros and cons
 
Upvote 0 Downvote
Yeah, that's basically what Kewlx said. Threads are a very efficient way to run multiple execution streams, but if one thread crashes then the whole process is hooped. That's why a lot of interfaces for "plug-in" software run the plug-ins in separate processes - so that a failure of the plug-in doesn't bring the main program crashing down.

I find the concept of "fork" in *nix systems to be rather odd - the idea that you basically have a single piece of code that magically gets duplicated and then the same code has to figure out if it's the parent or the child and take the appropriate action.

I like the thread concept better, which is essentially a call to a subroutine which returns immediately while the subroutine (and anything it calls in turn) continues to execute as a parallel stream of instructions. The inherent separation between the parent code in the calling procedure and the child code in the subroutine just feels more natural to me.
 
Upvote 0 Downvote
The important point that Kewlx omitted was the performance overhead of processes compared to threads. The point about a thread failing causing the whole process to fail is valid, but this may be exactly what you want. Depending upon what the thread is doing, the whole process may depend upon it and it might be more dangerous to continue than to fail.

I think the reasoning behind the fork call is that the child inherits the complete environment of it's parent - including file handles. And sometimes you want the child to run essentially the same code as the parent, for example spawning ne HTTP listeners. But I agree that it seems an odd concept when you first come to it.
 
Upvote 0 Downvote
You must log in or register to reply here.

TRENDING THREADS

Latest posts

Moderators online

Share this page

COMPANY
RESOURCES
FOLLOW
Top Bottom