Article: Apple steals Microsoft's Multicore thunder
GCD eats Microsoft's lunch....or does it?
I wonder if he's correct in his assertion that DRM has caused code bloat in windows. If that indeed is true I certainly do not want a bunch of DRM in OS X.
Snow Leopard for the win! I hope Apple continues to keep their OS as bloat free as possible and nimble. Come to think of it i've heard about Windows 7 being faster but I haven't really heard people speak about Windows 7 performance as superlative. Vista is a dog ( my mother has a 3 core AMD system and I thought something was wrong with her computer because it was so slow) so I think that skews subjective performance.
Quote:
Originally Posted by Randall
Windows on Multicore
In that piece, I noted Microsoft was already well out in front of the multicore trend with Windows Vista, and the tuning and tweaking that went into its kernel was carried forward -- and even improved on a bit -- with Windows 7. I also noted Windows XP lacks this multicore tuning, hampering its ability to scale. In fact, if it weren't for Vista's longer kernel code path (a by-product of all that DRM-fueled code bloat), it would clean XP's clock on a dual- or quad-core system.
Windows on Multicore
In that piece, I noted Microsoft was already well out in front of the multicore trend with Windows Vista, and the tuning and tweaking that went into its kernel was carried forward -- and even improved on a bit -- with Windows 7. I also noted Windows XP lacks this multicore tuning, hampering its ability to scale. In fact, if it weren't for Vista's longer kernel code path (a by-product of all that DRM-fueled code bloat), it would clean XP's clock on a dual- or quad-core system.
I wonder if he's correct in his assertion that DRM has caused code bloat in windows. If that indeed is true I certainly do not want a bunch of DRM in OS X.
Quote:
Originally Posted by Randall
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. And before you snicker about the absurdity of discussing enterprise desktop systems with more cores than there are players on a football field (hint: that's 22 for those of you still living in your mom's basement), please note that Intel is already delivering chips with up to eight concurrent execution threads (4 cores plus hyperthreading).
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. And before you snicker about the absurdity of discussing enterprise desktop systems with more cores than there are players on a football field (hint: that's 22 for those of you still living in your mom's basement), please note that Intel is already delivering chips with up to eight concurrent execution threads (4 cores plus hyperthreading).
Snow Leopard for the win! I hope Apple continues to keep their OS as bloat free as possible and nimble. Come to think of it i've heard about Windows 7 being faster but I haven't really heard people speak about Windows 7 performance as superlative. Vista is a dog ( my mother has a 3 core AMD system and I thought something was wrong with her computer because it was so slow) so I think that skews subjective performance.
Comments
What was the point?
That column said almost nothing, but did it in a snarky way.
What was the point?
I think the crux of the article was how Apple is more adept at marketing their features. It's true. Microsoft is first with a lot of technologies but they are so inept and generating buzz. They are so hereditarily uncool they can't seen to find a way to make something sound cool and trigger the "I want it" response for many.
Microsoft certainly has an answer for every one of Apple's technologies but Apple gets maximum impact of their technology through savvy marketing and having a smaller market so they can move quicker.
Though the area that Apple should not follow is the performance sapping DRM arena. Despite the claims of many Apple takes performance seriously enough ..they may charge you an arm an a leg to get great performance but that's life.
I think the crux of the article was how Apple is more adept at marketing their features. It's true. Microsoft is first with a lot of technologies but they are so inept and generating buzz. They are so hereditarily uncool they can't seen to find a way to make something sound cool and trigger the "I want it" response for many.
Microsoft certainly has an answer for every one of Apple's technologies but Apple gets maximum impact of their technology through savvy marketing and having a smaller market so they can move quicker.
Though the area that Apple should not follow is the performance sapping DRM arena. Despite the claims of many Apple takes performance seriously enough ..they may charge you an arm an a leg to get great performance but that's life.
What a load of BS. Microsoft have a problem because what they provide requires vendors to completely re-write their software in a new language tuned for parallelism. Microsoft might be able to create 'in theory' technology that work great on the drawing board and in academia but when the customers what a quick solution - they fail to meet the requirements.
Grand Central coupled with OpenCL aren't probably the most elegant solution but they can be easily retrofitted to existing code without needing to make massive structural changes to the code, re-write massive sways in purpose build languages or migrate software over to frameworks and languages that cause vendor lockin.
What a load of BS. Microsoft have a problem because what they provide requires vendors to completely re-write their software in a new language tuned for parallelism. Microsoft might be able to create 'in theory' technology that work great on the drawing board and in academia but when the customers what a quick solution - they fail to meet the requirements.
Grand Central coupled with OpenCL aren't probably the most elegant solution but they can be easily retrofitted to existing code without needing to make massive structural changes to the code, re-write massive sways in purpose build languages or migrate software over to frameworks and languages that cause vendor lockin.
Kaiwai, you know that is certainly true. In order to use OpenCL like features I believe you have to use Direct X and Microsoft's new Compute shader features. Sometimes it's easy to forget that OpenGL and OpenCL are not tied to a single platform.
It's kind of funny because I hear people drone on about how Apple = proprietary to the point where they assume. How many times have I heard people state that AAC is an Apple codec? Too many.
Grand Central Dispatch is another technology that is misunderstood. Over on Mac Achaia there was a GCD thread that descended into Nerd Rage and a burgeoning developer flame war. I think the problem is when Apple says something is revolutionary they don't always mean that it's new technology. With GCD I do not believe Apple is saying that they've invented a new way of dealing with concurrent threads at a hardware level. I believe their revolution is dealing with threads from a developer level and making it as trivial as possible and that is in fact revolutionary to someone who really doesn't want to micromanage their threading.
I think the crux of the article was how Apple is more adept at marketing their features. It's true. Microsoft is first with a lot of technologies but they are so inept and generating buzz. They are so hereditarily uncool they can't seen to find a way to make something sound cool and trigger the "I want it" response for many.
Microsoft certainly has an answer for every one of Apple's technologies but Apple gets maximum impact of their technology through savvy marketing and having a smaller market so they can move quicker.
Though the area that Apple should not follow is the performance sapping DRM arena. Despite the claims of many Apple takes performance seriously enough ..they may charge you an arm an a leg to get great performance but that's life.
The technical part, I don't know much about. But I certainly get the corporate culture and marketing approach part. What I don't see is what this columnist is trying to say about either one. It seems he's trying to convince us that Microsoft has the better technical approach, which Apple papers over by giving their technologies flashier names. If that's the case, I guess I don't see the argument as having been made. For one I don't accept that Apple's approach to backups are inferior, if the point of a backup technology is to make it easy to use.
Trying to compare a system-hosed recovery feature with a full data backup system is one major faux pas, but then trying to compare deep in the kernel optimizations with a developer's application level API is a pant's down around the ankles screw-up.
These aren't apples and oranges comparisons, they are like orange to orange-tree comparisons, they make no sense whatsoever in the context they were put forth.
I believe their revolution is dealing with threads from a developer level and making it as trivial as possible and that is in fact revolutionary to someone who really doesn't want to micromanage their threading.
BING BING BING. Precisely. Currently, managing threads is an absolute pain and adds huge amounts of source code bloat -- especially in complex applications that have enough source bloat to contend with as is. That's why so many developers don't bother; there's not enough performance increase. At least, not enough to make up for the additional maintenance required to keep bugs out of an app that just became 25% more complex to write.
THAT is why Grand Central Dispatch is revolutionary; it moves 70-80% of thread management off your plate and into a standard API that implements best practices. So you don't have to. Which means you can tap the extra performance without running the risk of introducing tons of new bugs into your app.
BING BING BING. Precisely. Currently, managing threads is an absolute pain and adds huge amounts of source code bloat -- especially in complex applications that have enough source bloat to contend with as is. That's why so many developers don't bother; there's not enough performance increase. At least, not enough to make up for the additional maintenance required to keep bugs out of an app that just became 25% more complex to write.
THAT is why Grand Central Dispatch is revolutionary; it moves 70-80% of thread management off your plate and into a standard API that implements best practices. So you don't have to. Which means you can tap the extra performance without running the risk of introducing tons of new bugs into your app.
This thread is hilarious
http://www.reddit.com/search?q=Grand+Central
My favorite quote:
Yeah, I love how folks come on and always say, hey, you could already do this by <insert lower level implementation details here>. Well, no shit. Brilliant. And you could always make a fire with a flint and rock, too, dumbass.
As always it's not just the technology that is key or innovative but also the implementation of technology lest we all want to go back to making our fires with two rocks and some kindling.
What a load of BS. Microsoft have a problem because what they provide requires vendors to completely re-write their software in a new language tuned for parallelism. Microsoft might be able to create 'in theory' technology that work great on the drawing board and in academia but when the customers what a quick solution - they fail to meet the requirements.
Grand Central coupled with OpenCL aren't probably the most elegant solution but they can be easily retrofitted to existing code without needing to make massive structural changes to the code, re-write massive sways in purpose build languages or migrate software over to frameworks and languages that cause vendor lockin.
You don't know your head from your ass about GCD and OpenCL. Next I'm going to read you're a seasoned genius at OpenGL3.x as well and what a pain it is to use.
OpenCL guarantees no vendor lock-in. OpenGL and OpenCL are on every platform. Hardware lock-ins come in with the use of CUDA and Streams, to their respective company GPUs--another reason why OpenCL was so quickly embraced and ratified to allow for third parties to implement and then from that foundation build extensions to draw business to their tools.
You don't know your head from your ass about GCD and OpenCL. Next I'm going to read you're a seasoned genius at OpenGL3.x as well and what a pain it is to use.
OpenCL guarantees no vendor lock-in. OpenGL and OpenCL are on every platform. Hardware lock-ins come in with the use of CUDA and Streams, to their respective company GPUs--another reason why OpenCL was so quickly embraced and ratified to allow for third parties to implement and then from that foundation build extensions to draw business to their tools.
Where did I state that OpenCL and OpenGL results in vendor lock in - come on, show me exactly in the post where I said utilisation of it will result in lock in.
Take a reading class because the vendor lock in I was referring to was what Microsoft was offering as an alternative to OpenGL/OpenCL and GCD in the form of frameworks and languages that were Windows bound and not multiplatform.
Kaiwai, you know that is certainly true. In order to use OpenCL like features I believe you have to use Direct X and Microsoft's new Compute shader features. Sometimes it's easy to forget that OpenGL and OpenCL are not tied to a single platform.
It's kind of funny because I hear people drone on about how Apple = proprietary to the point where they assume. How many times have I heard people state that AAC is an Apple codec? Too many.
Grand Central Dispatch is another technology that is misunderstood. Over on Mac Achaia there was a GCD thread that descended into Nerd Rage and a burgeoning developer flame war. I think the problem is when Apple says something is revolutionary they don't always mean that it's new technology. With GCD I do not believe Apple is saying that they've invented a new way of dealing with concurrent threads at a hardware level. I believe their revolution is dealing with threads from a developer level and making it as trivial as possible and that is in fact revolutionary to someone who really doesn't want to micromanage their threading.
Where did I state that OpenCL or OpenGL were proprietary?
Where did I state that OpenCL or OpenGL were proprietary?
You, my friend, are certainly not "people" though I have heard interesting discussion out and about on this subject from others.
Many people confuse defacto standard with "open" . Most recently the brouhaha about Mini DisplayPort (which the connector as indeed proprietary until it was ratified in version 1.2) .
You, my friend, are certainly not "people" though I have heard interesting discussion out and about on this subject from others.
Many people confuse defacto standard with "open" . Most recently the brouhaha about Mini DisplayPort (which the connector as indeed proprietary until it was ratified in version 1.2) .
Depends on how you define open; java isn't 'open' by definition of a standards body like ECMA but the development is open and one can implement it based on the specifications ratified by the working group. Open also doesn't mean, "does not have barriers to entry", AAC being a full documented CODEC by riddled from top to bottom with patents.
For me, as long as one can implement something given that the full specifications are open to the public and maintained by the said organisation, one could argue that a given thing is open. With that being said, open has be abused in the past - where vendors throw open on the front of their product in a vain attempt of winning geek cred.
Mac OS X kernel is good at multitasking as it is. GCD is not about this. Apple provides GCD support on different levels, from the very low level with a C-based API all the way up to the highest level. Some of the high level APIs use GCD explicitly, others do not. So you can have 10.5-compatible apps which use GCD when available.
Besides providing outstanding features for developers, including dead-simple APIs (especially the high-level ones) and developer/debugging tolls which, according to a developer I talked with, are remarkable for a new technology, Apple is implementing GCD support all over the place in the OS and their Frameworks. This will give some performance boost even for the applications which are totally unaware of GCD (built for pre-SL versions, that is).
Although GCD uses threads to do it's job, it is not about simplifying thread setup. When using GCD developers don't need to think about threads at all. They need to think how to break the task into subtasks, and set the dependancies if needed. There is no new language, just a single new function-like syntax construct called 'block'. The most significant difference between managing threads explicitly and using GCD is that GCD is dynamic. That is, the number of threads to be used is not hardcoded and depends on many factors in a complicated way. GCD takes into account not only the processor configuration the app currently runs on, but also the current system load. For example, the same code could run on different number of threads depending on other activity on the system, e.g. other apps running at the same time. Managing this manually in a highly effective manner is close to impossible and draws the developer's attention from the task that needs to be done to the hardware-specific tricks which could easily fail to scale effectively with the future processor implementations.
It will take some time until Apple takes full advantage of GCD throughout all of the frameworks and Apple's apps, but it is probably the most significant change in Mac OS since it's release. The modular and hierarchical structure of Apple's code base allows for fast progress in terms of GCD adoption. Even if Microsoft gets a GCD analog in place, their fragmented code and loosely connected technologies scattered all around the OS will make it difficult to follow Apple's pace of development.
I read the pdf and while it's short on technical details it certainly points to the main "brain" of GCD doing all the heavy lifting and task management and thus this "brain" and its evolution is key to future performance.
I agree with you shadow that Microsoft has technologies that are cool in principal but they don't seem quite as adept and connecting these disparate features into a cohesive system. They are improving albeit a bit slower than Apple.
What I need now is a good demo of what OpenCL can do. I still feel like this is a dark horse technology.
What I need now is a good demo of what OpenCL can do. I still feel like this is a dark horse technology.
My #1 wish is to bring OpenCL's extra math capabilities to bear on apps like HandBrake, and with PhotoShop plug-ins. There may be some elements of OpenCL in other avenues, but I think 90%+ of the software we will see at first will be in graphics.
The problem is MS' solutions are oftenly far too much flexible, complex and buggy.
Apple is excellent at bringing up ideas - sometimes new and surprising, sometimes just sufficiently forgotten - then wrapping ideas in amazing user interface, optimizing the implementation for one single platform and brushing them up.
Looking at what has leaked on GCD, it should now be thought of as containing essentially following ameliorations
- message/listener-based thread dispatching, enveloped in easy-to-use APIs; is this new? not much for RTOS and low-level process dispatching in general; quite so for high-level task management, I dare say,
- improvements (maybe, some redesign, quite a paradigm shift) in resource management; Apple is now preaching "extremely expansive short-term allocation, instant yielding" approach; it appears to be not negligible at all, they seem to have achieved considerable ramp up by only this...
Then Apple parallelized carefully their applications. It's now the challenge for other software vendors. Personally, I don't expect all third parties to find solutions, being sophisticated enough, right out of here....