Date: Tue, 21 Nov 2017 23:16:45 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Ed Maste <emaste@freebsd.org> Cc: Bruce Evans <brde@optusnet.com.au>, src-committers <src-committers@freebsd.org>, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r325988 - head/sys/libkern Message-ID: <20171121220626.U2067@besplex.bde.org> In-Reply-To: <CAPyFy2B98iviaAm9wuCiE%2B32UoVDoCKCgHaa%2BO4nwbexwSUPaw@mail.gmail.com> References: <201711190031.vAJ0VE9m016670@repo.freebsd.org> <20171119173822.J974@besplex.bde.org> <CAPyFy2B98iviaAm9wuCiE%2B32UoVDoCKCgHaa%2BO4nwbexwSUPaw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 20 Nov 2017, Ed Maste wrote: > Hi Bruce, notes on a few of the points you raised (I'll look at others later): > > On 19 November 2017 at 04:07, Bruce Evans <brde@optusnet.com.au> wrote: >> >> The vendor version is in libc/string. It has been ANSIfied, but the >> libkern version has large churning to "optimize" it. It is the libkern >> version that should have been optimized, since bcmp is unimportant in >> the kernel and in most applications, but applications have a wider range >> so a few might benefit from optimizing it. > > I presume you meant "it is the _libc_ version that should have been > optimized", but could also read this as a distinction between > optimized and scare-quotes "optimized." Yes, optimize the libc version first and usually throw away the optimizations since they are negative or too MD or too hard to maintain. Also, clean up libc versions before changing libkern versions. >> bcmp is actually optimized >> in the kernel in support.[sS] for all arches except powerpc and riscv, >> so optimizing the kernel MI version of it is especially unimportant. >> In libc where MD optimizations are more important, they are also not >> done for arm, arm64 and sparc64. > > This could make a nice small project for someone to take on. A nice large project :-). I once tried it for bcopy and bzero, but gave up ~15 years ago when the MD variations became too complicated. The variations would be much larger now. Simple "rep movsb" is now almost best, except it takes too long to start up so even a naive C loop should beat it for sizes up to quite large values (nearly 1K). AVX might be best, but is less portable, and sometimes has overheating problems which are avoided by throttling it. The naive C loop might be fastest with a non-naive compiler that generates AVX for it, but how is the compiler going to know if its target hardware will throttle AVX when the program is run? ... >> - libc version copyright comment not marked for indent protection using >> "/*-" (this has been subverted to have another meaning which I forget). > > I don't believe there's another meaning. IIRC imp@ has pointed out > that it means precisely what you've mentioned above. "/*-" was originally just the normal style for indent protection. indent also supports "/**" for this. It is not easily to find copyrights without a unique markup, so IIRC the "/*-" form was reserved for copyrights, and other comments that used this were changed to use "/**". I prefer the "/*-" form and don't like it to be restricted to copyright comments. Actually, I seem to have remembered incorrectly. In kern/*.c, there are a few old '/*-' comments (there never were very many), and most '/**' comments are for doxygen. style(9) has fairly bad documentation of this. It only mentions the markup use of '/*-' for copyright comments. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20171121220626.U2067>