Grand things to come (CUDA GrandCentral and more)
Tossing calulations at the GPU will bring a enormous boost
Not only SETI (hhttp://www.tomshardware.com/reviews/nvidia-cuda-gpgpu,2299-4.html)
But many more things
http://www.tomshardware.com/reviews/...pgpu,2299.html
And note that they compare the boost going from a 2.7GHz Dual core to a graphical card in the 60-100 USD range.
If 10.6 and many apps can use this power, there will be a performance leap like at no other macintosh generations shift. That is for intel macs with decent GPUs (that does probably not include the nvidia 7300 in the macpro or the ATI 2600 in the later octa core macro or most of the iMac GPUs.
Let me guess Apple will revise the whole lineup and for the first time offer really good GPUs
Not only SETI (hhttp://www.tomshardware.com/reviews/nvidia-cuda-gpgpu,2299-4.html)
But many more things
http://www.tomshardware.com/reviews/...pgpu,2299.html
And note that they compare the boost going from a 2.7GHz Dual core to a graphical card in the 60-100 USD range.
If 10.6 and many apps can use this power, there will be a performance leap like at no other macintosh generations shift. That is for intel macs with decent GPUs (that does probably not include the nvidia 7300 in the macpro or the ATI 2600 in the later octa core macro or most of the iMac GPUs.
Let me guess Apple will revise the whole lineup and for the first time offer really good GPUs
Comments
If 10.6 and many apps can use this power, there will be a performance leap like at no other macintosh generations shift. That is for intel macs with decent GPUs (that does probably not include the nvidia 7300 in the macpro or the ATI 2600 in the later octa core macro or most of the iMac GPUs.
Let me guess Apple will revise the whole lineup and for the first time offer really good GPUs
Apple will only be able to use the best cards in the only desktop they sell - the Mac Pro. The rest will be limited to mobile chips, which typically don't have more than 32 stream processors.
Their current GPUs in the iMac, Mini and laptops have 16 or 32 stream processors running at around 1GHz but I think they will add sufficient performance boosts to apps as they are used on top of the CPU. Even a 2-3x boost is far more than hardware refreshes give you (not counting the PPC to Intel switch). If they utilized higher power chips, they'd generate far more heat in constant use.
Nvidia have a new iGT209 chip coming in Q3 so I wouldn't expect a mobile GPU upgrade before then. Not at WWDC anyway. This event will be about software and possibly the iphone. A Mac refresh will probably arrive close to the back-to-school period.
Overall, Grand Central Dispatch has wider usage. It can be applied to anything that can be broken into pieces, including text replacement, parsing, certain calculations, processing elements of arrays and dictionaries. As the full name suggest, it's role is to manage all data processing tasks as "packages", dynamically utilizing the computer resources. The data for the tasks does not need to be "packed". Only the dependencies between the tasks need to be defined. Grand Central Dispatch does not use Mac OS/POSIX threads and is much simpler, more efficient and more dynamic than classic multi-threading. By adding support for GCD in high-level frameworks Apple makes it very easy to use. It has C and Objective-C APIs.
OpenCL is suitable for parallel processing of large "packed" data chunks where certain calculations should be performed many many times. It is a C-like programming language which leverages the CPU, GPU and any other computing resources found on the system. It is extremely suitable for cell-like architectures. To use OpenCL, however, the developers need to use this language. Not all tasks are suitable for OpenCL but those which are may get huge performance boost. If the adoption rate of OpenCL is good (both HW vendors and software developers), Apple could get a very strong differentiation factor against Windows. The HW/SW integration Apple has will be particularly handy. This leaves the doors open for new co-processors in the future. The fragmented Wintel world would have hard time to catch up.
I expect the next Pro to be radically different with support for multiple GPUs. If Apple could get the software end to give a performance advantage compared to Win 7 they would be pretty daft if they did not made the hardware use this advantage to the very last drop
I want to see GCD/Open CL give a meaningful impact to many things we do that are utilitarian and common to our daily schedule. I think it's going to take a year before we really see apps taking good advantage of GCD/OpenCL.
The other problem I see is wholly Apple created. GCD is great if you have Mac Pro and are able to change your GPU but every other Mac computer has what Apple has decided for you by and large and that doesn't let you design your CPU/GPU structure to leverage GCD and OpenCL as effectively as I'd like.
The other problem I see is wholly Apple created. GCD is great if you have Mac Pro and are able to change your GPU but every other Mac computer has what Apple has decided for you by and large and that doesn't let you design your CPU/GPU structure to leverage GCD and OpenCL as effectively as I'd like.
1. I expect GCD to provide measurable improvement even on a 2-core notebook. Not that big as on 8-core but a measurable/perceptible improvement (with the supported Apps, that is).
2. OpenCL will bring very big improvement (with the supported Apps) even on an entry-level OpenCL-capable card.
1. I expect GCD to provide measurable improvement even on a 2-core notebook. Not that big as on 8-core but a measurable/perceptible improvement (with the supported Apps, that is).
2. OpenCL will bring very big improvement (with the supported Apps) even on an entry-level OpenCL-capable card.
I'm certainly hoping so though the key to OpenCL being more useful than CUDA is GCD and Blocks (as you eloquently mentioned previously).
If I'm developing an app I want to be concurrent I don't want to worry about if my code is optimum for the CPU or GPU I want the OS to take care of all of that.
I think we're going to have a future where we could see the return of DSP (much like AMD's propose Torrenza platform). Historically DSP have been difficult to program for but if their power can be harnessed like a CPU or GPU then they become just another compute engine in the chain.
I expect to see GCD evolve to cover more compute resources as they become available.
I'm certainly hoping so though the key to OpenCL being more useful than CUDA is GCD and Blocks (as you eloquently mentioned previously).
If I'm developing an app I want to be concurrent I don't want to worry about if my code is optimum for the CPU or GPU I want the OS to take care of all of that.
I think we're going to have a future where we could see the return of DSP (much like AMD's propose Torrenza platform). Historically DSP have been difficult to program for but if their power can be harnessed like a CPU or GPU then they become just another compute engine in the chain.
I expect to see GCD evolve to cover more compute resources as they become available.
As far as I understand it, GCD manages CPU. Not sure how it will work with DSPs
OpenCL, as far as I know, works on both CPU and OpenCL capable GPU, and possibly other processors. The developer can choose to allow the code to be executed on any compute resource, or on a specific one (e.g. GPU only).
As far as I understand it, GCD manages CPU. Not sure how it will work with DSPs
OpenCL, as far as I know, works on both CPU and OpenCL capable GPU, and possibly other processors. The developer can choose to allow the code to be executed on any compute resource, or on a specific one (e.g. GPU only).
Yes actually I got my wires crossed. GCD would have to be the brains behind whatever end user tool does the final computation. GCD is obviously task oriented versus OpenCL being data oriented.
I'm certainly hoping so though the key to OpenCL being more useful than CUDA is GCD and Blocks (as you eloquently mentioned previously).
If I'm developing an app I want to be concurrent I don't want to worry about if my code is optimum for the CPU or GPU I want the OS to take care of all of that.
I think we're going to have a future where we could see the return of DSP (much like AMD's propose Torrenza platform). Historically DSP have been difficult to program for but if their power can be harnessed like a CPU or GPU then they become just another compute engine in the chain.
I expect to see GCD evolve to cover more compute resources as they become available.
The key to OpenCL being more successful is GC? Not. The key is how blocks are managed and scaled up across all available units for Parallel processing. Those streams/cores will be where OpenCL spends it's focus.
Depending on the application the developer will have designed certain portions of his code to be run in a separate core to allow concurrent dedicated real-time processing on a core versus time delayed processing on the same core(s) it will be sharing amongst system applications and other third party applications. Within that area where a portion of that code leverages OpenCL it will then be managed via blocks to be spread across available GPU streams/cores and if necessary to open CPU clock cycles [last].
I am really hoping this will be the beginning of the end for Windows.
You have to make programmers employ new technologies first...
You have to make programmers employ new technologies first...
Definitely. When it comes to adopting new technologies Apple has some advantages over Windows:
- When Core Data was introduced, lots of developers were tempted to use the high-level Core-Data API in the expense of not supporting pre-Tiger versions.
- When Core Image was introduced some developers were tempted to develop application which depend on Core Image.
The list can go on...I think there were not so many technologies on the Windows side which could give the developers immediate advantage at such low cost (in terms of learning and coding).
Definitely. When it comes to adopting new technologies Apple has some advantages over Windows:
OK, I take your word for all that.
As far as I understand, what GCD is, before having seen any specifications, the essence of the technology is firing and listening to messages from your "tasks", which are supposed to run concurrently. This is indeed simple and easy to implement. The toughest part of design is thus the decomposition of that into good patterns.
And thus...
Apple has a number of Applications on it's own that are often used to showcase the new technologies.
Not meaning violating any NDA, couldn't you tweet nevertheless, which Apple's application is adopting GCD?
Not meaning violating any NDA, couldn't you tweet nevertheless, which Apple's application is adopting GCD?
I don't know which apps, if any, will support GCD at Snow Leopard launch time. Apple may do away with a shiny demo at WWDC and ship the apps some time after the Snow Leopard release. However, I am pretty sure Apple is working on all iLife, iWorks and pro apps to take advantage of GCD (no inside info, just common sense). If the new Finder rumors are correct (very likely), the Finder will definitely use GCD and file-system related improvements.
What makes me confident that Apple will do this is the fact that it always did in the past. Preview app uses ImageIO/ImageKit/CoreImage to open/manipulate/edit the images. TextEdit always uses the latest changes in text-related frameworks. Mail.app takes advantage of data detectors etc. I think that it is a two-way relationship. Apple starts implementing new technologies when they have a particular use case in mind. Then the applications which take advantage of the new technologies are used to test and debug, and later showcase the technology. In many cases Apple makes a new private framework first, then makes it available for everybody. Cover Flow (iTunes-only at first) and Core Animation come to mind.
I don't know which apps, if any, will support GCD at Snow Leopard launch time. Apple may do away with a shiny demo at WWDC and ship the apps some time after the Snow Leopard release. However, I am pretty sure Apple is working on all iLife, iWorks and pro apps to take advantage of GCD (no inside info, just common sense). If the new Finder rumors are correct (very likely), the Finder will definitely use GCD and file-system related improvements.
What makes me confident that Apple will do this is the fact that it always did in the past. Preview app uses ImageIO/ImageKit/CoreImage to open/manipulate/edit the images. TextEdit always uses the latest changes in text-related frameworks. Mail.app takes advantage of data detectors etc. I think that it is a two-way relationship. Apple starts implementing new technologies when they have a particular use case in mind. Then the applications which take advantage of the new technologies are used to test and debug, and later showcase the technology. In many cases Apple makes a new private framework first, then makes it available for everybody. Cover Flow (iTunes-only at first) and Core Animation come to mind.
Ok, then let's wait calmly for their keynote...
I just liked to get inspired by typical OS operation, which could be efficiently executed in the frame of GCD... I only could fancy copying/moving long lists of files and directories...
does anyone know if quicktime x in snow leopard will support opencl for gpu-accelerated h.264 encodes? cuz thatd be pretty sweet.
I think the right question should be "how effective it is going to be?". If it runs smoothly and saves CPU resources/battery power it does not matter what the underlying technology is. There is no point to use a technology for the sake of the technology.
I think the right question should be "how effective it is going to be?". If it runs smoothly and saves CPU resources/battery power it does not matter what the underlying technology is. There is no point to use a technology for the sake of the technology.
Wow, another smart person in these forums!
That is what I do. While all of you guys waste time speculating about future tech and sounding smart, I am just going to wait and test drive it once it comes out.