........ Apple has been shipping multi-core systems for over a decade, their OS (both iOS and MacOSX) has been aggressively optimized for a multi-processor environment -- including OpenCL. Apple's dev tools and OS in this area are second to none, and in the hands of developers for ages.
The OS is one component of delivering a highly parallel solution. The apps are another. RIM isn't even pushing the apps, and their proposed solution to functionality squanders huge amounts of performance and efficiency when compared to native apps implemented in C/C++/ObjC and using technologies like GCD and OpenCL. And before dismissing OpenCL as a desktop technology, consider that from the outset it was designed to consider embedded devices... and for mobile applications........
Sad to think the IPad may get an OCL capable gpu before the MBA and other Macs that rely on Intel IGPs.
The OS is one component of delivering a highly parallel solution. The apps are another. RIM isn't even pushing the apps, and their proposed solution to functionality squanders huge amounts of performance and efficiency when compared to native apps implemented in C/C++/ObjC and using technologies like GCD and OpenCL. And before dismissing OpenCL as a desktop technology, consider that from the outset it was designed to consider embedded devices... and for mobile applications, GPUs are some of the most power efficient devices available.
It really depends on what is really "native". When normal regular RIM Playbook AIR apps goes to the background when deactivate, the framerate drops to 4 frames per second (from the regular default framerate of 24 frames per second). The Playbook's video player still plays at full speed in the background in the demos --- because it's really a native QNX app in C/C++ with AIR just being a "windows manager". And regular QNX apps will work at full speed in the background in the Playbook --- until the developer explicitly reduces its speed. RIM hyped it as an "AIR" app because they were showing it at an Adobe event.
It really depends on what is really "native". When normal regular RIM Playbook AIR apps goes to the background when deactivate, the framerate drops to 4 frames per second (from the regular default framerate of 24 frames per second). The Playbook's video player still plays at full speed in the background in the demos --- because it's really a native QNX app in C/C++ with AIR just being a "windows manager". And regular QNX apps will work at full speed in the background in the Playbook --- until the developer explicitly reduces its speed. RIM hyped it as an "AIR" app because they were showing it at an Adobe event.
Are you saying that a bg AIR app will continuously consume resources (cycling) even when it is not doing anything? Isn't that a drain on resources and the battery?
Shouldn't the system participate in determinating the speed at which deacitivated apps can run? Say a bg app is compressing and uploading a video, and a fg app is capturing and/or playing a video. Would you want a bg app acting as a co-equal -- reducing the performance of a fg app and the GUI interaction?
What I am asking is:
-- don't the apps, including system apps like the browser, need the intelligence to request full or reduced services determined by whether they are running bg or fg?
-- If yes, how does an app do this?
-- doesn't the OS need to govern the resources that bg apps get based on what else is going on the system?
If, not, why wouldn't each app assume full resources are available and try to monopolize them -- as the PlayBook browser appesrs to do...
... And because of the above (all apps are equal) that resources are proportionately divided among bg and fg apps
... Or the apps, like the browser are designed to run on a single core
The easy thing to do is to design each app to run on a single core with all resources available and let the system control the resource usage by controlling the individual cores.
The PlayBook has 2 cores and a GPU. How/what does QNX do to handle, say, 3 or 4 bg apps competing for a single core?
Does QNX have the capability to utilize the GPU cores and any on board DSPs to distribute processes among apps running bg or fg?
If yes, how are these capabilities exposed to the developers -- certainly not through AIR!
Are you saying that a bg AIR app will continuously consume resources (cycling) even when it is not doing anything? Isn't that a drain on resources and the battery?
Shouldn't the system participate in determinating the speed at which deacitivated apps can run? Say a bg app is compressing and uploading a video, and a fg app is capturing and/or playing a video. Would you want a bg app acting as a co-equal -- reducing the performance of a fg app and the GUI interaction?
What I am asking is:
-- don't the apps, including system apps like the browser, need the intelligence to request full or reduced services determined by whether they are running bg or fg?
-- If yes, how does an app do this?
-- doesn't the OS need to govern the resources that bg apps get based on what else is going on the system?
If, not, why wouldn't each app assume full resources are available and try to monopolize them -- as the PlayBook browser appesrs to do...
... And because of the above (all apps are equal) that resources are proportionately divided among bg and fg apps
... Or the apps, like the browser are designed to run on a single core
The easy thing to do is to design each app to run on a single core with all resources available and let the system control the resource usage by controlling the individual cores.
The PlayBook has 2 cores and a GPU. How/what does QNX do to handle, say, 3 or 4 bg apps competing for a single core?
Does QNX have the capability to utilize the GPU cores and any on board DSPs to distribute processes among apps running bg or fg?
If yes, how are these capabilities exposed to the developers -- certainly not through AIR!
It depends on what kind of apps you are making. RIM/QNX recommends that if your apps don't have to use resources, then save your state and get the hell out of the way so that other apps can use the resources. The OS can still kill your app.
With respect to background apps, I may have worded my comments too loosely. Remember QNX is a hard realtime OS, there is never going to be co-equals. Your foreground app will never eat too much resources so that people can still make a phone call. The background app will never eat too much resources so that the GUI will still operate smoothly.
Developers who attended the "meet the playbook" events in the last few days just found out about AIR apps' access to native c++ extensions (and it is not based on Adobe's Alchemy).
It depends on what kind of apps you are making. RIM/QNX recommends that if your apps don't have to use resources, then save your state and get the hell out of the way so that other apps can use the resources. The OS can still kill your app.
That sounds similar to the current implementation in iOS... Don't know about Android.
Quote:
With respect to background apps, I may have worded my comments too loosely. Remember QNX is a hard realtime OS, there is never going to be co-equals. Your foreground app will never eat too much resources so that people can still make a phone call. The background app will never eat too much resources so that the GUI will still operate smoothly.
Unfortunately, the demos shown: HD video player in the bg plus a few others; browser dominating a core; give the impression that QNX handles all this seamlessly -- when, in fact they are contrived demos that don't represent real-world operation.
Quote:
Developers who attended the "meet the playbook" events in the last few days just found out about AIR apps' access to native c++ extensions (and it is not based on Adobe's Alchemy).
Do rhese extensions use anything like OpenCL to maximize usage of the multiple cores, GPU and DSPs?
Is an OpenCL facility available to native QNX apps.
I ask for 2 reasons:
1) RIM appears to have addressed perfornmance concerns by throwing hardware at the problems... At least initially.
2) It appears * likely that Apple's next iPad will have similar, or better, hardware -- with support for OpenCL to allow the system and apps to better exploit the hardware.
* Many recent iOS SDK additions appear to support more robust hardware with support for OpenCL
At the same time, the next iPhone, may not require the same level of hardware -- single-core CPU, 512 MB RAM, lesser GPU.
Then the fact that the co-CEO of RIM says that the Blakberry migration to QNX depends on PlayBook class, dual-core CPU, etc. This is disturbing because current smartphones do a lot more with a lot less hardware -- and the BB app set is basicly a browser, special mail and messaging apps, and a few others. This implies that the QNX implementation has a very high minimum hardware spec.
Check the settlement --- $23 million, not a lot of money.
try to get any bill out of gate is not easy. More on the fact someone is admit at fault. BeOS did have advantages that competitor willing to risk "wrong doing" to copy it. (settlements are few years back after Be is gone... not much string can pull at the time.. However, just want to point it out: technology superiority may never be recognized with someone like you around to trash it, when nobody around to defend them.... Sad. Move on. Got big fish to catch now.)
try to get any bill out of gate is not easy. More on the fact someone is admit at fault. BeOS did have advantages that competitor willing to risk "wrong doing" to copy it. (settlements are few years back after Be is gone... not much string can pull at the time.. However, just want to point it out: technology superiority may never be recognized with someone like you around to trash it, when nobody around to defend them.... Sad. Move on. Got big fish to catch now.)
I wasn't trashing Be at all. But the fact is that most people had a over-nostalgic view of BeOS --- because they were comparing it with Windows 95/98. Of course, BeOS looked super cool when they compare it with an OS with a Windows 3.1 kernel.
When BeOS 5 came out for x86, Microsoft already launched Windows 2000 --- with the NT kernel, NTFS and everything else. Windows XP came out a year after that.
And in the dying days of the internet bubble, Sony spent about 18 months developing the BeIA-based eVilla. 3Com started their internet appliance development much later than Sony, 3Com just hired some QNX consultant (who mostly embed QNX on medical instruments) --- launched the Audrey within 6 months time. The funny thing was that 3Com already discontinued the Audrey by the time Sony launched the evilla. And the Audrey was able to use a slower CPU, fewer ROM memory, and fewer RAM memory than the evilla. That's real technology superiority that QNX was never recognized.
In a parallel universe where Apple bought BeOS and Amiga had the money to make a new OS based on the QNX Neutrino kernel --- Amiga would have kicked Apple's ass.
That sounds similar to the current implementation in iOS... Don't know about Android.
Unfortunately, the demos shown: HD video player in the bg plus a few others; browser dominating a core; give the impression that QNX handles all this seamlessly -- when, in fact they are contrived demos that don't represent real-world operation.
It is a contrived demo --- because RIM/QNX already stated that they are most likely going to give end-users the options in the video player to either reduce the frame-rate for the background video or to pause the video all together. The RIM VP even joked about it in the Rogers TabLife demo --- by saying that this is not how normal people operate (i.e. playing the video in the background).
Quote:
Originally Posted by Dick Applebaum
Do rhese extensions use anything like OpenCL to maximize usage of the multiple cores, GPU and DSPs?
Is an OpenCL facility available to native QNX apps.
QNX is a member of the OpenCL group at khronos, don't know if it's going to be available for the Playbook.
Quote:
Originally Posted by Dick Applebaum
Then the fact that the co-CEO of RIM says that the Blakberry migration to QNX depends on PlayBook class, dual-core CPU, etc. This is disturbing because current smartphones do a lot more with a lot less hardware -- and the BB app set is basicly a browser, special mail and messaging apps, and a few others. This implies that the QNX implementation has a very high minimum hardware spec.
With the 1 GHz androids with slow flash performance, Steve Jobs is right on that point. RIM decides to have a "full" internet experience of their next gen stuff, nothing to do with QNX requiring high minimum hardware spec.
RIM also gave a very subtle hint on their OS path when they said that they want a dual-core baseband. This is going to be an integrated application/baseband CPU --- which Marvell and Qualcomm are the only real choice. Cost less money --- just look at the iphone 4 teardown, the baseband processor has its own RAM that is separate from the application processor's RAM. Have better battery life --- anytime the signal has to travel through the circuit board to another physical chip, you are spending electricity.
Android with Qualcomm integrated application/baseband --- uses the OKL4 microkernel as an hypervisor. Then on top of the hypervisor, sits 2 OS --- the Android OS and the Qualcomm one which handles the radio. That's 3 operating systems for Quadroid vs. 1 QNX OS handling the same function for the Blackberry.
In a parallel universe where Apple bought BeOS and Amiga had the money to make a new OS based on the QNX Neutrino kernel --- Amiga would have kicked Apple's ass.
Now, Amiga, I have been told, made nice enough computers, but given that it is not so much about technology prowess but about user experience, I would say that whatever the choice, an Apple with SJ at the helm would probably have won based on Jobs' extreme focus on user experience.
Wouldn't RIM's presence and expertise in serving IT/Enterprise be an advantage over iPad/iPad2?
RIM has a strong presence in IT/Enterprise. However, I bet that pressure from employees has forced IT/Enterprise to explore other smartphones besides BlackBerry devices. Compared to three years ago, there is a lot more interest in the iPhone from IT departments.
Comments
........ Apple has been shipping multi-core systems for over a decade, their OS (both iOS and MacOSX) has been aggressively optimized for a multi-processor environment -- including OpenCL. Apple's dev tools and OS in this area are second to none, and in the hands of developers for ages.
The OS is one component of delivering a highly parallel solution. The apps are another. RIM isn't even pushing the apps, and their proposed solution to functionality squanders huge amounts of performance and efficiency when compared to native apps implemented in C/C++/ObjC and using technologies like GCD and OpenCL. And before dismissing OpenCL as a desktop technology, consider that from the outset it was designed to consider embedded devices... and for mobile applications........
Sad to think the IPad may get an OCL capable gpu before the MBA and other Macs that rely on Intel IGPs.
And Microsoft did pay the BeOS share holder money to settle the lawsuit. Check the fact and which one is "Larger"?
Check the settlement --- $23 million, not a lot of money.
The OS is one component of delivering a highly parallel solution. The apps are another. RIM isn't even pushing the apps, and their proposed solution to functionality squanders huge amounts of performance and efficiency when compared to native apps implemented in C/C++/ObjC and using technologies like GCD and OpenCL. And before dismissing OpenCL as a desktop technology, consider that from the outset it was designed to consider embedded devices... and for mobile applications, GPUs are some of the most power efficient devices available.
It really depends on what is really "native". When normal regular RIM Playbook AIR apps goes to the background when deactivate, the framerate drops to 4 frames per second (from the regular default framerate of 24 frames per second). The Playbook's video player still plays at full speed in the background in the demos --- because it's really a native QNX app in C/C++ with AIR just being a "windows manager". And regular QNX apps will work at full speed in the background in the Playbook --- until the developer explicitly reduces its speed. RIM hyped it as an "AIR" app because they were showing it at an Adobe event.
It really depends on what is really "native". When normal regular RIM Playbook AIR apps goes to the background when deactivate, the framerate drops to 4 frames per second (from the regular default framerate of 24 frames per second). The Playbook's video player still plays at full speed in the background in the demos --- because it's really a native QNX app in C/C++ with AIR just being a "windows manager". And regular QNX apps will work at full speed in the background in the Playbook --- until the developer explicitly reduces its speed. RIM hyped it as an "AIR" app because they were showing it at an Adobe event.
Are you saying that a bg AIR app will continuously consume resources (cycling) even when it is not doing anything? Isn't that a drain on resources and the battery?
Shouldn't the system participate in determinating the speed at which deacitivated apps can run? Say a bg app is compressing and uploading a video, and a fg app is capturing and/or playing a video. Would you want a bg app acting as a co-equal -- reducing the performance of a fg app and the GUI interaction?
What I am asking is:
-- don't the apps, including system apps like the browser, need the intelligence to request full or reduced services determined by whether they are running bg or fg?
-- If yes, how does an app do this?
-- doesn't the OS need to govern the resources that bg apps get based on what else is going on the system?
If, not, why wouldn't each app assume full resources are available and try to monopolize them -- as the PlayBook browser appesrs to do...
... And because of the above (all apps are equal) that resources are proportionately divided among bg and fg apps
... Or the apps, like the browser are designed to run on a single core
The easy thing to do is to design each app to run on a single core with all resources available and let the system control the resource usage by controlling the individual cores.
The PlayBook has 2 cores and a GPU. How/what does QNX do to handle, say, 3 or 4 bg apps competing for a single core?
Does QNX have the capability to utilize the GPU cores and any on board DSPs to distribute processes among apps running bg or fg?
If yes, how are these capabilities exposed to the developers -- certainly not through AIR!
Are you saying that a bg AIR app will continuously consume resources (cycling) even when it is not doing anything? Isn't that a drain on resources and the battery?
Shouldn't the system participate in determinating the speed at which deacitivated apps can run? Say a bg app is compressing and uploading a video, and a fg app is capturing and/or playing a video. Would you want a bg app acting as a co-equal -- reducing the performance of a fg app and the GUI interaction?
What I am asking is:
-- don't the apps, including system apps like the browser, need the intelligence to request full or reduced services determined by whether they are running bg or fg?
-- If yes, how does an app do this?
-- doesn't the OS need to govern the resources that bg apps get based on what else is going on the system?
If, not, why wouldn't each app assume full resources are available and try to monopolize them -- as the PlayBook browser appesrs to do...
... And because of the above (all apps are equal) that resources are proportionately divided among bg and fg apps
... Or the apps, like the browser are designed to run on a single core
The easy thing to do is to design each app to run on a single core with all resources available and let the system control the resource usage by controlling the individual cores.
The PlayBook has 2 cores and a GPU. How/what does QNX do to handle, say, 3 or 4 bg apps competing for a single core?
Does QNX have the capability to utilize the GPU cores and any on board DSPs to distribute processes among apps running bg or fg?
If yes, how are these capabilities exposed to the developers -- certainly not through AIR!
It depends on what kind of apps you are making. RIM/QNX recommends that if your apps don't have to use resources, then save your state and get the hell out of the way so that other apps can use the resources. The OS can still kill your app.
With respect to background apps, I may have worded my comments too loosely. Remember QNX is a hard realtime OS, there is never going to be co-equals. Your foreground app will never eat too much resources so that people can still make a phone call. The background app will never eat too much resources so that the GUI will still operate smoothly.
Developers who attended the "meet the playbook" events in the last few days just found out about AIR apps' access to native c++ extensions (and it is not based on Adobe's Alchemy).
It depends on what kind of apps you are making. RIM/QNX recommends that if your apps don't have to use resources, then save your state and get the hell out of the way so that other apps can use the resources. The OS can still kill your app.
That sounds similar to the current implementation in iOS... Don't know about Android.
With respect to background apps, I may have worded my comments too loosely. Remember QNX is a hard realtime OS, there is never going to be co-equals. Your foreground app will never eat too much resources so that people can still make a phone call. The background app will never eat too much resources so that the GUI will still operate smoothly.
Unfortunately, the demos shown: HD video player in the bg plus a few others; browser dominating a core; give the impression that QNX handles all this seamlessly -- when, in fact they are contrived demos that don't represent real-world operation.
Developers who attended the "meet the playbook" events in the last few days just found out about AIR apps' access to native c++ extensions (and it is not based on Adobe's Alchemy).
Do rhese extensions use anything like OpenCL to maximize usage of the multiple cores, GPU and DSPs?
Is an OpenCL facility available to native QNX apps.
I ask for 2 reasons:
1) RIM appears to have addressed perfornmance concerns by throwing hardware at the problems... At least initially.
2) It appears * likely that Apple's next iPad will have similar, or better, hardware -- with support for OpenCL to allow the system and apps to better exploit the hardware.
* Many recent iOS SDK additions appear to support more robust hardware with support for OpenCL
At the same time, the next iPhone, may not require the same level of hardware -- single-core CPU, 512 MB RAM, lesser GPU.
Then the fact that the co-CEO of RIM says that the Blakberry migration to QNX depends on PlayBook class, dual-core CPU, etc. This is disturbing because current smartphones do a lot more with a lot less hardware -- and the BB app set is basicly a browser, special mail and messaging apps, and a few others. This implies that the QNX implementation has a very high minimum hardware spec.
Check the settlement --- $23 million, not a lot of money.
try to get any bill out of gate is not easy. More on the fact someone is admit at fault. BeOS did have advantages that competitor willing to risk "wrong doing" to copy it. (settlements are few years back after Be is gone... not much string can pull at the time.. However, just want to point it out: technology superiority may never be recognized with someone like you around to trash it, when nobody around to defend them.... Sad. Move on. Got big fish to catch now.)
try to get any bill out of gate is not easy. More on the fact someone is admit at fault. BeOS did have advantages that competitor willing to risk "wrong doing" to copy it. (settlements are few years back after Be is gone... not much string can pull at the time.. However, just want to point it out: technology superiority may never be recognized with someone like you around to trash it, when nobody around to defend them.... Sad. Move on. Got big fish to catch now.)
I wasn't trashing Be at all. But the fact is that most people had a over-nostalgic view of BeOS --- because they were comparing it with Windows 95/98. Of course, BeOS looked super cool when they compare it with an OS with a Windows 3.1 kernel.
When BeOS 5 came out for x86, Microsoft already launched Windows 2000 --- with the NT kernel, NTFS and everything else. Windows XP came out a year after that.
And in the dying days of the internet bubble, Sony spent about 18 months developing the BeIA-based eVilla. 3Com started their internet appliance development much later than Sony, 3Com just hired some QNX consultant (who mostly embed QNX on medical instruments) --- launched the Audrey within 6 months time. The funny thing was that 3Com already discontinued the Audrey by the time Sony launched the evilla. And the Audrey was able to use a slower CPU, fewer ROM memory, and fewer RAM memory than the evilla. That's real technology superiority that QNX was never recognized.
In a parallel universe where Apple bought BeOS and Amiga had the money to make a new OS based on the QNX Neutrino kernel --- Amiga would have kicked Apple's ass.
That sounds similar to the current implementation in iOS... Don't know about Android.
Unfortunately, the demos shown: HD video player in the bg plus a few others; browser dominating a core; give the impression that QNX handles all this seamlessly -- when, in fact they are contrived demos that don't represent real-world operation.
It is a contrived demo --- because RIM/QNX already stated that they are most likely going to give end-users the options in the video player to either reduce the frame-rate for the background video or to pause the video all together. The RIM VP even joked about it in the Rogers TabLife demo --- by saying that this is not how normal people operate (i.e. playing the video in the background).
Do rhese extensions use anything like OpenCL to maximize usage of the multiple cores, GPU and DSPs?
Is an OpenCL facility available to native QNX apps.
QNX is a member of the OpenCL group at khronos, don't know if it's going to be available for the Playbook.
Then the fact that the co-CEO of RIM says that the Blakberry migration to QNX depends on PlayBook class, dual-core CPU, etc. This is disturbing because current smartphones do a lot more with a lot less hardware -- and the BB app set is basicly a browser, special mail and messaging apps, and a few others. This implies that the QNX implementation has a very high minimum hardware spec.
With the 1 GHz androids with slow flash performance, Steve Jobs is right on that point. RIM decides to have a "full" internet experience of their next gen stuff, nothing to do with QNX requiring high minimum hardware spec.
RIM also gave a very subtle hint on their OS path when they said that they want a dual-core baseband. This is going to be an integrated application/baseband CPU --- which Marvell and Qualcomm are the only real choice. Cost less money --- just look at the iphone 4 teardown, the baseband processor has its own RAM that is separate from the application processor's RAM. Have better battery life --- anytime the signal has to travel through the circuit board to another physical chip, you are spending electricity.
Android with Qualcomm integrated application/baseband --- uses the OKL4 microkernel as an hypervisor. Then on top of the hypervisor, sits 2 OS --- the Android OS and the Qualcomm one which handles the radio. That's 3 operating systems for Quadroid vs. 1 QNX OS handling the same function for the Blackberry.
In a parallel universe where Apple bought BeOS and Amiga had the money to make a new OS based on the QNX Neutrino kernel --- Amiga would have kicked Apple's ass.
Now, Amiga, I have been told, made nice enough computers, but given that it is not so much about technology prowess but about user experience, I would say that whatever the choice, an Apple with SJ at the helm would probably have won based on Jobs' extreme focus on user experience.
Wouldn't RIM's presence and expertise in serving IT/Enterprise be an advantage over iPad/iPad2?
RIM has a strong presence in IT/Enterprise. However, I bet that pressure from employees has forced IT/Enterprise to explore other smartphones besides BlackBerry devices. Compared to three years ago, there is a lot more interest in the iPhone from IT departments.