From mint-bounce@lists.fishpool.fi Wed Feb 27 09:10:56 2008 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=HGwb3MLoL9COcwt+/+orfKXOC343zTckiTMogJr5bx8=; b=OAgxBXH9C6m3dcYRJ9SSMqRr0lbt/dofGm+hBvT0h32ZhKXpTa/kBwMhQqCe3z0XDlZmhDNWubxtjFqkyz4bjv+6SMV+XdahwiUdvYCxJYZHjE5zXmJTTXXuaKvqIjP8dHV5ia9x4v5AvCS9OAYErSXeRz8UsfCy+GUtJOGoBvM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=x5iuanJkuXKhEhswK0FSX3cw1acXOW6UiJE1dCsvWyM9frl3KEY0kl9GbsAgw5Ro5uYJkVyx6LX0Qm0O6E7qe/DrhcJQM9I/VwFj1XVC/a6BuMyQHc1yNsF3aNI68dlIZef2XM0CRXxD7f0WXKV+ZliL1YDM011sRGdu7GG7CGM= Message-ID: Date: Wed, 27 Feb 2008 15:00:02 +0100 From: MiKRO To: "Frank Naumann" Subject: Re: [MiNT] Some mintlib patches Cc: mint@fishpool.com In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_9076_22354615.1204120807199" References: <47BC986B.7050704@gmail.com> 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: ------=_Part_9076_22354615.1204120807199 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, You really mean 10-20% only between the two compiler options -m68020-60 > and -m68060? That's very optimistic I think (I speak about the compiler, > not hand optimized assembler). > I'm afraid you're right. And, please don't get me wrong. I'm not against special optimized > software. But it must have a noticeable effect. Otherwise you spent lot of > time for nothing. So optimizing the handful of tools there it make sense > is enough. > I agree with you on this after all, maybe there's really m68020-60 vs m68060 difference out of question. However, I have one experience where at least 68000 vs m680[20-]60 had not some but DRASTIC effect -- and that was gcc. When I ported gcc 3.3.6 using Patrice's tutorial, I've made brutal 060 optimization (in terms of raping makefiles ;-), I didn't care about multilib and stuff, I just added 060 everywhere. When I've tried this 060 gcc, that speed increase was about 30-40%! I'm not kidding, I couldn't believe my eyes. It was newer (=slower) gcc than original 2.95 and still with 060 it was this much, much faster. So I think when we want to be as universal as possible, let's make at least two "branches" -- 68000 and 68020-60... or let's leave m68000 stuff forever.. so when you want to reduce number of mintlib/kernel targets, this is my proposal -- nobody is using mint on atari st anymore . -- MiKRO / Mystic Bytes http://mikro.atari.org ------=_Part_9076_22354615.1204120807199 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi,

You really mean 10-20% only between the two compiler o= ptions -m68020-60
and -m68060? That's very optimistic I think (I speak about the compiler= ,
not hand optimized assembler).
I'm afraid you're rig= ht.

= And, please don't get me wrong. I'm not against special optimized software. But it must have a noticeable effect. Otherwise you spent lot of<= br> time for nothing. So optimizing the handful of tools there it make sense is enough.
I agree with= you on this after all, maybe there's really m68020-60 vs m68060 differ= ence out of question. However, I have one experience where at least 68000 v= s m680[20-]60 had not some but DRASTIC effect -- and that was gcc. When I p= orted gcc 3.3.6 using Patrice's tutorial, I've made brutal 060 opti= mization (in terms of raping makefiles ;-), I didn't care about multili= b and stuff, I just added 060 everywhere. When I've tried this 060 gcc,= that speed increase was about 30-40%! I'm not kidding, I couldn't = believe my eyes. It was newer (=3Dslower) gcc than original 2.95 and still = with 060 it was this much, much faster. So I think when we want to be as un= iversal as possible, let's make at least two "branches" -- 68= 000 and 68020-60... or let's leave m68000 stuff forever.. so when you w= ant to reduce number of mintlib/kernel targets, this is my proposal -- nobo= dy is using mint on atari st anymore .

--
MiKRO / Mystic Bytes
http://mikro.atari.org ------=_Part_9076_22354615.1204120807199--