Arm Has Been Working To Boost The Chrome/Chromium Browser Performance

[archsway]

As nice as PI 4 is I don’t see it becoming a desktop replacement anytime soon. It just doesn’t have the performance no matter the optimization. Beyond that there is a bit of ignorance within the PIotganziation when it comes to 64 bit software / operating systems. Life is far easier when the platform owner drives forward with the latest software features.

And what advantages would 64-bit bring other than faster amd64 emulation?

Do you have any statistics proving how much aarch64 is faster than aarch32?

Can you list any important desktop workloads requiring long doubles?

Is anyone really going to care that much about how far they can zoom in in Xaos?

[squash]

As nice as PI 4 is I don’t see it becoming a desktop replacement anytime soon. It just doesn’t have the performance no matter the optimization. Beyond that there is a bit of ignorance within the PIotganziation when it comes to 64 bit software / operating systems. Life is far easier when the platform owner drives forward with the latest software features.

One only needs to look at Apple to see the positive impact of forcing developers to the 64 bit world.

Pi 4 with Ubuntu's 64 bit 19.10 image is pretty darn usable and substantially faster than when running a 32 bit OS. The Rasbian image lags behind but is a single image supporting every Pi model to date. The rumors of an 8GB version, if true, would go a long way towards that goal.

[ms178]

There is also value in understandable, easy to debug code. I have no idea what the ZLibs thought processes are with respect to optimized code, but I would not be surprised that maintainability and correctness are high on their list. Which makes me wonder how much effort the ARM team has put into validating their submissions.

Pardon me, but is there value in slow code? And what makes you assume that optimized code is not understandable or harder to debug? Have you seen their presentation? Google/Chromium ships this optimized Zlib (which is also optimized for x86-64) in various different forms and roles to millions of devices. I'd say you can't get better testing than this.

And I am sure the ARM developers would have made changes neccessary. Just read their pull requests, he is basically talking to himself there because the upstream maintainer didn't even find the time to look at it and answer him. For two years. That's just sad.

[starshipeleven]

Pardon me, but is there value in slow code?

Small nitpick, I agree on what you said:
slow code is fine for non-performance-critical parts of the application. Optimization can take time and resources, and changing code will introduce new bugs, so it may not be worth it.

This is obviously not the case AT ALL here because a compression/decompression library's whole purpose is have the best performance code in it.