From mint-bounce@lists.fishpool.fi Fri Jan 15 07:27:43 2010 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=UrakWqe/y86pNytb1Gtl8EdhhHFZwLMxixVa1bTWevg=; b=HfFLJ4HkiqE5eSis8XqeMlir5qA+94e8i6+hqIJpBSP2+g+nP2t66jdw+K9xUOqWCG o5MlsSx7neVFIOcBE+RCKpXVIo/8QTBTel+XHcjCZwVHVXWVX05kBcthNygi4HuLWTfd ffgs6Ii9AuNK9h5jeG0aD/bk7FRWUCCHOaR7o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=C39SiB0UbM4395qmtyOTW+JI4krrNgJJzdWF0b4Q/JVV4nLtSlHlWaluTtlZrvRGUx Q55+4svG/7/479GvHtavwBFylVf/h1CZ1+kgVwrI7GiJUfM++ufDQ9I67c3nYiheHCZA g5TJc1wjRIva9i/01q9hFGJNKEiPzC6uRiKn4= MIME-Version: 1.0 Date: Fri, 15 Jan 2010 13:24:36 +0100 Message-ID: Subject: [MiNT] gcc 68000 vs 68020-60 vs 68060 comparison From: Miro Kropacek To: MiNT Mailing List Content-Type: multipart/alternative; boundary=00032555a0d23b0f44047d33163e X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: miro.kropacek@gmail.com Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: List-subscribe: List-owner: List-post: --00032555a0d23b0f44047d33163e Content-Type: text/plain; charset=ISO-8859-1 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). -- MiKRO / Mystic Bytes http://mikro.atari.org --00032555a0d23b0f44047d33163e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

this may be a little bit offtopic but it's q= uite 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 optio= ns, i.e. gmp, mpfr, mintlib, every library and executable in binutils, ever= y library (except multilib targets) and executable in gcc were compiled wit= h "-O2 -fomit-frame-pointer" plus "-m68020-60" or "= ;-m68060"

- preparation of those binaries finally cleared the lib= m dependency out and that is, it's not needed. Since I needed to recomp= ile 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 t= o 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 u= sed aranym (if my binaries works well), everytime compilation finished, I c= losed aranym and guess what most used untranslated instructions were? BFEXT= U, BFCLR, BFINS etc -- so regardless m68020-60 or m68060, gcc refuses to us= e registers + simple move/and/or operations that are at least 4x faster tha= n horrible BFxxx instructions (add the instruction pairing thanks to 2nd pi= peline and you'll get pretty amazing results when the code is well opti= mized)

- compilation of mintlib targets (000, 020, profile, de= bug) on CT60, 66/16 MHz, mono res and optimized binutils/gcc:
68000: 318m56s
68020-60: 293m5s
68060: 290m= 45s

what is quite interesting (or:=A0disappointing=A0;= -) -- I could swear when I've tried gcc3/m68060 on my falcon looong tim= e 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 spa= ce for massive speedups thanks to raw CPU power. Hmm, maybe I try to re-com= pile that quake ;-)

Btw I've measured also aranym builds, it's abou= t 3x faster than my ct060 (finally guys! ;-), in % are results nearly ident= ical.

So as you see, special 68060 target is proba= bly not worth of attention, maybe for some special application that uses si= nus, cosinus etc heavily (instructions emulated on 060) or FPU in general. = Except slightly faster build with 68020-60 there's one advantage and th= at is 68020-60/68060 builds are significantly smaller (2/3 of 68000 approxi= mately).

--
MiKRO / Mystic Bytes
http://mikro.atari.org
--00032555a0d23b0f44047d33163e--