[nwlieb]

Is this a 1-1 comparison? If the ARM compile is compiling to ARM binaries then there might be less work/optimizations since it is a newer architecture. Seems like a test with two variables that changed. Would be interesting to see them both cross-compile to their respective opposite archs.

[mlyle]

Maybe not, but A) it's close-- most of the work of compiling is not microarchitecture-level optimizations or emitting code, and B) if you're a developer, even if some of the advantage is being on an architecture that it's easier to emit code for... that's still a benefit you realize.

It's worth noting that cross-compiling is definitely harder in many ways, because you can't always evaluate constant expressions easily at compile-time in the same way your runtime code will, etc, too, and have to jump through hoops.

[throwaway894345]

As someone who knows relatively little about this, I'm very curious why this is downvoted. It seems like a rebuttal would be enlightening.

[marmaduke]

Hm my experience was that compiling C on arm was always super fast compared to x86, because the latter had much more work to do.

[mlyle]

This doesn't align with my experience. Clang is about the same, but GCC often seems much slower emitting cross-ARM code.

  jar% time x86_64-linux-gnu-gcc --std=c99 -O3 -c insgps14state.c -I inc -I ../../shared/api
  x86_64-linux-gnu-gcc --std=c99 -O3 -c insgps14state.c -I inc -I   0.97s user 0.02s system 99% cpu 0.992 total
  jar% time x86_64-linux-gnu-gcc --std=c99 -O3 -c insgps14state.c -I inc -I ../../shared/api
  x86_64-linux-gnu-gcc --std=c99 -O3 -c insgps14state.c -I inc -I   0.93s user 0.03s system 99% cpu 0.965 total
  jar% time x86_64-linux-gnu-gcc --std=c99 -O3 -c insgps14state.c -I inc -I ../../shared/api
  x86_64-linux-gnu-gcc --std=c99 -O3 -c insgps14state.c -I inc -I   0.94s user 0.01s system 99% cpu 0.947 total
  jar% time x86_64-linux-gnu-gcc --std=c99 -O3 -c insgps14state.c -I inc -I ../../shared/api
  x86_64-linux-gnu-gcc --std=c99 -O3 -c insgps14state.c -I inc -I   0.92s user 0.04s system 99% cpu 0.955 total

  jar% time arm-linux-gnueabihf-gcc --std=c99 -O3 -c insgps14state.c -I inc -I ../../shared/api
  arm-linux-gnueabihf-gcc --std=c99 -O3 -c insgps14state.c -I inc -I   1.43s user 0.03s system 99% cpu 1.458 total
  jar% time arm-linux-gnueabihf-gcc --std=c99 -O3 -c insgps14state.c -I inc -I ../../shared/api
  arm-linux-gnueabihf-gcc --std=c99 -O3 -c insgps14state.c -I inc -I   1.46s user 0.03s system 99% cpu 1.486 total
  jar% time arm-linux-gnueabihf-gcc --std=c99 -O3 -c insgps14state.c -I inc -I ../../shared/api
  arm-linux-gnueabihf-gcc --std=c99 -O3 -c insgps14state.c -I inc -I   1.55s user 0.04s system 99% cpu 1.587 total
  jar% time arm-linux-gnueabihf-gcc --std=c99 -O3 -c insgps14state.c -I inc -I ../../shared/api
  arm-linux-gnueabihf-gcc --std=c99 -O3 -c insgps14state.c -I inc -I   1.44s user 0.03s system 99% cpu 1.471 total

[marmaduke]

That’s interesting. I was not cross compiling so maybe the arm system I was using was just faster.

[fomine3]

So cross compile for RISC-V, POWER, or something else would be fair?

[attractivechaos]

Apple has been optimizing the compiler for a decade for iOS.

[freehunter]

If everything else is the same, that seems like a solid reason to prefer the ARM architecture even setting aside 1:1 comparisons. Isn't faster compilation and execution the whole point of a faster processor?

[kag0]

The assertion is that compilation might be faster since there are fewer optimizations, and therefore runtime would be slower.