Pinephone is the perfect reason to fix bad code.
The PINE64 Pinephone is by no means a fast device.
Equipped with the Allwinner A64 SoC, it features 4 Cortex-A53 cores manufactured using the old-at-release and ancient-by-today 40nm process node, running at whopping 1152 MHz. Helping the modest CPUs is the equally, if not more, poor Mali400-MP2 GPU. A64 features a few more little-exciting components, such as a LPDDR2/3 DRAM controller and the Cedrus video encoder/decoder acceletator. It has one giant advantage though - the chip price is $5.
The device comes in 2/16 or 3/32 RAM/eMMC configurations and outputs 0s and 1s to a 1440x720 (18:9/2:1) LCD.
As you can see, it’s no Ampere Q80-30, but we’ve seen worse hardware out there (I see you, crazy people using Raspberry Pi 1 tablets).
This leads us to two things:
- the software feels slow
- power consumption can get through the roof
While the second part is largely a hardware thing, we cannot underestimate the fact that badly written software will require more computations, meaning the CPU has to crunch more numbers, meaning it has to eat up more powah.
The first one.. yeah.. it’s not hard to imagine that many [Linux] apps, often carrying a 20+ years of legacy have some drawbacks.. This is especially the case with desktop environents. A huge amount of work has been done to get the likes of KDE Plasma anywhere near usable on the Pinephone (it’s much better now than what it used to be), but more work is needed for a truly enjoyable experience. Such desktop environments have many dependencies and are overall pretty complex pieces of software, expanding almost every day. Sadly, with so much attention given to features, the performance is often getting overlooked. And for a good reason. Most desktop computers and laptops from the past 10 years are plenty powerful for a developer, not to mention the average user. The difference between O(n) and O(n^2) might not be apparent to an i5 2500K user, but it surely will be to the Piner, waiting tirelessly for his dialer to come up… No wonder some people started an effort to put a tiling WM on the phone, so that it feels snappier!
The truth is, we failed. We went for fancy graphics and ease of adding new features over focusing on making sure that the programs run well on bad hardware and exceptionally well on good machines. A great counter-example of this is p-boot, a bootloader which lets you reach your Linux desktop in literal three or four seconds from a cold boot (meaning the device is powered off). It does its job really well, has some extra features (for example “Privacy mode”, which shuts down the radios before you boot into Linux) and doesn’t make the user question the software state.
But it’s not too late. We can still fix our mistakes by profiling programs that seem slow (and these that don’t, things may be hiding underneath!), or even the Linux kernel itself (it’s not free from [performance] regressions either..) and either fixing them ourselves or reporting our findings upstream, so that others can look into it. There’s also compiler optimizations, which have come a long way (-O3 is not even a crazy choice these days and LTO is used even in production Linux kernel builds [on Android devices]).
I have a powerful desktop (with a Ryzen 2700X) and I can tell some programs are underwhelmingly slow, even though they don’t seem to do anything complex. And that’s on x86, the platform that has been the center of attention for the past [too many] years. Now, with ARM64 coming into the mainstream (thanks Apple, somebody finally did it well), we have a crazy amount of room for improvement. What better way to market Linux to the masses than to show that it can perform all tasks faster and more efficiently.
Please, let’s fix the code that we use on a daily basis. Waste some time once on finding the culprit instead of wasting everyone’s time on needlessly waiting.