News for hackers. Stuff that matters.

A comment on 2020 Mac Mini – Putting Apple Silicon M1 To The Test. Parent comment

Re:2020 Mac Mini – Putting Apple Silicon M1 To The Test by mlyle on Tuesday November 17, 2020 @01:38PM (#25127724)
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.

[ Parent | on HN ]
Re:2020 Mac Mini – Putting Apple Silicon M1 To The Test by throwaway894345 on Tuesday November 17, 2020 @02:17PM (#25128312)
As someone who knows relatively little about this, I'm very curious why this is downvoted. It seems like a rebuttal would be enlightening.
[ Parent | on HN ]
Re:2020 Mac Mini – Putting Apple Silicon M1 To The Test by marmaduke on Tuesday November 17, 2020 @05:02PM (#25130549)
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.
[ Parent | on HN ]
Re:2020 Mac Mini – Putting Apple Silicon M1 To The Test by mlyle on Tuesday November 17, 2020 @05:22PM (#25130709)
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
[ Parent | on HN ]
Re:2020 Mac Mini – Putting Apple Silicon M1 To The Test by marmaduke on Wednesday November 18, 2020 @08:17AM (#25136382)
That’s interesting. I was not cross compiling so maybe the arm system I was using was just faster.
[ Parent | on HN ]
Re:2020 Mac Mini – Putting Apple Silicon M1 To The Test by fomine3 on Tuesday November 17, 2020 @11:04PM (#25133092)
So cross compile for RISC-V, POWER, or something else would be fair?
[ Parent | on HN ]