Date: Fri, 25 Jan 2002 16:13:06 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Nate Williams <nate@yogotech.com> Cc: 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: <3C51F492.CB0FB69E@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> <15441.62092.864056.841853@caddis.yogotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Nate Williams wrote: > > > 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.) I think the way I would handle this for Java, for example, is to do the swicth when the JNI code for the FPU access code is loaded. This would only happen when you actually go to JIT FPU code out. > 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 real problem: you can't safely do mixed FPU and non-FPU access, if your threads can move between processors without user space threads scheduler interaction in this case. I really don't want to mandate that that happen, for obvious reasons. It's possible to lazy-bind FPU use to the first use in a program, if you use IPI signalling between the user space threads schedulers running on multiple CPUs. I really can't see a way around getting rid of the lazy binding in the FPU using case on multiple threads on multiple CPUs. You might be able to squeak by, if you *knew* that there was only one thread doing the FPU access, but it would be a bear to get right. Hence my punting to "optimize later". 8-(. > This is the state of the art in the current x86/unix JVMs (not just in > FreeBSD, but in Solaris and Linux as well). Yes, understood. > > 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. Unfortunately, we can't fix the base problem, which is "delayed exception signalling on x86 FPUs sucks". 8-). I think the only thing we can do is guarantee correctness. Right now, I'm just trying to avoid dragging everyone down with the FPU using code, which I think, *has* to drag down, at this point. 8-(. -- Terry 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?3C51F492.CB0FB69E>