You could take advantage of multi-core processors back in Windows XP, Windows Vista made it easier; obviously Windows 7 will too. You didn't need some stupid library to do it either; it was dependent on which development tool you were using; but the majority provide a method to thread out to another core or processor without any real difficulty. Apple has been playing catchup for sometime now; first with 64-bit systems and they still arent fully 64-bit, and now with multicore cpu support, also with gpu being used as cpu.
I'm actually being serious, dude. I'm asking this question because I'm planning to buy a computer within a few months and wanted to get more information about the performance benefits/downsides of both OSes. I may end up either getting a notebook/netbook and turning it into a hackintosh or in the less probable scenario, getting a Mac.
I can't begin to tell you how many fails you wrote in that short paragraph. Grand Central Dispatch is to HELP developers write software that can take advantage of multicores, do you know how hard and annoying it is to do it, so apple created this to make the process much easier. Mac OS X has supported multi-core since 2002.
This article has some interesting links about performance comparisons between xp/vista/7 for multicore tasks
"As it stands, you'll need to reach into the 20- to 30-core range before the multicore efficiencies of the Vista/Windows 7 kernel finally allow the OS to overtake Windows XP in terms of raw performance."
OS X has supported multiple cores for ages. Grand Central isn't adding support for writing programs that run on multiple cores, it's making it easy to support running on multiple cores. Rather that try to explain Grand Central, I'll just point everybody to the excellent Ars Technica article.
Lee - I'm a software developer. It's not hard at all to write multi-core apps, most devs are just lazy and don't bother. You really have no idea what you are talking about and just rehash what you read; that its supposedly super difficult to write multicore apps. It simply isnt true.
@PG & Lee Jesus you people are rude. If you're going to bash each other with "facts", perhaps try backing your information up with sources first. Don't follow in our past president's footsteps.
@PG I dont believe that you write ANYTHING. For any developer to be nonchalant about writing useful multi threaded apps means that he has no effing idea what he is talking about. If you are a developer you would do well to read that arstechnica.com link that was provided earlier in this thread.
What GCD does in essence is add a library that allows you easily take a serialized process and parallelize it with just a few lines of code. GCD takes the serialized process and works through it assigning the different processes to a que that then feeds these processes to cores as they are available.
@Pengiun Yes but the issue you run into and what makes GCD so unique is you dont have to know how many cores are being used by other processes. Sure writing a piece of multi threaded software that will the THE ONLY THING running on the system could be easy. What GCD gives you is a system where it doesnt matter what else is going on because your program isnt going to launch and immediately take over all cores for its process, its going to use whats available to the system at the time and doesnt have to assume that nothing else will be running.
@Tsing Tao: It was as easy before to write MT (multi-threaded applications). Read Ars review again, because you got it all wrong. The only and easy example in the article was how to use GCD to tell Mac OS X that application is actually doing something, not simply hanging. But example was half assed too - there where no any progress indication of a sort. Because that would have turned nice simple example into usual turd of code.
GCD from my prospective - system developer speaking - is a trivial utility. On one side for developers - a YATPL (yet another thread pool library). On another side for an end user: no matter how many GCD-using applications they would start, the applications will not grind system to halt. Because what makes GCD really different from your mom's YATPL, is the system wide scheduling of jobs: it will never attempt to start more threads than free cores/CPUs your Mac has.
Developers do not need to write YATPL again. End users get most of their mega core CPUs. Everybody's happy.
Grand Central Dispatch's primary purpose is to allow smaller programs to properly use multi-core systems without hogging resources, therefore, improving application performance yes, but also allowing multiple applications to work without using wasted resources, potentially, allowing significant gains in mutlitasking performance, this is where the Darwin kernel integration begins to work.
FWIW, regular desktop apps will not benefit from "64-bit" at all, at least in the foreseeable future (when their RAM requirements get ridiculous).
As far as Windows is concerned, Microsoft's Parallel Extensions are nearly identical, and they will be released with .NET 4.0 early next year.
As it stands, in order to use any of these technologies, the developers have to get their codebase on current APIs: Win32>.NET/WPF Carbon>Cocoa
tsing tao - what you are describing is a dumbed down system of multicore programming. Why would I want to tell the system to share resources across all cores when I can control it myself. You can EASILY thread out to another core (finding how many cores installed is a couple lines of code), then have your code execute on the core you want; if you need to use another core then by all means execute more code on a different core. It's simply a couple lines of code to make a single core application become a multicore, mulithreaded app; debugging will be harder but it is not as difficult as most articles are trying to make it appear. The way you have described it is the system automatically decides which cores to use; this is already the case in most operating systems and when you have the OS decide it is never as optimized as when you can choose when to thread out and when not to. Why would I want my code to execute on 4 codes all using 25% of each core when I can have my code execute on the 4th core all on it's own using the entire core and getting the job done faster. I'm not interested in apples grand central method; I've used xcode and it is complete crap, I don't imagine anything apple is adding into it is going to make it any better. The IDE is so backwards you wonder why people even bother developing with it.
Now that we've thrown 'em off the trail, use the form below to get in touch with the people at Engadget. Please fill in all of the required fields because they're required.
So...quick question.
Does Windows 7 also have the level of multicore support that Grand Central offers with Snow Leopard???
I can't tell if you're being serious or being sarcastic...
Maybe a few years ago it did.
You could take advantage of multi-core processors back in Windows XP, Windows Vista made it easier; obviously Windows 7 will too. You didn't need some stupid library to do it either; it was dependent on which development tool you were using; but the majority provide a method to thread out to another core or processor without any real difficulty. Apple has been playing catchup for sometime now; first with 64-bit systems and they still arent fully 64-bit, and now with multicore cpu support, also with gpu being used as cpu.
Jon Graft
I'm actually being serious, dude. I'm asking this question because I'm planning to buy a computer within a few months and wanted to get more information about the performance benefits/downsides of both OSes. I may end up either getting a notebook/netbook and turning it into a hackintosh or in the less probable scenario, getting a Mac.
Once again, no sarcasm intended.
uhmmm, lets see, considering grand central dispatch is unix based, no.
PG, thanks for the informative reply.
@PG
I can't begin to tell you how many fails you wrote in that short paragraph. Grand Central Dispatch is to HELP developers write software that can take advantage of multicores, do you know how hard and annoying it is to do it, so apple created this to make the process much easier. Mac OS X has supported multi-core since 2002.
Please, jump off a very big mountain.
@AustinHwang
This article has some interesting links about performance comparisons between xp/vista/7 for multicore tasks
"As it stands, you'll need to reach into the 20- to 30-core range before the multicore efficiencies of the Vista/Windows 7 kernel finally allow the OS to overtake Windows XP in terms of raw performance."
http://www.infoworld.com/d/windows/apple-steals-microsofts-multicore-thunder-grand-central-594
OS X has supported multiple cores for ages. Grand Central isn't adding support for writing programs that run on multiple cores, it's making it easy to support running on multiple cores. Rather that try to explain Grand Central, I'll just point everybody to the excellent Ars Technica article.
http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars
Start on page 8 for the complete rundown of what Grand Central means.
Lee - I'm a software developer. It's not hard at all to write multi-core apps, most devs are just lazy and don't bother. You really have no idea what you are talking about and just rehash what you read; that its supposedly super difficult to write multicore apps. It simply isnt true.
@PG & Lee
Jesus you people are rude.
If you're going to bash each other with "facts", perhaps try backing your information up with sources first.
Don't follow in our past president's footsteps.
I'm a .net software developer and multi-core programming is extremely easy in .net. Especially with the new .net thread debugger in vs2010.
@PG I dont believe that you write ANYTHING. For any developer to be nonchalant about writing useful multi threaded apps means that he has no effing idea what he is talking about. If you are a developer you would do well to read that arstechnica.com link that was provided earlier in this thread.
What GCD does in essence is add a library that allows you easily take a serialized process and parallelize it with just a few lines of code. GCD takes the serialized process and works through it assigning the different processes to a que that then feeds these processes to cores as they are available.
... it was extremely easy to do threading, not as easy to do it right.
@Pengiun Yes but the issue you run into and what makes GCD so unique is you dont have to know how many cores are being used by other processes. Sure writing a piece of multi threaded software that will the THE ONLY THING running on the system could be easy. What GCD gives you is a system where it doesnt matter what else is going on because your program isnt going to launch and immediately take over all cores for its process, its going to use whats available to the system at the time and doesnt have to assume that nothing else will be running.
@Tsing Tao: It was as easy before to write MT (multi-threaded applications). Read Ars review again, because you got it all wrong. The only and easy example in the article was how to use GCD to tell Mac OS X that application is actually doing something, not simply hanging. But example was half assed too - there where no any progress indication of a sort. Because that would have turned nice simple example into usual turd of code.
GCD from my prospective - system developer speaking - is a trivial utility. On one side for developers - a YATPL (yet another thread pool library). On another side for an end user: no matter how many GCD-using applications they would start, the applications will not grind system to halt. Because what makes GCD really different from your mom's YATPL, is the system wide scheduling of jobs: it will never attempt to start more threads than free cores/CPUs your Mac has.
Developers do not need to write YATPL again. End users get most of their mega core CPUs. Everybody's happy.
Grand Central Dispatch's primary purpose is to allow smaller programs to properly use multi-core systems without hogging resources, therefore, improving application performance yes, but also allowing multiple applications to work without using wasted resources, potentially, allowing significant gains in mutlitasking performance, this is where the Darwin kernel integration begins to work.
FWIW, regular desktop apps will not benefit from "64-bit" at all, at least in the foreseeable future (when their RAM requirements get ridiculous).
As far as Windows is concerned, Microsoft's Parallel Extensions are nearly identical, and they will be released with .NET 4.0 early next year.
As it stands, in order to use any of these technologies, the developers have to get their codebase on current APIs:
Win32>.NET/WPF
Carbon>Cocoa
tsing tao - what you are describing is a dumbed down system of multicore programming. Why would I want to tell the system to share resources across all cores when I can control it myself. You can EASILY thread out to another core (finding how many cores installed is a couple lines of code), then have your code execute on the core you want; if you need to use another core then by all means execute more code on a different core. It's simply a couple lines of code to make a single core application become a multicore, mulithreaded app; debugging will be harder but it is not as difficult as most articles are trying to make it appear. The way you have described it is the system automatically decides which cores to use; this is already the case in most operating systems and when you have the OS decide it is never as optimized as when you can choose when to thread out and when not to. Why would I want my code to execute on 4 codes all using 25% of each core when I can have my code execute on the 4th core all on it's own using the entire core and getting the job done faster. I'm not interested in apples grand central method; I've used xcode and it is complete crap, I don't imagine anything apple is adding into it is going to make it any better. The IDE is so backwards you wonder why people even bother developing with it.
No. Programs need to be set up for threading, where as GCD automatically distributes the load most efficiently over all available cores.