[dmitrygr]

A53 is not a great core, and seemingly no compiler targets it well. Back at el goog, ChromeOS team had an intern who used a cycle-accurate model of it to find that android's AOT compiler produced shit code for it when multiplies were involved. A small patch to the AOT compiler produced measurable perf improvement in most android workloads on A53, costing no perf on A57/A72. This patch was, of course, not shipped (politics).

[BoingBoomTschak]

Could you expand on the "politics" part? I can't imagine the reason why. I mean, if you had said "suits thought this wasn't business relevant" or something, I'd have believed it.

[dmitrygr]

The intern was in the ChromeOS team, the fix would have needed to go into android. Those two teams were always in a bit of "stay in your lane, buddy" relationship.

[saagarjha]

I continue to maintain that Google should adopt negative peer bonuses

[mtklein]

"The peer malus" - Frederic Beal

[gessha]

And that will result increased tension between the teams “downvoting each other”.

Maybe this way Google will truly become a Microsoft-type of company.

[saagarjha]

Is it not there already?

[jjmarr]

I thought the fabled monorepo was supposed to prevent this?

[nullpoint420]

IIRC, both Android and Chrome(OS) upstream are not in the google3 monorepo.

[djmips]

The article also mentions how the llvm-mca is inaccurate for the A53. And furthermore LLVM compilers will do poorly

"...any compiler that is using LLVM to optimize machine code (such as the Rust compiler or clang) will not do very well for the A53, since it’s essentially trying to optimize code using a wrong CPU model. "