Date: Tue, 25 Apr 95 11:31:47 MDT From: terry@cs.weber.edu (Terry Lambert) To: bde@zeta.org.au (Bruce Evans) Cc: toor@jsdinc.root.com, geli.com!rcarter@implode.root.com, hackers@FreeBSD.org, jkh@violet.berkeley.edu Subject: Re: benchmark hell.. Message-ID: <9504251731.AA00311@cs.weber.edu> In-Reply-To: <199504250440.OAA15562@godzilla.zeta.org.au> from "Bruce Evans" at Apr 25, 95 02:40:21 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >The correct way to run comparative benchmarks is to boot a DOS disk > >and fdisk/mbr the same machine and installl on the same machine over > >and over with the different OS's. Not "identical hardware", the same > >machine. > > What is ``DOS''? :-> The correct way is to boot a boot disk for the > OS being tested and erase all traces of the previous OS... I guess that could be done, if you trusted the previous OS to not do anything to sabatoge performance (for instance, many EIDE drives come with boot blocks that have built in INT 13 redirectors for geometry translation, with the net effect that UFS will incorrectly optimize for the disk geometry, actually reducing performance. [ ... delayed FPU switching ... ] > Actually, this is because FreeBSD doesn't waste a whole 108 bytes in the > proc table for the FPU state and no one wants to handle the complications > and probable slowness of updating paged-out FPU contexts after delayed > FPU context switches. The simple answer to this is to not switch that part of the proc. > It takes a fairly special benchmark to demonstrate the speed advantages > of delayed context switches. I disagree; all it takes is a single process benchmark with a typical 20 or 30 processes running meanwhile that aren't using FPU. > FreeBSD's low level context switching is faster than Linux's because > hardware tasking is not used. Perhaps there is a lot more bloat in > other layers of the context switching. (Yes, there is. E.g., calling > microtime() for each context switch is very expensive except on > Pentiums). microtime() has to be called so that FreeBSD can do better > timing statistics and scheduling than Linux. ) However, for real > processes, context switching is relatively rare, so small differences > (less than a factor of 2-10) in the speed of context switching don't > matter. The microtime requirement is a result of the timer interval being equal to the lbolt interval for mandatory context switch. I've argued this before. > Actually, copyin/copyout are faster in FreeBSD, except on 386's. For > copyin, the check consists of setting up a fault handler, checking > that the addresses are covered by the user segment registers, and > letting the h/w check for page faults. For copyout, the page tables > have to be checked directly only for 386's. The problem in this approach is that you are taking preventative action. I will treat this in more detail in my response to Charles' post. > copyinstr() is poorly implemented iin FreeBSD. However, I've never seen > it showing up in profiling output. Then you haven't been looking right. Remember the hoo-rah about the speed of a rename? This is part of the problem there. If we consider BSD as a file server candidate, then we have to acknowledge that 70% of file system operations are reads, 18% are writes, 8% are lookups including 'open' (it this 8% that gets hit), with the remaining 4% being all other operations. Or we could not acknowledge it, and be obligated to study the problem as thoroughly as Novell has studied the problem to prove our point (or prove ourselves wrong). Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9504251731.AA00311>