I agree with this point of view. I have prepared by upgrading my memory from 2GB to 4GB; that is all I can do hardware wise to upgrade my current iMac. But I expect to benefit from better utilization of the 64-bit Intel CPU, and from quicker back-ups via Time Machine and Time Capsule because of SL. The ATI Radeon HD 2600 graphic card will not be supported for OpenCL, but I am not pining about it. I think it is wonderful that SL is about stability, performance, and preparing for Mac OS 10.7.
I expect that some of the bundled apps like Mail and Safari will be GCD enabled in SL. A question I have in my mind is when the iLife and iWork apps will be GCD enabled, and begin taking advantage of OpenCL. Does anyone know? Would the SL Box Set just be SL plus 64-bit versions of iLife and iWork without being GCD enabled or taking any advantage of OpenCL? For now, I think I probably will have to wait on the description of the SL Box set when it is announced.
Do you have a link to support your claims about the 2600? I have read that the 2400 and 2600 will be supported for OpenCL.
The two authors are on the committee from AMD and it includes explicit support to MAC OS X, Win32 and Linux.
I looked at your link. Good to know. So, I presume the question becomes whether drivers for these cards (ATI 2400 and 2600) will be updated in a future SL point release. I'm not clear whether Apple or ATI will do the work; I don't know the business policy or business case involved here. Thanks. I had also read that support would be technically possible, but treated Apple SL specs as the definitive word.
I think the problem would be everyone would think it is a relas candidate and expect everything to work perfectly. The support lines would be overwhelmed. Plus with more people having software in a constant state of revision would give the perception of poorly written software. Microsoft wa able to do a preview of Windows 7 because the code was finished a long time ago with Vista.
You are wrong for the following reason: Microsoft does NOT provide support for products still in testing; Windows 7 RC was a 'use at your own risk' release.
Regarding public beta testing, anyone who advocates such an idea should have a look at the horrible bug submissions - if it isn't the lack of detail that'll cause more problems than it solves it will be the inane bug reports on issues that aren't bugs but requests for a given feature. Either the engineers are overwhelmed with useless feedback or the feedback they do receive is completely pointless.
I agree with this point of view. I have prepared by upgrading my memory from 2GB to 4GB; that is all I can do hardware wise to upgrade my current iMac. But I expect to benefit from better utilization of the 64-bit Intel CPU, and from quicker back-ups via Time Machine and Time Capsule because of SL. The ATI Radeon HD 2600 graphic card will not be supported for OpenCL, but I am not pining about it. I think it is wonderful that SL is about stability, performance, and preparing for Mac OS 10.7.
I expect that some of the bundled apps like Mail and Safari will be GCD enabled in SL. A question I have in my mind is when the iLife and iWork apps will be GCD enabled, and begin taking advantage of OpenCL. Does anyone know? Would the SL Box Set just be SL plus 64-bit versions of iLife and iWork without being GCD enabled or taking any advantage of OpenCL? For now, I think I probably will have to wait on the description of the SL Box set when it is announced.
I'm in the same situation with my iMac - I don't think that OpenCL will deliver much for an end user like me given that the type of things I'll be doing will gain no benefit out of OpenCL.
Regarding iWork and iLife - from what I understand from the Apple website, GCD is extensively used through the operating system; I assume that if the Apple website is accurate, if iLife and iWork are utilising these share components of Mac OS X, then it should also inherit the performance improvements as well.
It will be interesting to see what Safari is like when Snow Leopard is released because when I tried Snow Leopard, it was as though Safari was a different beast when compared to Safari on Leopard.
I'm in the same situation with my iMac - I don't think that OpenCL will deliver much for an end user like me given that the type of things I'll be doing will gain no benefit out of OpenCL.
Regarding iWork and iLife - from what I understand from the Apple website, GCD is extensively used through the operating system; I assume that if the Apple website is accurate, if iLife and iWork are utilising these share components of Mac OS X, then it should also inherit the performance improvements as well.
It will be interesting to see what Safari is like when Snow Leopard is released because when I tried Snow Leopard, it was as though Safari was a different beast when compared to Safari on Leopard.
I think that SL Mail is GCD "enabled" because Mr. Serlet at the WWDC mentioned that SL Mail could release threads, but that Leopard Mail could not do the same. To me, that means that Apple has re-worked this multi-threaded app to use GCD APIs (set up blocks). Probably true for some other SL bundled apps.
No doubt iLife and iWork will benefit indirectly from an OS that itself utilizes GCD. If I understand this correctly, Cocoa frameworks can use GCD, thus benefitting Cocoa apps indirectly after a re-compile. But as to when the iLife and iWork apps become GCD "enabled" by directly taking advantage of GCD APIs, that is my question. If not in the SL Box Set, than no doubt in later releases of iLife and iWork. At that point, I am a SL customer ready to buy iLife and iWork.
Cocoa itself is GCD enabled. You see, Apple introduced API's that were somewhat like GCD called NSOperations. That's the high-level threading tool generally. With 10.6 Apple pulled these API's closer to the core of the OS and then reengineered NSOperation to use the new, more efficient and "smart" APIs. Nonetheless, to developers, and apps, it all looks the same. So any programs built on NSOperation APIs get GCD for free. The app tells the Cocoa APIs it wants to use an NSOperation. On 10.5 that doesn't use GCD. On 10.6, the app gets GCD-enabled NSOperations.
So what's the difference? GCD leverages "smart" API's that know the system and control how many processors and threads are used, and how operations are cued to maximize complete system performance. Earlier, the NSOperation class didn't know about what the system was doing, or what was best for all-round performance. It just made threads if required and threw the operations at the threads - whether or not the computer could process that amount of threads at once and whether or not that many threads were needed.
By the way, this is why iWork and iLife now require 10.5 - NSOperations were introduced in Leopard and Apple wanted GCD to just work on iWork and iLife straight away. Thus they required the use of NSOperation. Thus they were 10.5 and above only.
Cocoa itself is GCD enabled. You see, Apple introduced API's that were somewhat like GCD called NSOperations. That's the high-level threading tool generally. With 10.6 Apple pulled these API's closer to the core of the OS and then reengineered NSOperation to use the new, more efficient and "smart" APIs. Nonetheless, to developers, and apps, it all looks the same. So any programs built on NSOperation APIs get GCD for free. The app tells the Cocoa APIs it wants to use an NSOperation. On 10.5 that doesn't use GCD. On 10.6, the app gets GCD-enabled NSOperations.
So what's the difference? GCD leverages "smart" API's that know the system and control how many processors and threads are used, and how operations are cued to maximize complete system performance. Earlier, the NSOperation class didn't know about what the system was doing, or what was best for all-round performance. It just made threads if required and threw the operations at the threads - whether or not the computer could process that amount of threads at once and whether or not that many threads were needed.
By the way, this is why iWork and iLife now require 10.5 - NSOperations were introduced in Leopard and Apple wanted GCD to just work on iWork and iLife straight away. Thus they required the use of NSOperation. Thus they were 10.5 and above only.
Sir! thanks for the explanation?"any programs built on NSOperation APIs get GCD for free." I dare say I understand what you said.
Sir! thanks for the explanation?"any programs built on NSOperation APIs get GCD for free." I dare say I understand what you said.
Yes. Not sure whether that was sarcasm or not but I was trying to explain the details so people would know why there was so much hype over a technology already built into OS X.
Yes. Not sure whether that was sarcasm or not but I was trying to explain the details so people would know why there was so much hype over a technology already built into OS X.
Hope it helps.
No, no, I am a retired programmer not conversant in Cocoa, but has the background to understand your clear explanation.
ha ha very funny. I end up buying several copies of the master collection for mac and pc because nothing is backwardsly compatible and they make indiviual applications very unattractive to upgrade. As soon as another vendor sends us a file in the new format we end up having to upgrade every machine in the studio
I didn't think that was too vague - but to clarify, I have several pro designers on staff and we do a lot of video and animation work. Also I might add that am NOT retired and actuallly do real work on a daily basis.
I didn't think that was too vague - but to clarify, I have several pro designers on staff and we do a lot of video and animation work. Also I might add that am NOT retired and actuallly do real work on a daily basis.
It's the way you write sometimes that's the problem.
Comments
I agree with this point of view. I have prepared by upgrading my memory from 2GB to 4GB; that is all I can do hardware wise to upgrade my current iMac. But I expect to benefit from better utilization of the 64-bit Intel CPU, and from quicker back-ups via Time Machine and Time Capsule because of SL. The ATI Radeon HD 2600 graphic card will not be supported for OpenCL, but I am not pining about it. I think it is wonderful that SL is about stability, performance, and preparing for Mac OS 10.7.
I expect that some of the bundled apps like Mail and Safari will be GCD enabled in SL. A question I have in my mind is when the iLife and iWork apps will be GCD enabled, and begin taking advantage of OpenCL. Does anyone know? Would the SL Box Set just be SL plus 64-bit versions of iLife and iWork without being GCD enabled or taking any advantage of OpenCL? For now, I think I probably will have to wait on the description of the SL Box set when it is announced.
Do you have a link to support your claims about the 2600? I have read that the 2400 and 2600 will be supported for OpenCL.
Do you have a link to support your claims about the 2600? I have read that the 2400 and 2600 will be supported for OpenCL.
Here is the link you requested. Look under OpenCL.
list.http://www.apple.com/macosx/specs.html
Here is the link you requested. Look under OpenCL.
list.http://www.apple.com/macosx/specs.html
That list will change state.
FWIW: Experimental C++ support bindings is on version 0.3 in the specs:
http://www.khronos.org/registry/cl/api/1.0/cl.hpp
The two authors are on the committee from AMD and it includes explicit support to MAC OS X, Win32 and Linux.
That list will change state.
FWIW: Experimental C++ support bindings is on version 0.3 in the specs:
http://www.khronos.org/registry/cl/api/1.0/cl.hpp
The two authors are on the committee from AMD and it includes explicit support to MAC OS X, Win32 and Linux.
I looked at your link. Good to know. So, I presume the question becomes whether drivers for these cards (ATI 2400 and 2600) will be updated in a future SL point release. I'm not clear whether Apple or ATI will do the work; I don't know the business policy or business case involved here. Thanks. I had also read that support would be technically possible, but treated Apple SL specs as the definitive word.
Can you recommend a good retailer?
OWC. www.macsales.com
I think the problem would be everyone would think it is a relas candidate and expect everything to work perfectly. The support lines would be overwhelmed. Plus with more people having software in a constant state of revision would give the perception of poorly written software. Microsoft wa able to do a preview of Windows 7 because the code was finished a long time ago with Vista.
You are wrong for the following reason: Microsoft does NOT provide support for products still in testing; Windows 7 RC was a 'use at your own risk' release.
Regarding public beta testing, anyone who advocates such an idea should have a look at the horrible bug submissions - if it isn't the lack of detail that'll cause more problems than it solves it will be the inane bug reports on issues that aren't bugs but requests for a given feature. Either the engineers are overwhelmed with useless feedback or the feedback they do receive is completely pointless.
I agree with this point of view. I have prepared by upgrading my memory from 2GB to 4GB; that is all I can do hardware wise to upgrade my current iMac. But I expect to benefit from better utilization of the 64-bit Intel CPU, and from quicker back-ups via Time Machine and Time Capsule because of SL. The ATI Radeon HD 2600 graphic card will not be supported for OpenCL, but I am not pining about it. I think it is wonderful that SL is about stability, performance, and preparing for Mac OS 10.7.
I expect that some of the bundled apps like Mail and Safari will be GCD enabled in SL. A question I have in my mind is when the iLife and iWork apps will be GCD enabled, and begin taking advantage of OpenCL. Does anyone know? Would the SL Box Set just be SL plus 64-bit versions of iLife and iWork without being GCD enabled or taking any advantage of OpenCL? For now, I think I probably will have to wait on the description of the SL Box set when it is announced.
I'm in the same situation with my iMac - I don't think that OpenCL will deliver much for an end user like me given that the type of things I'll be doing will gain no benefit out of OpenCL.
Regarding iWork and iLife - from what I understand from the Apple website, GCD is extensively used through the operating system; I assume that if the Apple website is accurate, if iLife and iWork are utilising these share components of Mac OS X, then it should also inherit the performance improvements as well.
It will be interesting to see what Safari is like when Snow Leopard is released because when I tried Snow Leopard, it was as though Safari was a different beast when compared to Safari on Leopard.
I'm in the same situation with my iMac - I don't think that OpenCL will deliver much for an end user like me given that the type of things I'll be doing will gain no benefit out of OpenCL.
Regarding iWork and iLife - from what I understand from the Apple website, GCD is extensively used through the operating system; I assume that if the Apple website is accurate, if iLife and iWork are utilising these share components of Mac OS X, then it should also inherit the performance improvements as well.
It will be interesting to see what Safari is like when Snow Leopard is released because when I tried Snow Leopard, it was as though Safari was a different beast when compared to Safari on Leopard.
I think that SL Mail is GCD "enabled" because Mr. Serlet at the WWDC mentioned that SL Mail could release threads, but that Leopard Mail could not do the same. To me, that means that Apple has re-worked this multi-threaded app to use GCD APIs (set up blocks). Probably true for some other SL bundled apps.
No doubt iLife and iWork will benefit indirectly from an OS that itself utilizes GCD. If I understand this correctly, Cocoa frameworks can use GCD, thus benefitting Cocoa apps indirectly after a re-compile. But as to when the iLife and iWork apps become GCD "enabled" by directly taking advantage of GCD APIs, that is my question. If not in the SL Box Set, than no doubt in later releases of iLife and iWork. At that point, I am a SL customer ready to buy iLife and iWork.
Cocoa itself is GCD enabled. You see, Apple introduced API's that were somewhat like GCD called NSOperations. That's the high-level threading tool generally. With 10.6 Apple pulled these API's closer to the core of the OS and then reengineered NSOperation to use the new, more efficient and "smart" APIs. Nonetheless, to developers, and apps, it all looks the same. So any programs built on NSOperation APIs get GCD for free. The app tells the Cocoa APIs it wants to use an NSOperation. On 10.5 that doesn't use GCD. On 10.6, the app gets GCD-enabled NSOperations.
So what's the difference? GCD leverages "smart" API's that know the system and control how many processors and threads are used, and how operations are cued to maximize complete system performance. Earlier, the NSOperation class didn't know about what the system was doing, or what was best for all-round performance. It just made threads if required and threw the operations at the threads - whether or not the computer could process that amount of threads at once and whether or not that many threads were needed.
By the way, this is why iWork and iLife now require 10.5 - NSOperations were introduced in Leopard and Apple wanted GCD to just work on iWork and iLife straight away. Thus they required the use of NSOperation. Thus they were 10.5 and above only.
Ok let's clear this up guys:
Cocoa itself is GCD enabled. You see, Apple introduced API's that were somewhat like GCD called NSOperations. That's the high-level threading tool generally. With 10.6 Apple pulled these API's closer to the core of the OS and then reengineered NSOperation to use the new, more efficient and "smart" APIs. Nonetheless, to developers, and apps, it all looks the same. So any programs built on NSOperation APIs get GCD for free. The app tells the Cocoa APIs it wants to use an NSOperation. On 10.5 that doesn't use GCD. On 10.6, the app gets GCD-enabled NSOperations.
So what's the difference? GCD leverages "smart" API's that know the system and control how many processors and threads are used, and how operations are cued to maximize complete system performance. Earlier, the NSOperation class didn't know about what the system was doing, or what was best for all-round performance. It just made threads if required and threw the operations at the threads - whether or not the computer could process that amount of threads at once and whether or not that many threads were needed.
By the way, this is why iWork and iLife now require 10.5 - NSOperations were introduced in Leopard and Apple wanted GCD to just work on iWork and iLife straight away. Thus they required the use of NSOperation. Thus they were 10.5 and above only.
Sir! thanks for the explanation?"any programs built on NSOperation APIs get GCD for free." I dare say I understand what you said.
OWC. www.macsales.com
Thanks!
Sir! thanks for the explanation?"any programs built on NSOperation APIs get GCD for free." I dare say I understand what you said.
Yes. Not sure whether that was sarcasm or not but I was trying to explain the details so people would know why there was so much hype over a technology already built into OS X.
Hope it helps.
Yes. Not sure whether that was sarcasm or not but I was trying to explain the details so people would know why there was so much hype over a technology already built into OS X.
Hope it helps.
No, no, I am a retired programmer not conversant in Cocoa, but has the background to understand your clear explanation.
ha ha very funny. I end up buying several copies of the master collection for mac and pc because nothing is backwardsly compatible and they make indiviual applications very unattractive to upgrade. As soon as another vendor sends us a file in the new format we end up having to upgrade every machine in the studio
Exactly what are you talking about?
Can you recommend a good retailer?
OWC is pretty reliable, and is having sales right now.
http://eshop.macsales.com/shop/XLR8_...=XLR8YourMac09
Exactly what are you talking about?
I didn't think that was too vague - but to clarify, I have several pro designers on staff and we do a lot of video and animation work. Also I might add that am NOT retired and actuallly do real work on a daily basis.
I didn't think that was too vague - but to clarify, I have several pro designers on staff and we do a lot of video and animation work. Also I might add that am NOT retired and actuallly do real work on a daily basis.
It's the way you write sometimes that's the problem.
No, no, I am a retired programmer not conversant in Cocoa, but has the background to understand your clear explanation.
Oh, ok. I'm an iPhone programmer, with quite a bit of mac programming experience.