The question is... how is this different to Intel's Thread Building Bocks, or OpenMP, both of which are better supported and more widely available to non-Mac developers.
If I'm not mistaken the technologies are for an application.
GCD can coordinate all applications running on the same system.
I guess having their own implemntation (for the mac) makes sense, as they can integrate it throughout the OS. I don't know anything about GCD either, but could it be used in Linux to make that a more parallel-friendly OS with less developer effort, and more standardisation of parallel execution?
Theoretically yes.
Apple here is in unique position.
Most software developers care solely about their own application. Old example from the desktop. On Windows I have 7-zip archiver installed. I have dual core CPU and this 7-zip is configured to use the 2 cores. From prospective of software developers it's all what they can do: let users tell how much cores/CPUs can be used. But I also have a video encoding application installed - and also configured to use two cores. If I try to run them both in parallel, that would cause erroneous amount of context switching harming performance of both the tasks. In worst case that might make my desktop completely unresponsive. As user I'm also lazy to reconfigure every time applications how many CPUs they should use.
Apple itself now produces number of applications which can utilize multiple CPUs (iTunes audio conversion, iMovie/QuickTime/FC video conversion, etc) and obviously they run into the problem that when applications left on their own to decide how much CPU resources they should use, system would overload leading to all the effects. Requiring user to reconfigure all the applications all the time is also kind of stupid.
Since Apple is in control of the OS and applications - and their own software might suffer from the problem, they went out and implemented the solution: system-wide batch queue with a thread pool. They are still threads - local to the process - but they are scheduled on system-wide basis. You do not need to configure applications how many CPUs they should use - nor applications have to think about: they simply put tasks (to be threads) of the queue of GCD.
I'm using the 'batch queue' term because this is the closest what exists now. Though classical UNIX batch queues are different in nature: those are processes and they are executed at some unknown point of time. GCD is real-time in its nature and its threads run immediately, unlike traditional batch queues which wait for system to be idle.
~200 lines of code required to implement thread pool for an application is hardly an effort. Three-four hours of coding at most.
Configuring bunch of applications, each with a thread pool, to utilize system optimally to extract maximum performance out of it - is an effort which has to take every time one deploys the software anew. And in my experience people spend considerable time (weeks) to configure thread pools properly: avoid overload and maximize performance.
I've seen that many times before. I'm also seeing the same with product sold by my employers: we have at least four applications with thread pools. Coming up for every deployment with the suitable configuration (which depends on business case of customer) is a time consuming process.
Apple has a long tradition to make things its own way, not always in the cleanest way under the hood.
I grew out of being purist and now I can reply you: to keep the sh1t in one place.
Otherwise you can go Linux way: keep tech under the hood clean, but as collateral force every program to swallow some of the sh1t and pass it on to end user.
And we all know that in the end the approach doesn't work. Struggles of Linux on desktop is the best evidence of that.
It's an old tech. But it's different this time around.
Old thread pools are per process. This is a thread pool for the whole system. And that's new.
IOW, with GCD you do not need to configure every application how much threads it should start. Applications do not need to bother with it anymore too: they simply queue batch tasks as they arrive and GCD guarantees that they will be executed. Without overloading system.
Shortly, GCD is a system-wide replacement for old per-application thread pool configuration. Makes applications simpler and also doesn't force end-user to understand all oddities of multi-programming to get most out of their boxes.
Having done some multiprogramming, I have to tell that it is really an end-user technology. Less a tool for developer.
One of the biggest problems on multi-CPU/core systems if to split appropriately CPUs between applications. That requires quite amount of testing and benchmarking. Then you simply configure max number of threads each application allowed to use. Obviously changing anything at later time when problem was found requires some effort too.
With GDC that all now is much easier. Available CPU resources are presented to applications in a fashion of real-time batch queue. One doesn't need to configure thread pools per application anymore.
That was never a problem from software development point of view - we just provide the 'max threads' parameter. But that was always problem from user/operator point of view who has to actually fill in the parameter.
To me it looked something like a nameless function, which shares same stack with the functions where it is defined.
Even if it's a dumb nameless function, it could be already very useful. E.g. perl's 'sort {$a op $b} @list' can be more or less directly translated to C's 'qsort(.... ^(const void *a, const void *b){ return a op b; } )'. At least I hope so.
Single Oracle license can buy you a lot of OS licenses - along with servers for the change.
Oracle is as evil as MS. If not more: their involvement with Linux is what in greater part makes up for the server bias in development as Linux became in past years the top Oracle platform. IOW, they one of the largest supporters of ruining Linux on desktop, as fat chunk of Red Hat and Novell profits comes from supporting and selling certified Oracle platform.
Mathematically that would make sense. Ranges are likely [1, 2) and [2, 3).
But note that graph isn't about how much memory you have installed, but how much physical memory Windows is reporting. Without accessing BIOS (Administrator rights required) it's impossible to know how much physical RAM you do have.
That's quite interesting. The graph shows that about 25% of systems runs on AMD CPUs. Frankly (though I claim to be an AMD enthusiast) I thought that AMD now at 10-15% max.
Apparently, thanks to the media hype around high-end toys, low-end gets neglected. And low-end is a place were AMD is very strong. That's only way I can explain the 25% user share of AMD....
Companies are different. Their focus is different. Apple sells its product directly - thus site is optimized with end users in mind. MS orients itself as a partner company - thus its web site is a kind of source of bullets points for PowerPoint presentations which can be reused by its partners when selling MS products. Both serve their purpose.
Sometimes they are quite comprehensive BTW as they are used further for internal research. But only sometimes.
As for RFCs, in my experience few students actually read them. TCP implementation is scattered over many STDs/RFCs and gathering them together is a pain. Most prefer to cheat using some TCP book.
What you say is a valid concern. But my point was different: no way there is a technical reason for one year delay for the fix in so well known piece of software as the TCP stack. (Which in MS's case is a verbatim copy of FreeBSD's stack.)
True. (Wouldn't lie - I personally implemented in past only about 50% of TCP.)
Nevertheless, it's pretty well known fact that MS took their implementation of TCP from BSD which apparently doesn't have the problem. More than that they took fresh implementation from FreeBSD relatively recently for 2003 Server.
Cisco IIRC also uses FreeBSD TCP implementation.
In other words, I still fail to see the problem: likewise they could have lifted the solution for the problem from the very same source where from they took their TCP implementation originally.
If I'm not mistaken, the problem was fixed last October in Linux. I doubt it took BSD folks longer.
Yes, absolutely. TCP is so complicated that only few engineers know precisely how it works and can patch the flaw. And probably it also lacks test tools. OMG. I'm so happy that it took them only a year.
/sarcams
WTF. Get real. TCP is studied and implemented as a lab assignment now in pretty much every university by all who in any way relate to network programming. Test tools and analyzers are abundant (both hardware and software) and can simulate pretty much any kind of load. There are even commercial companies selling (at size of MS and Cisco) for pennies ready suits of test cases for TCP.
Longest way: rent an analyzer (2-4 weeks longest for it to get shipped to your office), buy a suit of test cases (0 days), run the tests (1-2 days, normally less), patch the hole (1-2 days), rerun the tests (1-2 days). IOW, if they really cared, they could have released a patch within 2-3 weeks. Heck, I have seen people implementing basic TCP quicker than that.
This is simply another display of arrogance on part of big vendors. Nothing new here. Move on.
I'd argue that the amount of time lost by having to right-click and choose "Preview" (which should be the 2nd choice, the first being "Open") is worth it for the added benefit of always knowing what the file will open with.
And users know how file will open. If I created file yesterday in Photoshop, I can be sure that reopening it today would also start Photoshop, not Preview.
OS doesn't know why file is there nor can it know which application (of many choices) to use for the file.
But user does.
Otherwise, it's impossible to know how the file will open â" will it open with Preview, or will it open with Photoshop? Depends on what created it, and if you didn't create it,...
... and if you didn't create it - then use default application.
So finally you understand why it was implemented so?:)
OS can't know what file is for - instead of deciding for the user, follow the history of file.
As RTFA says, there were no technical reasons for the change. There is no point in technical discussions. Apple's management decided to clean up the handling, make it more aligned with the rest of systems.
"There are no reasons for it. It's just our corporate policy." (c)
Photoshop documents should open with Photoshop. If you only want to preview it, that should be a right-click menu choice, not a file-by-file setting that overrides the "Open in Photoshop" default action.
.PSD is not PS-only file format anymore. Probably in Windows or from POV of end-users. But nor on Macs or among designers.
It is quite often used as a plain image file format. There are many applications which can read it (Mac OS X's vanilla Preview can, any decent image editor) and many applications which can write it (same list).
So this was a quite normal work flow: all PSDs you create yourself would be open by PS, rest - by default Preview.
LOL. And RTFA illustrated that it worked perfectly fine before. And now is broken. Very few commenter here managed to bring an example which was actually broken. Rest are simply "what if"s.
Sole example of old behavior being broken I have read above: QuickTime was used to create.AVI, VLC is associated with.AVI, yet the created file would be open by QuickTime due to creator code.
Example from RTFA is similar but goes backwards: files created with PhotoShop are being by default open with Preview. Changing.PSD association to PS makes it open all files with PS, not only the ones you work with.
Both are valid examples. Both can be mitigated if tool to change association of multiple files would have been provided. And PS patched.
They are going out of their way to break things for users that might have actually used this feature in the last 25 years.
If you haven't noticed the feature in Mac OS X before it might mean only one thing: it is so well implemented that you hadn't even knew you were using it.
All what have happened in SLeopard is a clean up and making default different system, one similar to e.g. KDE.
Though most important aspect - as I'm concerned - is retained: one can still assign a different application to open the particular file.
Oh... I digress. The RTFA explicitly says that Finder's "Get Info" window still allows to change application to be used to open the file. IOW, I'm on safe side as it is how I usually do it anyway.
P.S.
Evidence provided through an anonymous tip suggests that removal of the influence of creator codes in Snow Leopard was deliberately imposed by management on engineering. Since engineering's hands are tied, bug reports to them are likely to be met with the usual "works as intended" brush-off.
If Apple did it right, then I'm pretty sure one can programmatically change the per-file association. Or probably even with the AppleScript.
After RTFA it seems to me the issue was greatly exaggerated.
But UTI is in no way a replacement for a creator code.
The most useful aspect to me was that one can tell that the particular file has to be opened by different application.
E.g. for most of smallish stuff I'm using QuickTime Player. But most of my movie collection is marked as to be opened by MPlayer. Files types are the same - but different applications are used to open different files.
Or bigger (to organization of my personal information) example are plain text files. On my Mac OS X MacVim is used as default editor. But I also have number of text files which I open and print only from TextEdit.
Creator code was allowing to set non-default application to open the file.
P.S. That was BTW one of the most missed features when I worked under Windows: allow shortcuts to have customized application and customized action for opening the file. After gaining access to Macs I naively thought it was another cool feature. It doesn't look like an ancient artifact to me.
Slashdot Mirror
Thanks!
Can anybody give real life examples where the CPU multi-threading brings anything?
And please only real life examples: no theory, no official PR - I know them well myself.
The question is... how is this different to Intel's Thread Building Bocks, or OpenMP, both of which are better supported and more widely available to non-Mac developers.
If I'm not mistaken the technologies are for an application.
GCD can coordinate all applications running on the same system.
I guess having their own implemntation (for the mac) makes sense, as they can integrate it throughout the OS. I don't know anything about GCD either, but could it be used in Linux to make that a more parallel-friendly OS with less developer effort, and more standardisation of parallel execution?
Theoretically yes.
Apple here is in unique position.
Most software developers care solely about their own application. Old example from the desktop. On Windows I have 7-zip archiver installed. I have dual core CPU and this 7-zip is configured to use the 2 cores. From prospective of software developers it's all what they can do: let users tell how much cores/CPUs can be used. But I also have a video encoding application installed - and also configured to use two cores. If I try to run them both in parallel, that would cause erroneous amount of context switching harming performance of both the tasks. In worst case that might make my desktop completely unresponsive. As user I'm also lazy to reconfigure every time applications how many CPUs they should use.
Apple itself now produces number of applications which can utilize multiple CPUs (iTunes audio conversion, iMovie/QuickTime/FC video conversion, etc) and obviously they run into the problem that when applications left on their own to decide how much CPU resources they should use, system would overload leading to all the effects. Requiring user to reconfigure all the applications all the time is also kind of stupid.
Since Apple is in control of the OS and applications - and their own software might suffer from the problem, they went out and implemented the solution: system-wide batch queue with a thread pool. They are still threads - local to the process - but they are scheduled on system-wide basis. You do not need to configure applications how many CPUs they should use - nor applications have to think about: they simply put tasks (to be threads) of the queue of GCD.
I'm using the 'batch queue' term because this is the closest what exists now. Though classical UNIX batch queues are different in nature: those are processes and they are executed at some unknown point of time. GCD is real-time in its nature and its threads run immediately, unlike traditional batch queues which wait for system to be idle.
~200 lines of code required to implement thread pool for an application is hardly an effort. Three-four hours of coding at most.
Configuring bunch of applications, each with a thread pool, to utilize system optimally to extract maximum performance out of it - is an effort which has to take every time one deploys the software anew. And in my experience people spend considerable time (weeks) to configure thread pools properly: avoid overload and maximize performance.
I've seen that many times before. I'm also seeing the same with product sold by my employers: we have at least four applications with thread pools. Coming up for every deployment with the suitable configuration (which depends on business case of customer) is a time consuming process.
Apple has a long tradition to make things its own way, not always in the cleanest way under the hood.
I grew out of being purist and now I can reply you: to keep the sh1t in one place.
Otherwise you can go Linux way: keep tech under the hood clean, but as collateral force every program to swallow some of the sh1t and pass it on to end user.
And we all know that in the end the approach doesn't work. Struggles of Linux on desktop is the best evidence of that.
It's an old tech. But it's different this time around.
Old thread pools are per process. This is a thread pool for the whole system. And that's new.
IOW, with GCD you do not need to configure every application how much threads it should start. Applications do not need to bother with it anymore too: they simply queue batch tasks as they arrive and GCD guarantees that they will be executed. Without overloading system.
Shortly, GCD is a system-wide replacement for old per-application thread pool configuration. Makes applications simpler and also doesn't force end-user to understand all oddities of multi-programming to get most out of their boxes.
Having done some multiprogramming, I have to tell that it is really an end-user technology. Less a tool for developer.
One of the biggest problems on multi-CPU/core systems if to split appropriately CPUs between applications. That requires quite amount of testing and benchmarking. Then you simply configure max number of threads each application allowed to use. Obviously changing anything at later time when problem was found requires some effort too.
With GDC that all now is much easier. Available CPU resources are presented to applications in a fashion of real-time batch queue. One doesn't need to configure thread pools per application anymore.
That was never a problem from software development point of view - we just provide the 'max threads' parameter. But that was always problem from user/operator point of view who has to actually fill in the parameter.
To me it looked something like a nameless function, which shares same stack with the functions where it is defined.
Even if it's a dumb nameless function, it could be already very useful. E.g. perl's 'sort {$a op $b} @list' can be more or less directly translated to C's 'qsort( .... ^(const void *a, const void *b){ return a op b; } )'. At least I hope so.
You are stepping into dangerous waters.
Single Oracle license can buy you a lot of OS licenses - along with servers for the change.
Oracle is as evil as MS. If not more: their involvement with Linux is what in greater part makes up for the server bias in development as Linux became in past years the top Oracle platform. IOW, they one of the largest supporters of ruining Linux on desktop, as fat chunk of Red Hat and Novell profits comes from supporting and selling certified Oracle platform.
You forgot Oracle.
But IMO it make no difference. The whole point of GPL is to create leveled ground for cooperation so that all participants can benefit.
MS benefits because one more OS would run well under its VM. Linux benefits because it has now one more supported platform.
If MS drops from the cooperation and nobody would step in to support the code, then the code is really useless and there is no hard removing it.
I'd say in "2-3GB"
Mathematically that would make sense. Ranges are likely [1, 2) and [2, 3).
But note that graph isn't about how much memory you have installed, but how much physical memory Windows is reporting. Without accessing BIOS (Administrator rights required) it's impossible to know how much physical RAM you do have.
MS sells it's core software products to the end user direct
Care elaborate? What software? Which country?
AFAICT, on low-end PCs highly likely RAM is shared with video RAM. Depending on how much is given to video, RAM size might vary.
Thus the silly size ranges.
That's quite interesting. The graph shows that about 25% of systems runs on AMD CPUs. Frankly (though I claim to be an AMD enthusiast) I thought that AMD now at 10-15% max.
Apparently, thanks to the media hype around high-end toys, low-end gets neglected. And low-end is a place were AMD is very strong. That's only way I can explain the 25% user share of AMD....
MS site isn't THAT bad.
Companies are different. Their focus is different. Apple sells its product directly - thus site is optimized with end users in mind. MS orients itself as a partner company - thus its web site is a kind of source of bullets points for PowerPoint presentations which can be reused by its partners when selling MS products. Both serve their purpose.
Frankly best analogy was already made here. It says it all.
Sometimes they are quite comprehensive BTW as they are used further for internal research. But only sometimes.
As for RFCs, in my experience few students actually read them. TCP implementation is scattered over many STDs/RFCs and gathering them together is a pain. Most prefer to cheat using some TCP book.
What you say is a valid concern. But my point was different: no way there is a technical reason for one year delay for the fix in so well known piece of software as the TCP stack. (Which in MS's case is a verbatim copy of FreeBSD's stack.)
True. (Wouldn't lie - I personally implemented in past only about 50% of TCP.)
Nevertheless, it's pretty well known fact that MS took their implementation of TCP from BSD which apparently doesn't have the problem. More than that they took fresh implementation from FreeBSD relatively recently for 2003 Server.
Cisco IIRC also uses FreeBSD TCP implementation.
In other words, I still fail to see the problem: likewise they could have lifted the solution for the problem from the very same source where from they took their TCP implementation originally.
If I'm not mistaken, the problem was fixed last October in Linux. I doubt it took BSD folks longer.
Yes, absolutely. TCP is so complicated that only few engineers know precisely how it works and can patch the flaw. And probably it also lacks test tools. OMG. I'm so happy that it took them only a year.
WTF. Get real. TCP is studied and implemented as a lab assignment now in pretty much every university by all who in any way relate to network programming. Test tools and analyzers are abundant (both hardware and software) and can simulate pretty much any kind of load. There are even commercial companies selling (at size of MS and Cisco) for pennies ready suits of test cases for TCP.
Longest way: rent an analyzer (2-4 weeks longest for it to get shipped to your office), buy a suit of test cases (0 days), run the tests (1-2 days, normally less), patch the hole (1-2 days), rerun the tests (1-2 days). IOW, if they really cared, they could have released a patch within 2-3 weeks. Heck, I have seen people implementing basic TCP quicker than that.
This is simply another display of arrogance on part of big vendors. Nothing new here. Move on.
I'd argue that the amount of time lost by having to right-click and choose "Preview" (which should be the 2nd choice, the first being "Open") is worth it for the added benefit of always knowing what the file will open with.
And users know how file will open. If I created file yesterday in Photoshop, I can be sure that reopening it today would also start Photoshop, not Preview.
OS doesn't know why file is there nor can it know which application (of many choices) to use for the file.
But user does.
Otherwise, it's impossible to know how the file will open â" will it open with Preview, or will it open with Photoshop? Depends on what created it, and if you didn't create it, ...
So finally you understand why it was implemented so? :)
OS can't know what file is for - instead of deciding for the user, follow the history of file.
As RTFA says, there were no technical reasons for the change. There is no point in technical discussions. Apple's management decided to clean up the handling, make it more aligned with the rest of systems.
"There are no reasons for it. It's just our corporate policy." (c)
Photoshop documents should open with Photoshop. If you only want to preview it, that should be a right-click menu choice, not a file-by-file setting that overrides the "Open in Photoshop" default action.
It is quite often used as a plain image file format. There are many applications which can read it (Mac OS X's vanilla Preview can, any decent image editor) and many applications which can write it (same list).
So this was a quite normal work flow: all PSDs you create yourself would be open by PS, rest - by default Preview.
LOL. And RTFA illustrated that it worked perfectly fine before. And now is broken. Very few commenter here managed to bring an example which was actually broken. Rest are simply "what if"s.
Sole example of old behavior being broken I have read above: QuickTime was used to create .AVI, VLC is associated with .AVI, yet the created file would be open by QuickTime due to creator code.
Example from RTFA is similar but goes backwards: files created with PhotoShop are being by default open with Preview. Changing .PSD association to PS makes it open all files with PS, not only the ones you work with.
Both are valid examples. Both can be mitigated if tool to change association of multiple files would have been provided. And PS patched.
That is (if RTFA to be believed) is unchanged in SL.
I overall agree with you except that:
They are going out of their way to break things for users that might have actually used this feature in the last 25 years.
If you haven't noticed the feature in Mac OS X before it might mean only one thing: it is so well implemented that you hadn't even knew you were using it.
All what have happened in SLeopard is a clean up and making default different system, one similar to e.g. KDE.
Though most important aspect - as I'm concerned - is retained: one can still assign a different application to open the particular file.
Oh... I digress. The RTFA explicitly says that Finder's "Get Info" window still allows to change application to be used to open the file. IOW, I'm on safe side as it is how I usually do it anyway.
P.S.
Evidence provided through an anonymous tip suggests that removal of the influence of creator codes in Snow Leopard was deliberately imposed by management on engineering. Since engineering's hands are tied, bug reports to them are likely to be met with the usual "works as intended" brush-off.
If Apple did it right, then I'm pretty sure one can programmatically change the per-file association. Or probably even with the AppleScript.
After RTFA it seems to me the issue was greatly exaggerated.
But UTI is in no way a replacement for a creator code.
The most useful aspect to me was that one can tell that the particular file has to be opened by different application.
E.g. for most of smallish stuff I'm using QuickTime Player. But most of my movie collection is marked as to be opened by MPlayer. Files types are the same - but different applications are used to open different files.
Or bigger (to organization of my personal information) example are plain text files. On my Mac OS X MacVim is used as default editor. But I also have number of text files which I open and print only from TextEdit.
Creator code was allowing to set non-default application to open the file.
P.S. That was BTW one of the most missed features when I worked under Windows: allow shortcuts to have customized application and customized action for opening the file. After gaining access to Macs I naively thought it was another cool feature. It doesn't look like an ancient artifact to me.