Date: Mon, 13 Apr 1998 00:48:44 -0500 (EST) From: "John S. Dyson" <toor@dyson.iquest.net> To: Peter.Jeremy@alcatel.com.au (Peter Jeremy) Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Intel-specific libkern code Message-ID: <199804130548.AAA00772@dyson.iquest.net> In-Reply-To: <199804130526.PAA05696@gsms01.alcatel.com.au> from Peter Jeremy at "Apr 13, 98 03:26:41 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> > qdivrem.c provides an excellent, portable multi-precision division > implementation. Unfortunately it is also large and slow. The > equivalent code in libgcc2.c is an order of magnitude smaller and > should be similarly faster since it makes use of the 64:32 bit > division instructions available (rather than relying only on 32:32 bit > division). I have a suitable replacment, but it is GPL code (since > it's basically a cut-and-paste job from libgcc2.c). > > random.c can also benefit from the use of 32:64 bit multiply and 64:32 > bit divide instructions. This is especially useful with gcc 2.8.1, > which include an `optimisation' which interacts very badly with the > existing code. > > I'm not sure how useful these changes would be overall (I don't have a > profiled kernel), but I suspect __qdivrem() is used more than might be > expected given the use of 64-bit offsets within the filesystem code. > > The rest of the (used) library doesn't appear to offer much scope for > machine-specific enhancements. > > Has anyone bothered to see if other parts of the generic kernel could > be tweaked to take advantage of Intel idiosyncracies? > We have done a little bit of that (things like fp based bcopy for P5, and I have a pagezero for P6 in my work queue.) Bruce Evans, David Greenman, others, and myself like to do that, and there is always room for more work in that area. > > Note that I am not suggesting that we turn FreeBSD into an Intel- > specific kernel. I am suggesting that we look at the possibility of > adding hooks to allow processor-specific code to replace `portable' > C where this is worthwhile. > We try to do that in a limited fashion, and it seems that the 64bit math routines are perfect potential candidates for machine specific optimizations. I suggest that if you are interested in doing some machine specific optimizations, that -current is a good place to suggest them. If your code is included in the distribution, you'll get full credit. (The only thing that we require is a BSD style or freer license, along with your copyright.) It would be good that if you fabricate some new code, that also you have some benchmark code and results that can be used for both you and everyone else to evaluate. LL benchmarks are often misused for system performance measurements, but LL benchmarks for micro-improvements that you are suggesting (micro, in the sense of level, not importance :-)) are very valuable. The FreeBSD effort is always accepting of new people, and optionally their contributions. John To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199804130548.AAA00772>