Date: Wed, 21 Mar 2001 13:35:45 +0300 (IDT) From: Roman Shterenzon <roman@harmonic.co.il> To: Kris Kennaway <kris@obsecurity.org> Cc: Roman Shterenzon <roman@harmonic.co.il>, freebsd-stable@FreeBSD.ORG Subject: Re: ARCH in /etc/make.conf Message-ID: <985170945.3ab8840168528@webmail.harmonic.co.il> In-Reply-To: <20010320163708.B26858@xor.obsecurity.org> References: <Pine.LNX.4.10.10103181240500.20824-100000@shark.harmonic.co.il> <20010319020716.B4427@xor.obsecurity.org> <985128401.3ab7ddd1dff3c@webmail.harmonic.co.il> <20010320163708.B26858@xor.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting Kris Kennaway <kris@obsecurity.org>: > 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 > gzip or cc will only tell about integer performance. I'm looking for more generic benchmark, that will measure integer, fp, predicted and unpredicted branches. For now, I'll do the following: use gzip and/or bzip2 over a large text and binary files ~10 times use lame (mp3 encoder) on some .wav files use mpg123 with decompression to disk on some .mp3 files. This is the best thing I can think of right now. I'll use "time" command. Suggestions? --Roman Shterenzon, UNIX System Administrator and Consultant [ Xpert UNIX Systems Ltd., Herzlia, Israel. Tel: +972-9-9522361 ] 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?985170945.3ab8840168528>