Slashdot Mirror
XFree86 4.1.0 Reviewed
Patrick Mullen writes "The Duke of URL has just posted their review of XFree86 4.1.0. The review covers its new features, the fixes since 4.0.3, performance (2D and 3D) and even takes a look at what ground has been made in ATI, NVIDIA, 3dfx, and Matrox's drivers." Compares performance to windows where applicable and to X403. Looks like the speed gains are real. Hope it gets put into sid soon for us apt junkies.
1) X runs on UNIX. Unicies are almost always server-oriented systems, and tend to have very short thread quantums. For example, the quantum on Linux 2.4 is 50ms (down from 100+ on 2.2).
/usr/src/linux/include/asm/param.h and setting the HZ define at 1000. Yes, the timeslice is mostly dependant on this single define. You will notice that for x86 it is at 100 by default. To get the timeslice you simple divide 1000ms by the HZ value. So for 2.2 and 2.4 you get 1000 / 100 = 10ms. I have a standard patch that's applied to all fresh kernels that put HZ at 1000 on my boxes. It's kind of ludicrous to have 10ms timeslices on a 1.4GHZ Thunderbird *g*. Oh, and if you need smaller timeslices, witout having to modify your kernel lookup the manpage of sched_setscheduler
...when GUIs like Photon (on QNX) implement all the features of X plus more in less than a meg, one has to fault elements of X's design
This is simply not true. Both your 2.2 and 2.4 numbers are dead wrong. Linux on x86 has always had a timeslice of 10ms. It has always been 1ms on 64-bit Linux platforms (Alpha). BTW, you can modify the timeslice very easily by editting
show much improved access times, even when the GUI is in a userspace server (as in BeOS or QNX)
X is in userpace.
2) It's badly designed
The design is about 20 years old, and still going strong. The developer didn't have the hindsight of what hardware would be developed over the years. Luckily enough they tought of X extensions. Oh wait, X extensions are bad right? Don't tell that to the Xv and RENDER extension that are taking full advantage of my cutting edge NVidia GPU!!
X uses the much more general (and much slower) UNIX domain sockets
Local sockets are really fast (and very low latency). For large transfers X uses shared memory anyway. And thanks to XAA the amount of communication is kept to a minimum.
Try TinyX. Your arguments, while true to some extend, are really not convincing enough to call X "badly designed". You are using outdated facts to draw conclusions. X is here to stay. Whining about it is not going to make it less useful. You could spend your time better by helping out Be and BeOS, be-fan. A 3ms timeslice doesn't do me any good if it doesn't boot on my box. Too bad the juicy parts are closed source no??!
Oh, I finally decided to put my BeBox in long term storage. Perhaps in 20 years it will fetch a nice price. I'm betting it'll bootup witout too much trouble, assuming I can still find a CMOS battery that fits.
-adnans
"In short: just say NO TO DRUGS, and maybe you won't end up like the Hurd people." --Linus Torvalds
One of the major problems I had running XFree86 on a laptop was having to switch between a port replicator (aka docking station) and using the laptop's display. For those of you that don't know, a port replicator lets you use a standard monitor, keyboard, mouse, etc. Switching between various XF86Config files got to be a royal pain in the arse.
So... those with laptops give this option a try in XF86Config:
Option "UseBIOSDisplay"
It lets you switch between monitors without changing the config file. Haven't had a problem yet.
That is fairly common when moving to new xservers on new hardware. It is usually the result of timing issues afaik. This type of bug is usually eliminated as more user feedback and testing help the developers with optimal timeing and acceleration code. Speaking of acceleration code, sometimes turning acceleration off eliminates the snow at the cost of speed. In any case, 4.1.1 will probably be much less snowy for you.