Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 20 Mar 2001 16:37:09 -0800
From:      Kris Kennaway <kris@obsecurity.org>
To:        Roman Shterenzon <roman@harmonic.co.il>
Cc:        freebsd-stable@FreeBSD.ORG
Subject:   Re: ARCH in /etc/make.conf
Message-ID:  <20010320163708.B26858@xor.obsecurity.org>
In-Reply-To: <985128401.3ab7ddd1dff3c@webmail.harmonic.co.il>; from roman@harmonic.co.il on Wed, Mar 21, 2001 at 01:46:41AM %2B0300
References:  <Pine.LNX.4.10.10103181240500.20824-100000@shark.harmonic.co.il> <20010319020716.B4427@xor.obsecurity.org> <985128401.3ab7ddd1dff3c@webmail.harmonic.co.il>

next in thread | previous in thread | raw e-mail | index | archive | help

--mojUlQ0s9EVzWg2t
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Mar 21, 2001 at 01:46:41AM +0300, Roman Shterenzon wrote:
> Quoting Kris Kennaway <kris@obsecurity.org>:
>=20
> > On Sun, Mar 18, 2001 at 12:44:38PM +0200, Roman Shterenzon wrote:
> > > Hi,
> > > I've noticed that for K6-2 -march=3Dk6 is implied.
> > > Browsing through gcc code teaches me that ``k6 - doesn't have
> > pipelines''
> > > which is wrong for sure for K6-2. That may explain why -march=3Dpenti=
um
> > > binaries (played with graphics/xine port) run faster than -march=3Dk6.
> > > Perhaps it's wiser to set -march=3Dpentium for K6-2 (of course, with
> > 3DNOW -
> > > I haven't seen yet what variables are set for benefit of ports like
> > mpg123)
> >=20
> > Can you produce benchmarks showing that this is the right thing to do?
> >=20
> > Kris
> >=20
> If you tell me how, I'd be glad to help.
> I played with xine - ran each one many times (in order to eliminate as mu=
ch as=20
> possible the cache, tlb and os cache effects) and watched the dropped fra=
mes=20
> and other information. This is far from being "good benchmark".
> Is there're anything related in ports/benchmarks, some new incarnation of=
=20
> wetstone/dhrystone or something?

Timing the execution of computationally-intensive, repeatable tasks is
the way to go here.  Remember to recompile everything (libraries and
binaries) with the two sets of optimizations so you're comparing
things properly, and to run the benchmark several times consecutively
on an otherwise quiet system and average the results, discarding the
first iteration as it may be affected by CPU or OS-level caching of
instructions/data.

Things like gzip of a large file, kernel/world buildstones (assuming
they're not I/O-dominated), and other CPU-bound tasks should be
affected by the different processor optimizations.

Kris

--mojUlQ0s9EVzWg2t
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (FreeBSD)
Comment: For info see http://www.gnupg.org

iD8DBQE6t/e0Wry0BWjoQKURAkduAKCZihqhmJq2nZEoo+S6MujDB+QpXQCgqrEG
Pgop9faq2RaJEey0kuWVm0k=
=mWSE
-----END PGP SIGNATURE-----

--mojUlQ0s9EVzWg2t--

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010320163708.B26858>