[Fyre4ce]

Can someone please explain to me the differences between the ways Windows 2000 and Mac OS X handle multiprocessing? Someone told me that Windows is better - I find that hard to believe.

------------------
Fyre4ce

"I need a vacation." - Terminator robot

[This message has been edited by Fyre4ce (edited 02-26-2001).]

[Gametes]

I am not a technical expert, but...

Windows: proprietary, hidden
Mach (the kernel for X): industry-tested academicly-developed open-source

windows: monolithic kernel (archaic, overkill, crash-prone by intrinsic nature of massiveness and complexity)
mach: microkernel (nimble, modern, minimal design)

[Scott_H]

I don't know enough about either to say which is better. But I did some hunting via Google and found one interesting thing. There wasn't a lot of info out there though.

Mac OS X and Win2k have the same "buzz words". That is the both support "full symmetric multiprocessing", SMP. BUT Windows has a 4 tier pricing structure for that. The basic gets you two CPUs and the next level 4 and ... up to I think 32. You have to pay more and more to get that added functionality. But what are you paying for. They coded in for 32 so why not give that to all users?
http://www.elementkjournals.com/w2k/...es/w2k99b2.htm


Contrast that with Apple. We know two will be supported. If not more (assuming we get more CPUs) then some Darwin open source guy would hack a new kernel for OS X to support the max # of processors. So there's no way Apple could price it the same way as M$.

Plus I think I read that the mach kernel can do 64 but don't quote me on it.

[JB72]

I suppose it depends too on what Darwin SMP will give for "free" to all apps vs. ones with specific MP support and/or multi-threading. This is one issue that won't be resolved for a while, although I think OS X has inherit advantages. We'll just have to see how well Apple and 3rd party developers will take advantage of it.


------------------
JB71.338x

Dock Pervert? You bet your ascot I am!

[bleen]

I remember hearing somewhere that Apple currently has UMA-2 to support upto 4 processors.

As far as the number of processors that The Mach Kernal could withstand i don't know... I don't know if this is related to the article, but I rember reading someone with MacOS X Server 1.0 (Rhapsody) had a lab of computers (about 30) divide up a process and fully take advantage of the processors in the lab.

[Gavin]

I read something technical about this a while ago, someone correct me if I have this wrong.

With Mach each thread is independent and can run on any processor so something like photoshop can run a single task across several processors concurrently. The trade off is that it has to keep all the parts in synch. It tries to keep all the processors equally busy.

Windows breaks things up into larger pieces. it will fill up one processor then start a new thread on the next processor. There are less pieces to keep track of but you could have part of one processor idle.

So Mach has a little more overhead but will make better use of available cycles. Windows is faster but doesn't use the hardware's full potential.

Depending on the type of job running each could have the advantage. The processor and even the motherboard architecture influence things too.

<disclaimer type=snippy>
That's a pretty rough summary of something I read a year ago, so eat me.
</disclaimer>

[sprynmr]

The Mach Kernal supports up to 64 processors, according to an Apple rep.

[ratfink]

Originally posted by sprynmr:
The Mach Kernal supports up to 64 processors, according to an Apple rep.

While this may be true, the law of diminishing returns kicks in, and even with the best bus and memory subsystems, anything beyond 8 is problematic.

I'm not sure of the SMP implementations of either, though I remeber NT4 had bugs keeping one task to a processor. (Not a requirement, but if you have few other compute intensive tasks it helps because of the cache.) I'm pretty sure that's fixed by now.

Assuming both have moderately equivalent SMP kernals, you will want to look at all the applications and the API's they use. The fundamental unit to a SMP kernal is the thread or process (depending on the OS, they are different.*) because these cant be split between processors. In other words, if the app's render loop only uses one thread, throwing multiple processors at it will have minimal impact. The most that will happen is the other CPU's will take up the any other process.

This is the same for API's. I would hope carbon and cocoa spawn different threads per app, but that's not a given (I havent looked). It's also nice if there are multiple threads within an app.

One of the reasons BeOS is so fast and responsive, is their engineers knew that SMP would would be stunted unless everything is "pervasively multithreaded." For example, if a programmer does nothing but create a window, there is already two threads, the app thread, and the window thread. This is the kind of stuff that needs to happen in OSX as well.

* Does anyone know is MACH/OSX supports true threads?
Process = Unit of execution that has its own memory space
Thread = unit of execution that belongs to a team, sharing memory

Geof

------------------
"I can see the future, and it's a place about seventy miles east of here."

[dhobbit]

OS X supports several different Threading models. MACH threads which are true threads, PThreads which simple get mapped on to MACH threads, BSD/Unix processes, and Carbon/OS9 threads which are non-preemptive.

Basically a Cocoa apps get access to any of the threading models. Carbon apps have to use the carbon threads which means the threads are not preempted. With mach and pthreads each thread is preemptable which provides much better smp support.

Originally posted by ratfink:
* Does anyone know is MACH/OSX supports true threads?
Process = Unit of execution that has its own memory space
Thread = unit of execution that belongs to a team, sharing memory

Geof

[gorgonzola]

Java-Cocoa apps get SMP support automatically.

I thought that was cool.

And yeah, Mach does up to 64, and even if anything beyond 8 is problematic, do you ever see us getting more than 8? If even that many?

Darwin hacks won't be necessary. Apple will just reconfigure Mac OS X to recognize more processors. All the gut-level support is there, all we need is stupid Motorola.

------------------
the oddball newsletter
------------------
it's only after you lose everything that you're free to do anything

[Fyre4ce]

So is it possible to say that one OS is "better" than the other at handling multiple CPU's? Some say no, others were silent on the topic.

------------------
Fyre4ce

"I need a vacation." - Terminator robot

[RodriCO2000]

To who ever said that Carbon/Classic is not Pre-empted. is wrong....

Classic layer IS NOT PRE-empted.... Carbon/Cocoa/Java IS PREEMPTED....

Steve has said it tons of times that in order to get Protected memory, Preemptive Multitasking, you need to get your Apps Carbonized, therefore carbon DOES get preempted....

With Mach each thread is independent and can run on any processor so something like photoshop can run a single task across several processors concurrently. The trade off is that it has to keep all the parts in synch. It tries to keep all the processors equally busy.

Windows breaks things up into larger pieces. it will fill up one processor then start a new thread on the next processor. There are less pieces to keep track of but you could have part of one processor idle.

This is not accurate. At any given time, thread/cpu load is evenly distributed between all processors on a system. The latest versions of Windows based on the NT core (Windows 2000, Windows XP) are heavily multi-threaded, far more so than OS X, but possibly less so than BeOS. Upon boot, Windows 2000 Professional has about 250 threads loaded; Windows XP has about 300 threads loaded on bootup. Compare that to 70-100 threads loaded by OSX on boot up. The apps and applets bundled with Windows are also far more extensively multithreaded on Windows than the bundled OSX apps and utilities; consider that this single IE6.0 browser window consists with this simple forum page consumes 9 threads; a single browser window at the more-complex www.msnbc.com consumes 20 threads; a single instance of Outlook Express with no extra windows open consists of 11 threads.

[To see running threads, load Task Manager, select View->Columns, and check Thread Count.]

At this time, I definitely think Windows2000/XP has the advantage for multiprocessing, primarily because all widely used Windows applications are written to utilize extensive multithreading. Meanwhile, most classic apps utilize minimal multithreading, if any at all, judging from the OSX process manager. Once more apps are written and updated to Carbon, the platforms should become more evenly balanced when it comes to the use of multiple cpus.

Ken

[This message has been edited by Ken_F (edited 03-02-2001).]

[gregomni]

Originally posted by Ken_F:
At this time, I definitely think Windows2000/XP has the advantage for multiprocessing, primarily because all widely used Windows applications are written to utilize extensive multithreading.

This isn't necessarily true. As long as you have at least two threads, you can potentially fully utilize a dual processor machine. Having a couple hundred threads doesn't really mean anything unless you have more than that many processors. If not, then you really have to start talking about what those threads are doing, why and when the OS is switching among them, and how efficiently it does so.

(Note that I really have no idea whether Win2000 or OS X handles multiprocessing better, I'm just saying that thread counts aren't good evidence one way or the other. I suspect that you'll have to get a more exact definition of "handles multiprocessing" and "better" before anyone can really answer this question.)

-Greg

[dhobbit]

Yes Carbon/Cocoa/Java apps are all preemptively multitasked. What I meant is the threads inside a carbon app are not preempted. It's similar to Classic. Classic the application/environment gets all the advantages of OS X protected memory, multitasking, etc. But photoshop and word running in classic don't.

Originally posted by RodriCO2000:
To who ever said that Carbon/Classic is not Pre-empted. is wrong....

Classic layer IS NOT PRE-empted.... Carbon/Cocoa/Java IS PREEMPTED....

Steve has said it tons of times that in order to get Protected memory, Preemptive Multitasking, you need to get your Apps Carbonized, therefore carbon DOES get preempted....

[Big Mac]

Originally posted by dhobbit:
Yes Carbon/Cocoa/Java apps are all preemptively multitasked. What I meant is the threads inside a carbon app are not preempted. It's similar to Classic. Classic the application/environment gets all the advantages of OS X protected memory, multitasking, etc. But photoshop and word running in classic don't.

AFAIK, True OS X Carbon applications (compiled to Mach-0) can call real live preemptive threads through MP Services. There are (or were) some oustanding issues about some portions of Carbon not being truly reentrant; some of those issues should be resolved for GM. The threads that Carbon apps call through MP Services are just coated PosixThreads. However, applications must be Mach-0 (which means a separate binary is required for them to run in Classic), and they must call MP Services rather than ThreadManager. (Calling ThreadManager creates a cooperative thread.)

That's my understanding, anyway.

[tr909]

multiprocessing: i just wrote an topic called:
Might be (the|a) REAL power for MacOS-X....
at: http://forums.macnn.com/cgi-bin/Forum3/HTML/003146.html

take a peek at:
http://www.totalimpact.com/G3_MP.html
http://www.totalimpact.com/powerbox.html