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
[-- Attachment #1 --] On Wed, Mar 21, 2001 at 01:46:41AM +0300, Roman Shterenzon wrote: > Quoting Kris Kennaway <kris@obsecurity.org>: > > > On Sun, Mar 18, 2001 at 12:44:38PM +0200, Roman Shterenzon wrote: > > > Hi, > > > I've noticed that for K6-2 -march=k6 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=pentium > > > binaries (played with graphics/xine port) run faster than -march=k6. > > > Perhaps it's wiser to set -march=pentium for K6-2 (of course, with > > 3DNOW - > > > I haven't seen yet what variables are set for benefit of ports like > > mpg123) > > > > Can you produce benchmarks showing that this is the right thing to do? > > > > Kris > > > 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 much as > possible the cache, tlb and os cache effects) and watched the dropped frames > and other information. This is far from being "good benchmark". > Is there're anything related in ports/benchmarks, some new incarnation of > 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 [-- Attachment #2 --] -----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-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010320163708.B26858>