[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[MiNT] gcc 68000 vs 68020-60 vs 68060 comparison
Hi all,
this may be a little bit offtopic but it's quite interesting thing, especially for users of real machines. For quite a long time I was always curious how much influence have various compilation options to the speed of compilation. Concretely, impact of 020+ options so this week I've decided to make some tests. So here are few notes:
- I've compiled every dependency with desired options, i.e. gmp, mpfr, mintlib, every library and executable in binutils, every library (except multilib targets) and executable in gcc were compiled with "-O2 -fomit-frame-pointer" plus "-m68020-60" or "-m68060"
- preparation of those binaries finally cleared the libm dependency out and that is, it's not needed. Since I needed to recompile also my cross compiler (to support m68060 multilib), after my makefile ended, I deleted all traces of libm.a in cross compiler setup and started to build m68020-60 & m68060 binaries. So unless m68000 is some exception, I'd say libm is needed only for gmp / mpfr tests on native builds
- gcc doesn't do very good job with bit operations. my testcase was compilation of all mintlib targets and for the testing I used aranym (if my binaries works well), everytime compilation finished, I closed aranym and guess what most used untranslated instructions were? BFEXTU, BFCLR, BFINS etc -- so regardless m68020-60 or m68060, gcc refuses to use registers + simple move/and/or operations that are at least 4x faster than horrible BFxxx instructions (add the instruction pairing thanks to 2nd pipeline and you'll get pretty amazing results when the code is well optimized)
- compilation of mintlib targets (000, 020, profile, debug) on CT60, 66/16 MHz, mono res and optimized binutils/gcc:
68000: 318m56s
68020-60: 293m5s
68060: 290m45s
what is quite interesting (or: disappointing ;-) -- I could swear when I've tried gcc3/m68060 on my falcon looong time ago, I could measure 30% speedup against gcc3/68000 when compiling quake. So either I was really drunk or this new gcc has drastically changed since then or mintlib is not very good testcase (since it uses a lot of external stuff) or 68000 optimization in general is so damn good there's no space for massive speedups thanks to raw CPU power. Hmm, maybe I try to re-compile that quake ;-)
Btw I've measured also aranym builds, it's about 3x faster than my ct060 (finally guys! ;-), in % are results nearly identical.
So as you see, special 68060 target is probably not worth of attention, maybe for some special application that uses sinus, cosinus etc heavily (instructions emulated on 060) or FPU in general. Except slightly faster build with 68020-60 there's one advantage and that is 68020-60/68060 builds are significantly smaller (2/3 of 68000 approximately).