Suggestion: better performing pinephone

[nodoze]

Hi folks,

are you sure we need a "stronger" phone?
Maybe we just should invest more time and energy in software-optimisation to get maximum performance out of this little devil
I'm sure it's possible to get the software running 10 times faster just by optimization ... so would this fulfil your "need for speed"?

What do you think? Any ideas?

Let me start the list:

1) Lets optimize the UI-driver stuff for the Pine-Phone hardware.
2) The stage is yours .....

Best regards,
Andrew >:o)

I think increased Software Optimization is great but still don't understand why having multiple options and/or choice is bad.

On one hand because stronger usually means more expensive ...
and on the other hand I think we have to do something against these "planned obsolescence" problem.

If we use our resources - a mobile phone for instance - with more care we safe our environment in the long term and a lot of money in the short term -> win -win situation
For instance - would you buy a new car if just by doing a service it will run as fast as new?

Trust me, I know what's possible just by doing the right Software-Optimizations, because I've done this in the past many times on my dally job.
You wouldn't believe what's possible

And maybe you guys can add some further ideas to move forward in that direction?

Best regards from Vienna,
Andrew >:o)

This is the 'Pinephone Hardware' subforum;
I will gladly use the 'Pinephone Software' subforum to make any Software Optimization recommendations I have there.

I won't be going into the 'Pinephone Software' subforum and telling threads that are pursuing software solutions &/or alternatives that hardware is the only acceptable question to be asked nor that Hardware is the only answer.

Some of us want to do things with Linux Phones that the Pinephone will never be able to do because of the hardware limitations no matter how well you optimize the software.  Some of us want true convergence and want to be able to do advanced containers, virtualization, & more which do require software but also require hardware that is expandable and it is not just about the Central Processing Unit (CPU) core speed...

My understanding is that at decently sized order quantities the i.MX-8M System on a Chip (SoC) chosen for the Libram 5 costs ~$20/chip while the A64 CPU chosen for the PinePhone is ~$5.

iMX-8M supports upto 8GB RAM (faster LPDDR4);
A64 only supports upto 3GB RAM (slower LPDDR3);

iMX-8M supports upto USB 3.0 (upto 10x faster);
A64 only supports upto USB2.0;

iMX-8M supports +20MP Cameras;
A64 only supports upto 5MP Cameras;

iMX-8M is a true 64bit SoC;
A64 is only 64bit on the CPU cores but 32bit elsewhere;

Graphics subsystems on the iMX-8M is several generations more capable than the A64...
iMX-8M supports 4K Video out at 60 FPS for convergence;
A64 only supports 1080p Video out;

etc...

A $15 increase in base CPU cost ($20-$5) would have allowed a much broader platform and spectrum of device options.   Sure start with a lowest cost option but not be stuck there...

I am all for low cost development options with minimal/slower RAM and cheaper initial components but wish the PinePhone wasn't locked into such low specs with no upgrade path and no options for increased specs.