Date: Fri, 25 Jan 2002 17:04:28 -0700 From: Nate Williams <nate@yogotech.com> To: Terry Lambert <tlambert2@mindspring.com> Cc: Nate Williams <nate@yogotech.com>, Daniel Eischen <eischen@pcnet1.pcnet.com>, Dan Eischen <eischen@vigrid.com>, k Macy <kip_macy@yahoo.com>, Peter Wemm <peter@wemm.org>, Julian Elischer <julian@vicor-nb.com>, arch@FreeBSD.ORG Subject: Re: KSE question Message-ID: <15441.62092.864056.841853@caddis.yogotech.com> In-Reply-To: <3C51F18A.C0D8D6B1@mindspring.com> References: <3C51D0B6.F6E04EBC@mindspring.com> <Pine.SUN.3.91.1020125164325.24428A-100000@pcnet1.pcnet.com> <15441.56832.170618.611705@caddis.yogotech.com> <3C51E888.FD13A18D@mindspring.com> <15441.59691.361172.394760@caddis.yogotech.com> <3C51F18A.C0D8D6B1@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > You could stick in all sorts of funky hooks, but because threads can be > > intererupted at any time, the amount of checking that still needs to > > occur at runtime would make a compile-time solution un-necessarily > > slow. (MHO of course). > > Actually, the runtime checking is incredibly easy, if you > *know* the program can use the FPU: just switch totally > away from lazy binding at all. This is extremely inefficient for interpreted languages, where they *may* use the FPU, but it's not obvious until runtime whether or not they *will* use the FPU. (FPU usage is till a rarity in comparison to the total runtime of the program.) And, when you have threaded interpreted languages it gets even more exciting, since now you take the hit for every userland context switch, even though you probably didn't use the FPU (since you didn't know). This is the state of the art in the current x86/unix JVMs (not just in FreeBSD, but in Solaris and Linux as well). > The reason it exists at all is "in case someone uses the FPU". If you > know they won't, it makes the rest of the code run faster, which is > probably an acceptable tradeoff. I still don't consider this a workable solution, since there are as many exceptions as there are standard cases. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15441.62092.864056.841853>