From owner-freebsd-chat Mon Mar 10 14:56:12 2003 Delivered-To: freebsd-chat@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1295337B401 for ; Mon, 10 Mar 2003 14:56:11 -0800 (PST) Received: from puffin.mail.pas.earthlink.net (puffin.mail.pas.earthlink.net [207.217.120.139]) by mx1.FreeBSD.org (Postfix) with ESMTP id 81B1343F93 for ; Mon, 10 Mar 2003 14:56:10 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from dialup-209.245.137.142.dial1.sanjose1.level3.net ([209.245.137.142] helo=mindspring.com) by puffin.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18sWBh-0005Wk-00; Mon, 10 Mar 2003 14:56:06 -0800 Message-ID: <3E6D17B7.5FDCEAFC@mindspring.com> Date: Mon, 10 Mar 2003 14:54:47 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Murray Cc: Peter Jeremy , chat@FreeBSD.ORG Subject: Re: cvs commit: src/lib/libc/i386/string Makefile.inc wcscmp.S References: <200303102237.h2AMb3Ig074356@grimreaper.grondar.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a43a12c1fed3604deaf40a201e1e406b26a2d4e88014a4647c350badd9bab72f9c350badd9bab72f9c Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Mark Murray wrote: > > In general, the best optimisations are achieved at a much higher level > > than compilers can easily achieve. My favourite example of this is > > the original code for compress(1) - which turns about 1/2 page of C > > code into a single VAX instruction. You're not going to get a compiler > > to recognize this level of equivalence. > > I'm guessing that this means there will always be room for humans to > hand-code assembler. How far can this be made redundant, given that > there is still lots of effort going into hand-coded asm functions? I think that in all cases where it's possible, you want to have C language equivalents. Yeah, they are slow, but they are also portable. It's really a pain to try to go to a new architecture when there's all this assembly language code lying around. At the very least, you want there to be both platform independent and platform dependent versions of the code. Otherwise, nothing beats a good human for highly optimized assembler; with the exception of certain RISC architectures, where the wins are all about instruction scheduling, it's really hard for a compiler to beat a motivated human. Even with PPC or Alpha, a highly knowlegable human can still beat compilers, if they are fully aware of the need for instruction scheduling. It all really boils down to what you're willing to invest for small marginal speed improvements. If it's overhead on every system call, you care about it. If it's overhead on every process startup, you probably care about it a lot less. If it's overhead on the system boot, which gets executed once every 50 days or so, then you probably don't care at all. 8-). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message