Return to BSD News archive
Path: sserve!manuel!munnari.oz.au!uunet!sun-barr!cs.utexas.edu!swrinde!gatech!bloom-beacon!eru.mt.luth.se!lunic!sunic!news.funet.fi!hydra!klaava!torvalds From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Newsgroups: comp.unix.bsd Subject: Re: abysmal performance of X in xgc and x11perf Message-ID: <1992Sep4.220430.807@klaava.Helsinki.FI> Date: 4 Sep 92 22:04:30 GMT References: <BRTMAC.92Sep4124909@maverick.ksu.ksu.edu> Organization: University of Helsinki Lines: 40 [ I haven't actually looked at the changes that were made to the 387 emulator when porting from linux, but I assume they aren't major, so this should still be true unless 386bsd does something weird ] In article <BRTMAC.92Sep4124909@maverick.ksu.ksu.edu> brtmac@maverick.ksu.ksu.edu (Brett McCoy) writes: >I have a 386sx/16 machine without a 387. Most of the time this >works fine, but in programs like ico, xgc and x11perf when they >do floating point intensive stuff the machine more or less locks >up and I generally have to reboot. > >I believe this is because of all the traps to the 387 emulation >code in the kernel. I understand it being slow, but why does >it bring the machine to a virtual halt? I doubt it brings the machine to a halt: other things still get to run. The emulator just makes some things very slow - I didn't originally write it for speed, but for ease of implementation, and I never went back to look more into it (as I do have a 387, and never actually used the emulator anyway other than for testing purposes). >When I run ico everything will freeze for 5 or 10 seconds, then >the ball will move a ways and other X events will occur (such as >the mouse cursor moving), then everything will halt again. It >seems that while the 387 emulation code is running nothing else >can run and the emulation code has priority over everything else. It's probably not the 387-emulator that has priority: it's X11. Things that don't use the screen should be perfectly all right - but anything which wants to draw things on the screen has to wait for X to be ready. And if X11 is busy calculating sin/cos for arcs, it won't update other windows, which is why it looks halted. Try logging in over a serial line to see if that's ok: it will naturally be slower than on an unloaded machine, as X11 is chugging away on counting, but it shouldn't be any worse than any other CPU-intensive task. And if you are serious about running X, I'd suggest you get a real 387 pronto: the 387-emulator was never meant to be used for any "real" calculations. Linus