Whatever happened to CFluent ?
Some of you might remember me in the past months having mentioned a project ("CFluent", "see fluent", "CF-luent" ;)) to improve fluidity of the Android UI.
Indeed, aside from the stuff I actually release, I spend a lot of time prototyping and hacking together stuff that may not ultimately see release. CFluent is one of those projects.
As you are probably well aware, Android is not always as fluent as we would want (note that this has now largely been negated by the improvements in Jelly Bean (Project Butter), which was released after I prototyped CFluent). So I started mucking about with how threads and workloads could be balanced on a multi-core system to make this less apparent. I also wanted this to be installable on rooted devices, without requiring custom frameworks, ROMs, or kernels.
What I came up with, is separating all the UI threads from the non-UI threads, and making sure (most, if not all of) the non-UI threads ran on a different core. That way, the core running the UI thread could be fully dedicated to the UI thread, and doing little else.
Some testing, coding, more testing, more coding, etc later, this was somewhat working. And the results were.... not that bad, actually.
Under "normal" load, it did not seem like CFluent had any effect, but you started to run a lot of background processes, taking up CPU and I/O, with CFluent your foreground app would remain much more fluent than without CFluent. Yay! Win!
Unfortunately for CFluent, and fortunately for the rest of us, that situation isn't actually all that common. One thing I have learned in this exercise that the reason the interface stutters or Android feels slow in general, is only very rarely due to the CPU being fully utilized. Yes - it does happen, but not as often as you would think.
So, in that way, CFluent wasn't actually all that useful except for certain circumstances. Add to that, that CFluent was not actually able to control (cross-SoC) when cores would be enabled/disabled. So CFluent was always "responsive" in nature instead of "orchestrating" control. As soon as a core switched on or off, CFluent would have to go through each and every running thread on the system again and decide on which core to run it. Same thing with switching threads.
Not to mention that CFluent actually does reduce benchmarking scores, because it would put the benchmark threads on different cores from the UI, preventing you from ever gaining 100% CPU utilization (in a well coded benchmark).
I'm not saying the idea doesn't work - I think it could still be beneficial. However, the idea would have to be implemented at kernel level (in a scheduler, maybe ?) and some changes would have to be made to Dalvik for it to be optimal, so the code in question would be fully aware of which threads belong to the UI, could control the cores, and aware of thread switches as they happen, instead of after the fact.
Aside from these drawbacks, a fair number of processes may not able to cope with their threads being switched between cores. This could cause all sorts of crashes. While it worked remarkably well on my SGS2, as well as the SGS3 I tested it on later, it constantly crashed programs and would often result in the device not waking up at all on all of the Galaxy Tab variants I have.
I was at Google I/O 2012, and after Romain Guy (one of the guys who make Android) held his session about Project Butter (making Jelly Bean more fluent than other Android versions) I was able to talk to him for a minute. I asked him if they also tried thread rescheduling in the manner I described above for better performance. Not quite unsurprisingly, they had looked at it, but dropped it because it created too many problems. Seems I'm not crazy after all :)
So, even though I spent quite some time and research on CFluent, it never has - and never will - be released. It was an interesting project to muck around with, though.
Who knows, after my holidays, I might throw the source code at you all just for fun. I'm actually considering publishing the source code for a lot of projects I no longer actively develop myself, and I may do that in the future. If I can find the time to clean them up a bit ...
Indeed, aside from the stuff I actually release, I spend a lot of time prototyping and hacking together stuff that may not ultimately see release. CFluent is one of those projects.
As you are probably well aware, Android is not always as fluent as we would want (note that this has now largely been negated by the improvements in Jelly Bean (Project Butter), which was released after I prototyped CFluent). So I started mucking about with how threads and workloads could be balanced on a multi-core system to make this less apparent. I also wanted this to be installable on rooted devices, without requiring custom frameworks, ROMs, or kernels.
What I came up with, is separating all the UI threads from the non-UI threads, and making sure (most, if not all of) the non-UI threads ran on a different core. That way, the core running the UI thread could be fully dedicated to the UI thread, and doing little else.
Some testing, coding, more testing, more coding, etc later, this was somewhat working. And the results were.... not that bad, actually.
Under "normal" load, it did not seem like CFluent had any effect, but you started to run a lot of background processes, taking up CPU and I/O, with CFluent your foreground app would remain much more fluent than without CFluent. Yay! Win!
Unfortunately for CFluent, and fortunately for the rest of us, that situation isn't actually all that common. One thing I have learned in this exercise that the reason the interface stutters or Android feels slow in general, is only very rarely due to the CPU being fully utilized. Yes - it does happen, but not as often as you would think.
So, in that way, CFluent wasn't actually all that useful except for certain circumstances. Add to that, that CFluent was not actually able to control (cross-SoC) when cores would be enabled/disabled. So CFluent was always "responsive" in nature instead of "orchestrating" control. As soon as a core switched on or off, CFluent would have to go through each and every running thread on the system again and decide on which core to run it. Same thing with switching threads.
Not to mention that CFluent actually does reduce benchmarking scores, because it would put the benchmark threads on different cores from the UI, preventing you from ever gaining 100% CPU utilization (in a well coded benchmark).
I'm not saying the idea doesn't work - I think it could still be beneficial. However, the idea would have to be implemented at kernel level (in a scheduler, maybe ?) and some changes would have to be made to Dalvik for it to be optimal, so the code in question would be fully aware of which threads belong to the UI, could control the cores, and aware of thread switches as they happen, instead of after the fact.
Aside from these drawbacks, a fair number of processes may not able to cope with their threads being switched between cores. This could cause all sorts of crashes. While it worked remarkably well on my SGS2, as well as the SGS3 I tested it on later, it constantly crashed programs and would often result in the device not waking up at all on all of the Galaxy Tab variants I have.
I was at Google I/O 2012, and after Romain Guy (one of the guys who make Android) held his session about Project Butter (making Jelly Bean more fluent than other Android versions) I was able to talk to him for a minute. I asked him if they also tried thread rescheduling in the manner I described above for better performance. Not quite unsurprisingly, they had looked at it, but dropped it because it created too many problems. Seems I'm not crazy after all :)
So, even though I spent quite some time and research on CFluent, it never has - and never will - be released. It was an interesting project to muck around with, though.
Who knows, after my holidays, I might throw the source code at you all just for fun. I'm actually considering publishing the source code for a lot of projects I no longer actively develop myself, and I may do that in the future. If I can find the time to clean them up a bit ...
