Why are people so stupid about framerate? FPS above 60-70 (worst case, so about 100 average) make no difference. Yet, people want cards that can get 1000fps in Quake III? Why? Because that same card can get 70+ fps in Quake IV! It is *important* to have fast graphics because games keep getting more complex.
Actually, nowhere inside the P4 is an 8080. Inside the P4 is a RISC chip with decoders than can translate 8080 (eg. x86) instructions. As for obscure instructions, they'e been getting slower with every new processor, so I doubt they're very much used today at all.
The reason you can't compile Linux with icc isn't licensing, but actual compatibility. icc doesn't support many non-standard gcc extensions that the Linux kernel uses.
Not only does icc do elf, it also supports most of the gcc linktime stuff like.gnu.linkonce.* sections. It is *very* compatible, as long as you don't use any gcc-specific extensions (except inline asm). It tends to be a little less strict than gcc 3.x, though.
I'm using icc now, and I must say its a great compiler. It performs really well, even for non-fpu intensive tasks. For example, in a test case I tried to find out the speed of page coalescing algorithm. Compiled with icc, the benchmark ran 30% faster under icc than under gcc. That's a significant difference. In addition to performance, the compiler has a lot of other great features. Its error messages still edge out gcc's in my opinion (which is the real reason I like it, not really the performance) and its got good C++ compatibility. It has gcc-style inline asm support, and is substantially compatible with gcc. There are a couple of problems with it, however. Not all the command-line options supported by gcc are supported in icc. Normally, this isn't an issue, but in some cases the additional control might be nice. I'm a little worried about its quality, however. While the compiler itself hasn't bugged out on me yet, the IPO support (intraprocedural optimization, basically optimization between multiple object files) sometimes fails in weird cases (in my toy OS kernel with C++ objects with destructors created on the stack). Also, the lack of documentation about its exception handling runtime (which has to be rewritten in order to use C++ exceptions in a kernel) is annoying.
I can see why you say this, but in practice I can't see this as a problem. The size of the disk cache is increased with the number of devices mounted. On the other hand, separate caches mean you can implement different buffer cache policies depending on the device. (You can imagine, for example, that flash memory could use a very different write-back policy than disk.)
>>>>>>>>>
Seperate caching policies can be implemented with a unified cache as well. The thing is, that on a desktop machine, the usage of disk cache can vary wildly. At one minute, the user might be running a disk-intensive program like a compiler, and the next moment they might be running a program that doesn't touch the disk, like a game or raytracer.
You really need a hybrid (and I don't mean RTLinux). Desktop systems need real-time. BeOS users can testify to this. Also, there are new applications such as serving streaming media and ATM routing which really need real-time. Even burning CDs really needs real-time to do properly.
>>>>>>>>>>
I think you need soft-realtime, but you have to be flexible about it. Hard-realtime, with its viscious demands on timing, is really not appropriate for an environment where you might sometimes want to "break the rules" and give a process some extra time in order to make the desktop more responsive to the user.
It wouldn't be too hard on UNIX. It would require that X run as setuid root, but X could manually renice applications on the fly. Actually, the last point you mention would be very helpful for GUI applications. Tannebaum mentions something similar in relation to lottery scheduling in his book "Modern Operating Systems."
Obviously, somebody didn't read the docs. QNX RtP is designed to:
"[scale] seamlessly from the leanest consumer device right up to the largest distributed SMP systems."
1) Actually, POSIX plays a huge role. The X server is nothing more than a big program that accesses the system through the standard kernel APIs (barring DRI, of course). Since both the QNX kernel and the Linux kernel offer similar functionality through a similar API, it shouldn't be any harder to port Photon than any other major app. The only hangup I can think of would be the differing messaging schemes, but that's a very narrow and concrete issue to solve.
2) For all practical purposes, X is XFree86. We are talking desktop OSs here and there is only one X server that is of any consideration as a main GUI for an OS and that is XFree86. I don't care what SGI has made IRIX's version of X do, it doesn't run on Intel machines and is thus irrelevent. Isn't life great when you have 99% market share? That said, I challenge you to point out one thing that X does better than Photon, aside from 3D,
Traditional schedulers have several problems with GUI programs.
QNX RtP's scheduler, a straight priority-driver round-robin affair, allows a high priority process to run whenever it becomes ready, even if it is preempting the foregroung GUI process. Its a very static scheduler, which means it doesn't take into account the myriad of issues that result in good UI response.
Traditional UNIX schedulers try to be fair to each process, penalizing CPU-bound processes and giving better response to I/O bound processes. This, too, has flaws. A CPU-bound GUI process can get penalized when an I/O bound background process (such as a compiler) can get boosted. The scheduler doesn't take into account which process is in the foreground when making decisions.
The two best schedulers I've seen for desktop systems are Windows NT's and BeOS's. Both treat GUI scheduling as an integral part of the system and take issues such as which is the foreground process into account when making decisions. This is not as "clean" as the UNIX way of doing things, but results in much better user-percieved responsiveness.
QNX RtP has tons of potential, but there are lots of things holding it back as a desktop OS:
1) Lack of unified VM/buffer-cache. The size of the disk cache is fixed rather than dynamically adjusted depending on need.
2) Lack of proper swapping. Since swapping kills embedded apps, RtP lacks good swapping. Use of swap has to be explicitly coded into the app, and was implemented as sort of a hack to allow gcc to be self-hosted.
3) Real-time scheduler. The hard-real time scheduler might be nice on an embedded system, but on a desktop system (where fairness takes a back seat to user-percieved responsiveness) it doesn't work well.
4) Crappy disk subsystem. I don't know if this problem has been fixed in 6.2 (I doubt it) but RtP has a really slow disk system. The IDE drivers have issues and the filesystem is ancient.
Some of the numbers that RtP shows aren't as impressive as they could be. 0.55us context switches sound great, but Linux can do switches on that order as well. Still, RtP is a great system. QNet, in particular, is very featureful, and Photon totally destroys X in every area except maybe 3D support. It has superlative network transparency, a good (fast) widget set, incredible fonts (courtesy of BitStream's FontFusion) and a nice, lean, architecture. If QSSL would port Photon to Linux (which wouldn't be that hard, given that both are mostly straight POSIX) I'd pay to run it.
I think a more salient point is that since most important apps already use a toolkit like GTK+ or Qt, only the toolkit would have to be ported to Berlin.
Re:MS Windows vs. X, same hardware
on
Xfree86 4.2.0 Out
·
· Score: 2
By running the graphics driver as a seperate process, you (potentially, I don't know if Photon does it) can start and stop graphics drivers at will, switch graphics drivers on the fly, protect the server from the driver, etc.
Umm, If everything used one widget set, you could run ALL apps at the same time AND they'd all be consistant.
Re:MS Windows vs. X, same hardware
on
Xfree86 4.2.0 Out
·
· Score: 2
Actually, the XDrawLine level is rather low-level. If you take a look at Berlin, you interface at a much higher level and put drawing objects into the server.
Re:MS Windows vs. X, same hardware
on
Xfree86 4.2.0 Out
·
· Score: 2
While I agree that the toolkits suck, that email is rather irrelevent. If I interpret the email correctly, backing is referring to double-buffering. That's nothing more than a cheap trick used by designs that can't render widgets quickly enough. In a game, double buffering is useful because because any tearing is really annoying. That's not so on a desktop. BeOS, for example, can render widgets fast enough on much more ancient machines and it does't have double-buffering. Same thing for QNX Photon (and hell, Photon is even more flexible than X. It even runs the graphics driver as a seperate process).
I think someone should at least give an honest shot at moving away from X. One of the things I really like about Linux is that the kernel devs aren't afraid to try new things. Take the 2.4 VM for example. It might have destabilized things and pissed off a lot of sysadmins (so much the better...) but it resulted in a VM that was quite good for the loads Linux is usually subject too. There is a lot of work left to be done, but its better than what we had before. Similarly, I don't think people should be afraid to try out new things with the GUI. However, I don't really know how X fits into that kind of scheme. X is really too low level for an archicture that allows experimenting. The reason Linux could change so much and still run all regular UNIX apps is that POSIX is a high-level, clean API that supports lots of different implementations. Similarly, I think we need consistant GUI API that is simple (yet complete, like POSIX) that allows people to really work on the backend. This would not only get rid of the GUI problems we have in Linux today (too many layers of software, little consistency) but would be better all-around for everyone. Users would get a consistent desktops and better implementations. Developers would get a consistant API that would be stable enough to have time to mature. Hackers would have a system that allows them to experiment without breaking compatibility. True, some flexibility might be lost, but not nearly as much as one would think. POSIX is a very narrow standard, but nobody has yet really found something major that can't be handled through the standard API. Nobody complains that there aren't a dozen different ways to call kernel features and I don't think that many developers would care that there was only one standard GUI API. Even if they did, you could always add libraries on top of that and still have fewer layers of software than you do today.
Umm, Linux doesn't have a "shitty font system." Most of its older apps are braindead with respect of fonts, because the classic X font system IS shitty, but most apps based on modern versions of GTK+ or Qt can use the excellent Xft font system and its high-quality FT2-baesd renderer. The only thing it lacks is quality free fonts. If you don't want to take fonts from your windows partition, go download the free WebFonts from MS's website (which include all the important ones). If you just plain don't like MS, download QNX RtP or BeOS PE (which have some nice fonts as well) and use those. If you don't want to even do that, bite the bullet and pay the $200 (for 10 fonts) to Monotype to buy some eye-gasmic ESQ typefaces. If you're needs are less intensive than that (although you should buy Arial from Monotype anyway, since you'll be staring at it the most) go to www.buyfonts.com and buy some lower priced ones from EFF.
Yes, NT is fully preemptible (except when its holding some very critical locks). However, it is not a real-time kernel, since it makes no guarentees about latency. The stock kernel is fine for soft realtime stuff like audio/video things, but you can't do hard realtime with it. However, there is a product called RTX which claims to make WinNT realtime.
1. It makes kernel debugging considerably harder
>>>>>>>
Then don't compile it in while you're debugging. Most *users* don't debug their kernels.
2. It introduces potential livelocks which could hang the system (this is an inherent part of the design and not an implementation bug)
>>>>>>>>
True, but the SMP support introduced these to begin with. The preemptive patches just bring that danger to UP machines.
3. It doesn't work with SMP (yet), this is fixable
>>>>>>>>>>
Already been done. As of around 2.4.10, it experimental, but working.
4. It doesn't improve the worst-case latency.
>>>>>>>>>>>
It's not designed to. Love has already started work on a lock-breaking patch to get rid of long-held locks.
(Aside from the fact that all of the Linux kernel, drivers, etc. is in 'kernel' mode, and a MicroKernel has only the message-passing and task-scheduling in 'kernel' mode, and everything else (drivers, etc.) run in 'user' mode.)
>>>>>>>>>>.
That's basically everything that distinguishes a microkernel from a monolithic kernel:) The preemptive bit is orthagonal to micro/macro kernel. There are non-preemptible microkernels (like MINIX, I think) and preemptible monolithic kernels (Solaris).
Slashdot Mirror
SuSE uses ALSA as the default sound system.
Why are people so stupid about framerate? FPS above 60-70 (worst case, so about 100 average) make no difference. Yet, people want cards that can get 1000fps in Quake III? Why? Because that same card can get 70+ fps in Quake IV! It is *important* to have fast graphics because games keep getting more complex.
Darwin may be open source, but it is Aqua that makes OS-X what it is.
Actually, nowhere inside the P4 is an 8080. Inside the P4 is a RISC chip with decoders than can translate 8080 (eg. x86) instructions. As for obscure instructions, they'e been getting slower with every new processor, so I doubt they're very much used today at all.
The reason you can't compile Linux with icc isn't licensing, but actual compatibility. icc doesn't support many non-standard gcc extensions that the Linux kernel uses.
Not only does icc do elf, it also supports most of the gcc linktime stuff like .gnu.linkonce.* sections. It is *very* compatible, as long as you don't use any gcc-specific extensions (except inline asm). It tends to be a little less strict than gcc 3.x, though.
I'm using icc now, and I must say its a great compiler. It performs really well, even for non-fpu intensive tasks. For example, in a test case I tried to find out the speed of page coalescing algorithm. Compiled with icc, the benchmark ran 30% faster under icc than under gcc. That's a significant difference. In addition to performance, the compiler has a lot of other great features. Its error messages still edge out gcc's in my opinion (which is the real reason I like it, not really the performance) and its got good C++ compatibility. It has gcc-style inline asm support, and is substantially compatible with gcc. There are a couple of problems with it, however. Not all the command-line options supported by gcc are supported in icc. Normally, this isn't an issue, but in some cases the additional control might be nice. I'm a little worried about its quality, however. While the compiler itself hasn't bugged out on me yet, the IPO support (intraprocedural optimization, basically optimization between multiple object files) sometimes fails in weird cases (in my toy OS kernel with C++ objects with destructors created on the stack). Also, the lack of documentation about its exception handling runtime (which has to be rewritten in order to use C++ exceptions in a kernel) is annoying.
I can see why you say this, but in practice I can't see this as a problem. The size of the disk cache is increased with the number of devices mounted. On the other hand, separate caches mean you can implement different buffer cache policies depending on the device. (You can imagine, for example, that flash memory could use a very different write-back policy than disk.)
>>>>>>>>>
Seperate caching policies can be implemented with a unified cache as well. The thing is, that on a desktop machine, the usage of disk cache can vary wildly. At one minute, the user might be running a disk-intensive program like a compiler, and the next moment they might be running a program that doesn't touch the disk, like a game or raytracer.
You really need a hybrid (and I don't mean RTLinux). Desktop systems need real-time. BeOS users can testify to this. Also, there are new applications such as serving streaming media and ATM routing which really need real-time. Even burning CDs really needs real-time to do properly.
>>>>>>>>>>
I think you need soft-realtime, but you have to be flexible about it. Hard-realtime, with its viscious demands on timing, is really not appropriate for an environment where you might sometimes want to "break the rules" and give a process some extra time in order to make the desktop more responsive to the user.
It wouldn't be too hard on UNIX. It would require that X run as setuid root, but X could manually renice applications on the fly. Actually, the last point you mention would be very helpful for GUI applications. Tannebaum mentions something similar in relation to lottery scheduling in his book "Modern Operating Systems."
Obviously, somebody didn't read the docs. QNX RtP is designed to:
"[scale] seamlessly from the leanest consumer device right up to the largest distributed SMP systems."
1) Actually, POSIX plays a huge role. The X server is nothing more than a big program that accesses the system through the standard kernel APIs (barring DRI, of course). Since both the QNX kernel and the Linux kernel offer similar functionality through a similar API, it shouldn't be any harder to port Photon than any other major app. The only hangup I can think of would be the differing messaging schemes, but that's a very narrow and concrete issue to solve.
2) For all practical purposes, X is XFree86. We are talking desktop OSs here and there is only one X server that is of any consideration as a main GUI for an OS and that is XFree86. I don't care what SGI has made IRIX's version of X do, it doesn't run on Intel machines and is thus irrelevent. Isn't life great when you have 99% market share? That said, I challenge you to point out one thing that X does better than Photon, aside from 3D,
Traditional schedulers have several problems with GUI programs.
QNX RtP's scheduler, a straight priority-driver round-robin affair, allows a high priority process to run whenever it becomes ready, even if it is preempting the foregroung GUI process. Its a very static scheduler, which means it doesn't take into account the myriad of issues that result in good UI response.
Traditional UNIX schedulers try to be fair to each process, penalizing CPU-bound processes and giving better response to I/O bound processes. This, too, has flaws. A CPU-bound GUI process can get penalized when an I/O bound background process (such as a compiler) can get boosted. The scheduler doesn't take into account which process is in the foreground when making decisions.
The two best schedulers I've seen for desktop systems are Windows NT's and BeOS's. Both treat GUI scheduling as an integral part of the system and take issues such as which is the foreground process into account when making decisions. This is not as "clean" as the UNIX way of doing things, but results in much better user-percieved responsiveness.
Umm (RtP == RealTime Platform) *is* a desktop os.
QNX RtP has tons of potential, but there are lots of things holding it back as a desktop OS:
1) Lack of unified VM/buffer-cache. The size of the disk cache is fixed rather than dynamically adjusted depending on need.
2) Lack of proper swapping. Since swapping kills embedded apps, RtP lacks good swapping. Use of swap has to be explicitly coded into the app, and was implemented as sort of a hack to allow gcc to be self-hosted.
3) Real-time scheduler. The hard-real time scheduler might be nice on an embedded system, but on a desktop system (where fairness takes a back seat to user-percieved responsiveness) it doesn't work well.
4) Crappy disk subsystem. I don't know if this problem has been fixed in 6.2 (I doubt it) but RtP has a really slow disk system. The IDE drivers have issues and the filesystem is ancient.
Some of the numbers that RtP shows aren't as impressive as they could be. 0.55us context switches sound great, but Linux can do switches on that order as well. Still, RtP is a great system. QNet, in particular, is very featureful, and Photon totally destroys X in every area except maybe 3D support. It has superlative network transparency, a good (fast) widget set, incredible fonts (courtesy of BitStream's FontFusion) and a nice, lean, architecture. If QSSL would port Photon to Linux (which wouldn't be that hard, given that both are mostly straight POSIX) I'd pay to run it.
I think a more salient point is that since most important apps already use a toolkit like GTK+ or Qt, only the toolkit would have to be ported to Berlin.
By running the graphics driver as a seperate process, you (potentially, I don't know if Photon does it) can start and stop graphics drivers at will, switch graphics drivers on the fly, protect the server from the driver, etc.
Umm, If everything used one widget set, you could run ALL apps at the same time AND they'd all be consistant.
Actually, the XDrawLine level is rather low-level. If you take a look at Berlin, you interface at a much higher level and put drawing objects into the server.
While I agree that the toolkits suck, that email is rather irrelevent. If I interpret the email correctly, backing is referring to double-buffering. That's nothing more than a cheap trick used by designs that can't render widgets quickly enough. In a game, double buffering is useful because because any tearing is really annoying. That's not so on a desktop. BeOS, for example, can render widgets fast enough on much more ancient machines and it does't have double-buffering. Same thing for QNX Photon (and hell, Photon is even more flexible than X. It even runs the graphics driver as a seperate process).
I think someone should at least give an honest shot at moving away from X. One of the things I really like about Linux is that the kernel devs aren't afraid to try new things. Take the 2.4 VM for example. It might have destabilized things and pissed off a lot of sysadmins (so much the better...) but it resulted in a VM that was quite good for the loads Linux is usually subject too. There is a lot of work left to be done, but its better than what we had before. Similarly, I don't think people should be afraid to try out new things with the GUI. However, I don't really know how X fits into that kind of scheme. X is really too low level for an archicture that allows experimenting. The reason Linux could change so much and still run all regular UNIX apps is that POSIX is a high-level, clean API that supports lots of different implementations. Similarly, I think we need consistant GUI API that is simple (yet complete, like POSIX) that allows people to really work on the backend. This would not only get rid of the GUI problems we have in Linux today (too many layers of software, little consistency) but would be better all-around for everyone. Users would get a consistent desktops and better implementations. Developers would get a consistant API that would be stable enough to have time to mature. Hackers would have a system that allows them to experiment without breaking compatibility. True, some flexibility might be lost, but not nearly as much as one would think. POSIX is a very narrow standard, but nobody has yet really found something major that can't be handled through the standard API. Nobody complains that there aren't a dozen different ways to call kernel features and I don't think that many developers would care that there was only one standard GUI API. Even if they did, you could always add libraries on top of that and still have fewer layers of software than you do today.
Yet, the problem with X is also extensibility. XRender is nice, but basically only GTK+, Qt, and a few straight X apps support it.
Umm, Linux doesn't have a "shitty font system." Most of its older apps are braindead with respect of fonts, because the classic X font system IS shitty, but most apps based on modern versions of GTK+ or Qt can use the excellent Xft font system and its high-quality FT2-baesd renderer. The only thing it lacks is quality free fonts. If you don't want to take fonts from your windows partition, go download the free WebFonts from MS's website (which include all the important ones). If you just plain don't like MS, download QNX RtP or BeOS PE (which have some nice fonts as well) and use those. If you don't want to even do that, bite the bullet and pay the $200 (for 10 fonts) to Monotype to buy some eye-gasmic ESQ typefaces. If you're needs are less intensive than that (although you should buy Arial from Monotype anyway, since you'll be staring at it the most) go to www.buyfonts.com and buy some lower priced ones from EFF.
Yes, NT is fully preemptible (except when its holding some very critical locks). However, it is not a real-time kernel, since it makes no guarentees about latency. The stock kernel is fine for soft realtime stuff like audio/video things, but you can't do hard realtime with it. However, there is a product called RTX which claims to make WinNT realtime.
1. It makes kernel debugging considerably harder
>>>>>>>
Then don't compile it in while you're debugging. Most *users* don't debug their kernels.
2. It introduces potential livelocks which could hang the system (this is an inherent part of the design and not an implementation bug)
>>>>>>>>
True, but the SMP support introduced these to begin with. The preemptive patches just bring that danger to UP machines.
3. It doesn't work with SMP (yet), this is fixable
>>>>>>>>>>
Already been done. As of around 2.4.10, it experimental, but working.
4. It doesn't improve the worst-case latency.
>>>>>>>>>>>
It's not designed to. Love has already started work on a lock-breaking patch to get rid of long-held locks.
(Aside from the fact that all of the Linux kernel, drivers, etc. is in 'kernel' mode, and a MicroKernel has only the message-passing and task-scheduling in 'kernel' mode, and everything else (drivers, etc.) run in 'user' mode.) :) The preemptive bit is orthagonal to micro/macro kernel. There are non-preemptible microkernels (like MINIX, I think) and preemptible monolithic kernels (Solaris).
>>>>>>>>>>.
That's basically everything that distinguishes a microkernel from a monolithic kernel