Surely designing and validating the CPU cores is meaningfully more expensive (and time consuming) than working with existing ARM IP?
Fewer faster cores is better for most single-user apps and OSs, not just JS engines, and when its not, GPUs are often a better option. So, the question then is why is Android in this sorry state, and what might the future hold?
How Did We Get Into This Mess?
I think that this is a result of an interplay between ARM’s business strategy, the strategy of SoC makers, and the marketing needs of Android phone vendors.
Android phone vendors are already at a disadvantage when competing with Apple because most lack the scale and integration of Apple, and therefore can’t control as much of the user experience. This situation lends itself to competing on specs.
Core-count and clockspeed are both numbers that can be flogged by phone makers against Apple, and against one another. Unfortunately, pushing clockspeed too far comes at the expense of an even more important spec: battery life.
The SoC makers need to deliver “improvements” at a suitable pace for the phone makers. Because of there are multiple players in the android market, a suitable pace is multiple times a year. Unfortunately for the SoC makers there are forces outside their control that limit the pace of meaningful improvements. As a result, they have resorted to gimmicks, like large core counts.
The forces outside the control of SoC makers are manifold. Perhaps the most fundamental is the pace of improvements in semiconductor fabrication technology. Moores “law” has had a good long run, and over that run, the economic and technological forces involved have ended up synchronizing around delivering new process nodes approximately every two years. In between, the main opportunity for performance improvements comes from architectural changes.
This brings us to the other force outside the control of most ARM SoC makers: They rely on ARM for CPU core designs. Qualcomm and NVIDIA are major exceptions. Both have their own CPU cores, but even so, they still reply on ARM for the CPU cores in many of their SoCs. For Qualcomm, this is apparently the result of having misjudged how aggressively Apple would pursue it’s own core designs. This strategic misstep left them without any high-end 64-bit offering for a time, and resulted in them turning to an ARM core design while they finish their own in-house 64-bit ARM core. For NVidia, it seems to be more the slow pace of their own program to develop in-house ARM cores.
Developing their own ARM cores is an expensive and long-running commitment. They have to acquire the appropriate license from ARM, hiring suitable staff, and commit to the long process of developing and validating an in-house CPU core design. The challenge of hiring should not be underestimated. It is pretty clear that the number of people who can be trusted in key roles in a program to develop a cutting-edge CPU core are quite limited; just witness the way certain key people have shifted around from Apple, AMD, etc.
I don’t think that people can expect ARM itself to develop a competitive high-performance core, because that undermines their relationship with architectural licensees, like Apple, Qualcomm and NVidia. The risk of alienating Apple is particularly high, I think, because Apple, which has core design, SoC design, device design, OS, developer tools, and application distribution under its control, can move to another instruction set architecture if need be. As a result, the core designs that can be licensed from ARM are likely to fall short of being leading edge.
What Might the Future Hold
So, given all this, what are the prospects for Javascript performance on Android, and what does it mean for Discourse?
It seems that, in the short term, things aren’t likely to get significantly better. My guess is that javascript engines aren’t suddenly going to get lots better on Android but maybe there are some low-hanging fruit for real-world apps (rather than just optimizations that look good on benchmarks). I don’t have a good sense for the uptake of upgrades in the Android world, but assuming that meaningful improvements for JS performance on Android are ready to go in 6 months, it is going to be at least another 6 months before they are widely deployed.
There will be new Android devices released, with new SoCs. There is no guarantee that they will have a marked improvement in single core performance, but it seems likely that, at some point soon, more cores will no longer be viable or acceptable, and that raw single-core performance will gradually improve. It will be years though before there are meaningful improvements in the raw single-core performance of the average Android device in the field.
In the longer term, there is also some chance that raw single performance in new devices makes a significant leap at some point when/if Qualcomm gets back in the swing of doing its own cores.
In the longer term, there is another possibility for Android devices with significantly improved single-core performance, non-ARM SoCs. I haven’t been keeping track of Intel’s efforts, but I know their mobile chips have good single-threaded performance, and I think they probably need to get a good foothold mobile market, or die trying. And then there is Imagination, which licenses the GPU cores used by Apple and other high-end SoC makers, and who recently bought MIPS.
One thing worth considering, that I don’t have a great sense of is the impact of demographic trends. If we assume that globally over, say, the next 4 years, Android will hold or gain market share against iOS because of cost considerations, what does that mean for the performance of mainstream android devices? Will most of those low-cost devices use old, lame SoCs and therefore lag the progress I predict/hope must come to Android single core performance, or will they at least see the same pace of performance improvements, even if they start from a relative disadvantage.
tl,dr, What Does this Mean for Discourse
As for Discourse, it seems to me that your assumptions should be that:
- JS performance on mainstream Android devices will always lag that in iOS mainstream by a significant degree for at least the next 3 years.
- JS performance in the android mainstream will gradually improve in absolute terms
- JS performance in the android mainstream may improve relative to iOS in the 1-3 year timeframe.
Recommendations based on the above:
- Don’t move away from Javascript
- Inform end-users of the problems in order to create incentives for browser and hardware makers to address the problem
- Based on usage stats, figure out the minimum current hardware/software you want to target.
- Identify and prioritize application-level performance problems that have the greatest impact on user experience for users in your target
- Fix those worth fixing.
- When in doubt, target performance improvements that yield gains on both android and iOS, followed by those that can be tuned based on platform / performance, etc (for example, the way you currently halve the amount of data sent to android clients)
- When possible, address issues by encouraging/supporting efforts to address them in libraries/frameworks you use (ie Ember).
- Repeat.
Update
but more tolerable.
Keep the good UX and people will keep using it is my guess.
problem (for Google) though is that somehow Safari has an about 40% edge over Chrome when it comes to running Ember stuff… on top of that Apple somehow managed to put Desktop level performance into people’s pockets with the 6S.
), I hope this list provides some points you can think about. Especially the Ember update should help!
)
(Does cost of 13 Pro Max + $350 get you a 14 Pro Max? 
