General Code Compile - Who's it For?

As I had mentioned, one big advantage of having an Arm system like this is the fact that it enables your native software development, without having to worry about cross-compiling code and all of the kerfuffle that that entrails.

For me personally, one issue had been the fact that we need to compile our SPEC test suite for Arm architectures, which isn’t all that evident when you don’t have a native machine to test things on.

Still, I had been able to configure a proper cross-compile setup- in this case GCC9 on an x86 machine (AMD Ryzen 3700X) cross-compiling for an AArch64 target, versus natively compiling the same target with the same compiler on the eMAG workstation.

Native vs Cross-Compile (Andrei's SPEC setup)

The first thing I noted when compiling things on the eMAG system, is that it took quite an enormous amount of time for linking together the libraries and executables. Unfortunately, this isn’t something that can be parallelised, and it ends up being a mostly single-thread performance bottlenecked part of software development.

Although the eMAG system does have more processing power than your average consumer system, it’s unlikely for this to actually materialise in the average development environment due to the massive singe-threaded performance disadvantage of the system.

In my case, my personal desktop machine outperformed the eMAG system in this one use-case by a factor of >2x.

My personal view on this is that if I were to be trying to port a piece of software to Arm, assuming that the act of cross-compiling itself isn’t an inherent issue, then I would probably prefer to simply cross-compile things on my regular x86 machine and deploy and test it on a lower-end embedded Arm board.

The only real audience who could rationalise the system performance deficit for its architectural flexibility would be developers who actually work on hardware enablement – using the SBSA system to its fullest for things like Arm driver development and making full use of the peripherals and PCIe capabilities of the system.

SPEC2017: OK-ish MT Performance Conclusion - All Eyes on an Altra System
Comments Locked

35 Comments

View All Comments

  • mode_13h - Sunday, May 24, 2020 - link

    Heh, yeah. Hopefully, just a typo.
  • mode_13h - Sunday, May 24, 2020 - link

    Cool review. Thanks.

    If you'd asked me 5-7 years ago, I thought I'd already be running an ARM-based server or workstation, by now. Maybe I was off by a few years?

    Anyway, I think we'll look back on this as a milestone. It's not the very first ARM-based workstation I've seen (for that, check out https://www.phoronix.com/scan.php?page=article&... ), but certainly the most compelling.
  • KAlmquist - Monday, May 25, 2020 - link

    Linking is, in principle, pretty parallelizable. Static libraries are a problem for parallel linking because you have to know which symbols are referenced but not defined by files preceding the library before you can determine which object files in the library are needed, but these days people use shared libraries instead of static libraries. Generating the memory layout is a single threaded operation, but a quick one.

    There are a lot of companies that would benefit from the existence of a parallelized linker. Avantek would have a more compelling product. Any company that does lots of software development would benefit from shorter build times. So I expect that eventually someone will fund the development of such a linker.
  • schm121 - Tuesday, May 26, 2020 - link

    We always enjoy your articles its inspired a lot by reading your articles day by day. So please accept my thanks and congrats for success of your latest series.
    https://www.schmhyd.edu.in/
  • futurepastnow - Thursday, June 11, 2020 - link

    The next Mac Pro?

Log in

Don't have an account? Sign up now