SoCs that have only A53 cores are terribly slow. Recently played with a Motorola Moto G22 phone with a Mediatek Helio G37. The phone has a nice design, 5 cameras, enough RAM and storage (4GB/64GB), but the UI is laggy and slow, installing and lunching apps, rendering web pages takes a lot of time.
This core is ideal to be replaced in low power platforms like SMB routers that run on MIPS (MT7621). I think Qualcomm and Mediatek is extensively using these in router SOCs which previously were based on MIPS. These cores are probably less 'application' cores and a more designed towards low power helping cores. For example QC uses network accelerators along with the cores. Anything gigabit and beyond still requires bigger ARM cores or Intel but below gigabit these are not bad.
Not trying to justify phone manufacturers not putting in the effort to optimize their software, but one way around the slow UIs is to go into the Developer Settings and turn the UI animation speed to 0x. It's a setting I've always enabled on my Android phones when I used to use them.
It's sad that Android doesn't automatically fall back to a simpler GUI which takes less time to render. Even Windows XP (2000, 98?) got this right (with manual settings).
Even an A53 is a super computer when it comes to graphics compared to CPUs of yore.
A serious improvement on these budget phones is turning animations completely off, it removed most of the stuttering and GPU usage doesn't spike just pulling up the keyboard.
Android doesn't automatically fall back to a simpler GUI
How much simpler can it be, given that everything seems to already be flat and borderless? As your last sentence alludes to, Windows and other desktop OSs worked perfectly fine with far more complex UIs (including windows) on far less powerful hardware. Mobile UIs seem to be quite primitive in comparison.
In other words, this is entirely a software problem.
A visually simpler GUI (such as Luna vs. "classic" on Windows XP) isn't necessarily less resource-intensive. Implementing an actual different, less resource-intensive rendering path could help, but would double the development effort.
Nope... I'm using a tiny SBC, a Radxa Zero with a A53 Cpu, with Manjaro Linux, as a ultra low power daily driver and it is perfectly usable for light browsing, programming or productivity.
It boots Linux in 7 seconds and xfce desktop is pretty snappy.
Kernel is 6.1 and RAM is only 4GB.
Opens Lazarus almost instantly and FPC compiles ARM binaries super fast.
Agreed. I'm perfectly happy to have a couple of A53s in my phone for background tasks. Four feels a bit overkill but okay, maybe it makes the big.LITTLE design work better.
But I've always been disappointed by devices that are all A53s.
And when I see devices that have eight A53s and nothing else, I have to assume that they are just trying to trick people into thinking it's a more powerful device than it actually is.
>I have to assume that they are just trying to trick people into thinking it's a more powerful device than it actually is
Why would you think that people who actually look up and care about the hardware at the same time are unable to read the first sentence on wikipedia and have no idea what it is? Do you really believe that customers of $100 budget phones are tricked into powerful performance?
Oddly enough, a very sizeable portion of customers seem to be aware of core numbers and "memory" size (often confused with disk size, though). The i3-5-7 naming scheme is also pretty widely understood. I used to work at an electronics store when I was a teenager (6-7 years ago, so not that long ago!) and that kind of made it a struggle to steer people who knew just enough to hurt themselves into buying an actually good product. I mean, that MediaTek is an 8 core CPU so why was I trying to sell him a 2/4cores Qualcomm? Or they'd buy a laptop with a Celeron and barely enough flash to fit Windows, but it was a quad core! Obviously better than the 2 core i3 that actually has space to install software lol.
I'd guess 25% of customers knew about those at a superficial level, and another 10% actually knew what they should be looking for.
I’d guess there are a lot of people who see “eight-core CPU!” and don’t research any further. Same way that PC buyers used to stare at GHz and ignore the total performance of the CPU.
It's not entirely their fault either. Manufacturers know what spec people are more aware of and include that in their product and make it front and center. It's more common than I'd hope to have a laptop with an APU paired with a separate GPU that is barely better than the one inside the APU. But people go "gaming, so dedicated gpu" and buy the product. What a waste all around.
I would not call the Redmi Note 5 (SD626) I've been using for the last 4 years "terribly slow", instead I call it "perfectly useable". This whole "laggy UI" thing people complain about is beyond me, the UI is GPU rendered and keeps up with most of what I throw at it. I don't expect a low-power device I charge every 3d day to perform like a mains-connected system.
> I would not call the Redmi Note 5... "terribly slow", instead I call it "perfectly useable".
The software you use plays a rather large role in how the hardware performs. Some people here like to live on the OEM-designed happy path, where things tend to just work. That means using Google Apps for everything, an expectation that the latest video streaming social platforms will open quickly and not stutter, and scrolling the Google Play Store or Google Maps will be a fluid experience.
Others may use simpler apps, or expect less of their phones. I'm in the latter category, and I suspect you are as well. While the BlackBerry KeyOne I use daily was panned by some six months after release in 2017 for being too slow, I instead killed off nearly everything else that would run in the background - including and specifically any Google frameworks and apps.
Some software companies have made a point of taking any hardware gains for granted. Most people have new phones, with fast processors, so some companies will push devs to take shortcuts. I'm quietly indignant about that, though that rant is rather tangental to your original question about how some have such different experiences from yours.
You may not expect desktop-class performance, though others do. Display scrolling on a mobile handset is an indicator of quality that separates cheap devices from those that one might actually want to use to get work (or play) done.
The thing is that the display scrolls without any hiccups on this device. Pulling down the notification shade is always fluent, gestures work without hiccups, controls appear and disappear fluently. The UI is not where these devices tend to show their lack of performance, for that you need to open a browser and load some heavily javascript-encumbered sites. As an example I use OpenHAB with some embedded (live) Grafana charts for control and data visualisation. Opening the site or the app (which just embeds the site) on my device takes a second, on my wife's S23FE it appears a lot faster. Changing between pages on the site or app is also a lot faster on her device than on mine. Since I program the thing I like using a somewhat slower - but still perfectly useable - device as it makes sure anything I produce will be fast enough even on less than top of the line hardware. I follow the same creed when it comes to PC hardware by using older devices, it has always served me well.
Understood, though consuming the sausage (as an end user) is often a very different exercise than making it, so to speak. Battery tradeoffs are a real consideration for end consumers, though are not as much an issue within a development environment where the test device is tethered to the host development machine.
They are meant to be used in a big.LITTLE configuration. So the A53 cores should be active in the low-power mode, and more powerful cores should be active in high-power mode.
I'll bet that's due to slow storage, and not the CPU(s); I've done a few handsets and tablets and write performance was a large part of being laggy or not. It's quite obvious when the storage is full and the flash controller spends a lot of time doing RMW ops and halting writes.
Yep, this was also the case with my old phone. Opening apps took a while but after that, everything was more fluid afterwards and clearly indicated that storage played a part in the device's slowness. Though, the 1.5 GB ram and the quad-core Cortex-A7 still made the device pretty slow.
Don't think so - CPU and GPU are far more important for the speed and fluidity of UI than flash write speed.
Yes, if the storage is full it can kill both the performance and stability of Android, but devices with slow SoC are slow even with plenty of free space.
> but devices with slow SoC are slow even with plenty of free space.
We'd find during initial development (i.e., raw, bare Android) that the initial bring up would have good-to-excellent performance, but as the storage began to fill (more "stuff" in the baked-in system/cache partitions, user-installed apps, etc.) it would lag more and more. You'd be surprised how in the early kernels (2.6-3.x series) "iowait"s would slow everything down, UI included, and not just loading speed of apps and such.
