8 ms·

Coding Neon Kernels for the Cortex-A53

• dmitrygr 1y ago
  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 1y ago
    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 1y ago
      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 1y ago
        I continue to maintain that Google should adopt negative peer bonuses
        • mtklein 1y ago
          "The peer malus" - Frederic Beal
        • gessha 1y ago
          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 1y ago
            Is it not there already?
      • jjmarr 1y ago
        I thought the fabled monorepo was supposed to prevent this?
        • nullpoint420 1y ago
          IIRC, both Android and Chrome(OS) upstream are not in the google3 monorepo.
  • djmips 1y ago
    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. "