Date: Fri, 25 Jan 2002 16:57:46 -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: <3C51FF0A.9ACAC316@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> <3C51F492.CB0FB69E@mindspring.com> <15441.62830.180895.121111@caddis.yogotech.com> <3C51F89E.78DAD01D@mindspring.com> <15441.63876.271856.290838@caddis.yogotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Nate Williams wrote: > > > Otherwise known as not having a complete solution to the problem, hence > > > not having a solution at all. :( > > > > It maps the problem space, so it's a complete solution. > > No, it doesn't. It's a 75% solution, and the remaining 25% is extremely > common. Not an acceptable solution. FPU usage is uncommon. If it were 51% common, we'd just pay the cost of switching it all the time, and this discussion would not have started. The problem with any interpreted language that permits the use of the FPU is that you have a hard time knowing ahead of time whether or not you need to pay the penalty. If we exclude these languages as being sufficiently slow because they are interpreted that the FPU overhead will be comparatively miniscule, then we are left with caching JITed languages, which include LISP and Java, among other things, and Java is incredibly popular. I don't know how to answer the question except to say that there is a trade-off between FPU lazy binding, and full quantum utilization achieved by not having a 1:1 mapping between kernel and user space threads. I think that the trade-off is going to have to be made, one way or the other. I can see beaing able to deal with this using a vastly more complex user space scheduler. At this point, I'd say that such a scheduler was a LISP and Java specific problem, and not a general problem for optimization of the system. > > One way around this would be to compile your Java programs > > to native code, but that's ugly, too, and has corner cases > > when you grab serialized objects out of a directory or > > whereever, and have to fall back to the JVM to access the > > member functions, which might use the FPU. 8-(. > > Plus, it's not possible to do, since there are no 'Good' java->native > code compilers for FreeBSD. (There is only one decent compiler out, and > it isn't ported to FreeBSD. And, GCC is *NOT* that compiler, as it's > Java stuff isn't useful for anything real.) 8^). We agree on two things, now. 8-) 8-). > > Cool! Let's just dike the thing out! > > > > I know, we can compile the FPU emulation library into user > > space, and not use the hardware FPU at all. Then we can fix > > the emulated FPU, and the problem goes away. 8-) 8-) 8-). > > Yeah, sure. How about this: force trigger the exception before context switching away, if the FPU has been used. There won't be an exception necessarily, but since we are in the kernel scheduler, we can do this before we switch away, and the fact that we are in the scheduler means we can do it before a migration or other dangerous event occurs. This effectively would non-lazy bind the FPU state. This can be done lazily anyway, until we know we have more than one CPU *and* are running a threaded program *and* can be scheduled on more than one CPU simlutaneously, so it only starts happening after you meet all those conditions, AND use the FPU. That pushes the overhead out into mutithreaded SMP using programs, where it's going to have to be there anyway. It has the side benefit that the force only occurs *after* use of the FPU, so a JVM running a lot of threads over a long period of time will not keep taking the overhead unless the thread being run accesses the FPU (forcing the force), so a JVM with 10,000 threads that runs one transient FPU using thread once, and never runs one again, doesn't take the overhead all the time. The downside is that extra code has to be run on task switch to (1) check if the FPU was used and (2) execute a barrier that forces pending exceptions (if any) to occur. This could be further delayed by not doing it unless the context swithc was *(away* from the program being run (i.e. using up your quantum, if you are just going to run again doesn't cause the overhead, so you aren't eating it every LBOLT interval -- this is how the lazy stuff works already, so it's not even any extra checks for that particular case). ??? -- 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?3C51FF0A.9ACAC316>