If you've ever used Direct3D, you'd realize that it's nothing like OpenGL. It's far less abstract and closer to the hardware than GL is. There are a lot of similarities, of course, because they both do the same thing using the same 3D graphics concepts (transform matrixes and whatnot) but they are very different overall. Besides, D3D blew chunks until around D3D 6.0, which didn't come out until many years later.
Err, vertex shaders come first. The verticies are moved around by the shaders, then they're projected, 2D triangles are generated, and the pixel shaders run on the pixels covering the generated triangles. But yeah, vertex shader is a misnomer.
There is a difference between music clips that change and music that is generated according to the theme of a level. Seperate music clips are nowhere near as fluid, and don't evoke the same level of subtle enhancement that dynamic music does.
Um, PC games, which load from the hard drive, use in game engine cut scenes as well. Modern consoles have enough memory to handle loading FMV video. Heck, the PS 1 platform was full of FMV games. However, gamers just prefer in game cutscenes because it preserved the realism and feel of the game. You're really arguing minutae here and missing the main point.
By vetor I presume you mean vector, as in outline fonts? The Scale2x stuff really doesn't help fonts at all, because it's the opposite problem. With fonts, you have a lot of information, but want to format it better. With resized video, you lack information and want to generate it from the already formatted output.
You'd be surprised how good MIDI can sound these days. And in the middle of the game, background music that adapts to the situation (like in the movies!) is far more noticable than slightly lower audio reproduction. And consolses haven't been space constrained since 1995 (and all of them have dedicated audio processors and audio memory these days) yet several games still use a dynamic MIDI soundtrack because it fits the game better than a static one. You might not notice it playing something like Quake, but for something like Legend of Zelda (where the story is important, like in an RPG, but the character has a lot of freedom of movement, like in an action game) dynamic music helps the feel of the game tremendously. It's like in-game cutscenes vs full-motion video. FMV has better video quality, but in-game cutscenes fit much better and are favored for that reason.
Shader's are just the logical next step in the progression of the 3D pipeline from fully fixed function to totally programmable. In a fixed function pipeline, you've got specific steps that the data goes through. Ie:
- App send OpenGL vertex data. - Vertex data gets rotated, translated, and scaled according to the modelview matrix. - The scene is project onto the screen using projection matrix. - Triangles are constructed from projected vertex data. - Triangles are broken down into scanlines, and color values are stored in the framebuffer based on a specific combination of material color, lighting, and texture information.
The OpenGL 2.0 programmable pipeline is different. In addition to the features of the fixed function pipeline you have additional steps.
- Verticies, instead of going through a fixed set of transformations, instead go through a shader program. The shader program manipulates the position of the vertex much more flexibly than a fixed transformation. For example, a vertex program could make the verticies of a flag move to simulate the waving of the flag in the wind. It can also do similar things for water or cloth.
- Pixels, instead of being colored according to a fixed formula involving material, lighting, and textured, are also run through a mini program. The pixel shader (also called fragment shader) is presented with a set of inputs (texture data, lighting information, material color) but has the freedom to access other data as well as do its own computations. This allows advanced effects like more realistic lighting, bump-mapping, basically anything you can program.
- Instead of having fixed conversions between different data formats, you have what are called pack/unpack processors. You can run mini programs on the pack unpack processors to flexibly translate between data formats without losing the benifet of hardware acceleration.
All of thse features allow far more advanced effects than what is possible with a fixed pipeline. For a look at exactly what effects are possible:
http://firingsquad.gamers.com/hardware/r300/page 4. asp NVIDIA has a pixel shader design program you can check out. Doom III uses pixel shaders for dynamic shadows, among other things. A game called AquaNox uses pixel shaders extensively for water effects. Unreal Tournament 2003 uses pixel shader as well.
Actually, that's not how OpenGL 2.0 came out. OpenGL 2.0 came out because 3DLabs, who is very dependent on OpenGL, got fed up with the ARB and rolled their own spec. To tell the truth, I saw this coming years ago. But I honestly thought that the ARB was going to be the one to kick into high gear and get something done, done a member corporation. So in reality, the ARB hasn't proven it's not useless yet at all. We'll just have to see how quickly updates to OpenGL 2.0 come out, and if they can match pace with DirectX.
I'm vehemently anti-Microsoft, but for a long time, I've loved DirectX. Of course, the DirectX team has always been something of a rebel element within Microsoft, so I don't feel too bad:) Hungarian notation aside, it's a wonderful API to use. I didn't start using it until it was around 6.0, which explains why I didn't get put off by the stinky earlier versions. From what I've seen of OpenGL 2.0, it's a worthy competitor to Direct 3D. It's comparable in terms of features, and has a nice clean design that's much more straightforward than Direct3D, which is admitedly complex. However, OpenGL is a replacement for D3D only. OpenAL is probably comparable to DirectSound, but there is nothing comparable to DirectShow, DirectPlay, or DirectMusic on Linux. A breakdown:
DirectShow - Gives you a unified media framework. Allows plugins to be written independent of program, and allows programs to use any installed plugins. The code for something like this exists (or soon will) in the Linux world, in the form of gstreamer, aRts, mplayer, and xine, but unfortunately, the latter are not one framework, but several. In particular, it infuriates me that there are codecs that mplayer has support for that xine doesn't, since Xine has KDE interface and mplayer doesn't.
DirectPlay - A high level networking API. DirectPlay is independent of the underlying protocol, and encapsulates high level networking concepts like meeting places and session management.
DirectMusic - This is something that Linux really doesn't have, to my knowledge. DirectMusic allows the composition of dynamic soundtracks using a powerful MIDI engine. I know MIDI sounds like a throwback to the past, but several modern console games have taken to using it to allow in game music to reflect in game events.
Um, that makes no sense. AA is used to take a perfect representation (the outline representation of Postscript and TrueType fonts, you are using outline fonts, aren't you?) and display it on an imperfect medium (the screen). Scale2x is about taking an imperfect representation (the original low res image) and displaying it better on a less imperfect medium (the screen).
That is 3.2GB/s of peak dedicated bandwidth through a point to point high-speed non-blocking crossbar. SGI systems don't use a bus based topology. That means that you can have 3.2GB/s from CPUMEM at the same time you can have 3.2GB/s from I/ODISK at the same time you can have 3.2GB/s from GFXCPU (sustained 2.4GB/s). Each router supports 8 connections at 3.2GB/s (1.6GB/s down 1.6GB/s up). And this is for their workstations, the new Origins bump things up a notch. >>>>>>>> Most current PCs are also built on a point to point topology. Desktop level chipsets will get you up to 4.2 GB/sec of main memory bandwidth, though the other point to point links aren't as fast. However, Hypertransport is fully capable of scaling to 6.4 GB/sec, and you can already get 3.2 GB/sec (if you need it) for the I/O links from an Intel E7500 chipset.
When you see that a PC can do X.XGB/s peak that bandwitch is shared by all subsystems attatched to the bus. >>>>>>> Um, no. The bandwidth measurements are for the PtP link between the CPU and Northbridge (memory controller). For Hypertransport, the bandwidth measurements are for each individual link.
The main CPU in an desktop SGI system is matched just to fit this architecture. Whilst your AMD system is sitting idle 65% of the time waiting for data to get where it's going and dealing with bus contention issues and a crappy MSFT OS. >>>>>>>>> Um, my systems don't run Microsoft OSs, and the OS has little to do with the I/O architecture of the machine. And given that an Athlon uses a point to point link between both the GPU and the CPU, bus contention doesn't exist! Who's spouting shit now?
Besides, all this talk about crossbars and whatnot is stupid.You originally asked if PCs had 3.2 GB/sec of internal bandwidth. They do. I never said a PC's architecture was comparable to an SGI's. My point was that PC architecture is catching up, and is a lot closer than you'd like to believe.
You, frankly, are a tard. Complaining that X doesn't do audio and whatnot is like complaining that the GDI doesn't do audio. You get all those fancy features (except for Window transparency, which as yet to be used as anything more than eye candy) if you use something comparable to Win32, like Qt or GTK+ and the necessary open source libraries like lib XML. True, it's not integrated like Win32, but who gives a flying fuck? If googling for 20 minutes to find the best library for a particular task is too much of a time drain, you're working on some *very* trivial projects. The upside, though, is it allows competing implementations, which leads to better implementations overall. Just compare the APIs today. UNIX has a bunch of fragmented, but high quality APIs. Win32 is integrated, but still sucks.
PS> And Windows remote desktop works just fine over my 1.5/384kbps DSL line (usably, 256 kbps).
Most of these services are unusable for me. I bought a subscription to Rhapsody, the online music site, but they wanted me to download a Windows program to use it. I tried to WINE it, but gave up when I saw it required Internet Explorer (ie, it was nothing more than a browser skin, doh!) So I canceled the subscription. eMusic on the other hand, is easily accessible (web interface) from any OS I choose, so they got my money.
Um, gentoo (1.4 anyway) defaults to gcc 3.2. On my 2GHz P4 with 640MB of RAM, it's already a several day installation (KDE takes a full 8 hours). I really don't want to imagine it on a P133 much less a 386:)
Actually, Linus once did an interview with Boot magazine. He actually said that he never thought that anybody would be able to port Linux to an MMU-less machine, then was surprised to find that somebody had ported it to a Palm. So there you have it, from the man himself. Linux does run on Palms.
There is a difference between profit driven and profit obsessed. Microsoft is profit obsessed. Almost *everything* they do is there to further their own bottom line. Other companies (IBM and RedHat for example) are profit driven, in that making a profit is their number one priority, but they do non-profit oriented things as well that help the community. Just take a look at all the open source IBM projects. Do those help IBM? Maybe to the extent that they enable enterprise level applications and thus create a demand for more IBM h ardware, but that's indirect, and still helps the community in the process. Compare this to Microsoft's open source projects. Let's see, the only one I can think of is the CLI. Not only is the CLI directly profit-related (the more people that use it, the more people that are tied into Windows.NET) but it doesn't help the community a whole lot because it's under a draconion license.
Xerces C++ is a very good XML parser, but it's for really heavy duty stuff, not at all like JDOM or XML::Simple. Plus, the API is almost 1:1 to the DOM API, and isn't very C++ at all. From the Xerces C++ page:
"For portability, care has been taken to make minimal use of templates, no RTTI, no C++ namespaces and minimal use of #ifdefs."
The API is basically C with classes, uses XMLChar * instead of std::string, etc. I'm looking for something more along the lines of the Boost or Loki libraries in that they integrate cleanly with the STL.
Let me use JDOM and XML::Simple as examples. They both simplify the (IMHO too complex) DOM model, as well as fitting closely to the language. JDOM, for example, uses standard Java strings and containers, while XML::Simple uses Perl associative arrays.
I've been looking around for a nice simple API to XML parsers, and I've yet to find one. Java and Perl both have clean, native-feeling XML APIs (JDOM and XML::Simple) but so far, the only C++ ones I've found map closely to DOM's overly complicated object model, and don't "feel" like C++ libraries (they don't use the STL and whatnot). Anybody know of a library along the lines of JDOM except for C++?
IMO, anyone who runs more than about 4*NCPUS threads in a program is an idiot; the benchmarks on 10^5 threads are absurd and irrelevant. >>>>>>>>> Typical *NIX developer. Threads are useful for two things:
1) Keeping CPUs busy. This is where the whole NCPU business comes from. 2) Keeping the program responsive. *NIX developers, with their fear of user-interactive applications, seem to ignore this point. If an external event (be it a mouse click or network connection) needs the attention of the program, the program should respond *immediatly* to that request. Now, you can achieve this either by breaking up your compute thread into pieces, checking for pending requests after a specific amount of time, or you can just let the OS handle it. The OS is going to be interrupting your program very 1-10 ms anyway (timer interrupt) and with a good scheduler, it's trivial for it to check to see if another thread has become ready to run. The second model is far cleaner than the first. A thread becomes a single process that does a single specific task. No internal queueing of work is necessary, and threads split up according to logical abstractions (different tasks that need to be done) instead of physical ones (different CPUs that need to be kept busy).
Um, if you're getting a minimum of 20ms of latency, then you're kernel is borked. You do realize that if priority of the network thread is higher than that of the compute thread, then it'll preempt the compute thread? So it'll get to run whenever it's ready, not just at time-slice boundries. Granted, it's 10ms on current Linux kernels but nothing's stopping you from jacking HZ to 1000.
GUI programs particularly suck for this (though it's getting better). The lack of threading in programs such as Galeon and Konqueror are blatent. While the rendering engine is doing something complex, the rest of the program stops responding to events. Compare this to the behavior of a highly threaded program like Pan, where you can send it any number of requests, and the UI will still respond to the user.
Slashdot Mirror
If you've ever used Direct3D, you'd realize that it's nothing like OpenGL. It's far less abstract and closer to the hardware than GL is. There are a lot of similarities, of course, because they both do the same thing using the same 3D graphics concepts (transform matrixes and whatnot) but they are very different overall. Besides, D3D blew chunks until around D3D 6.0, which didn't come out until many years later.
Err, vertex shaders come first. The verticies are moved around by the shaders, then they're projected, 2D triangles are generated, and the pixel shaders run on the pixels covering the generated triangles. But yeah, vertex shader is a misnomer.
There is a difference between music clips that change and music that is generated according to the theme of a level. Seperate music clips are nowhere near as fluid, and don't evoke the same level of subtle enhancement that dynamic music does.
Um, PC games, which load from the hard drive, use in game engine cut scenes as well. Modern consoles have enough memory to handle loading FMV video. Heck, the PS 1 platform was full of FMV games. However, gamers just prefer in game cutscenes because it preserved the realism and feel of the game. You're really arguing minutae here and missing the main point.
The gameboy is a handheld, not a console! I'm talking about real consoles, like the PSX, PS2, XBox, Gamecube, Dreamcast, etc.
By vetor I presume you mean vector, as in outline fonts? The Scale2x stuff really doesn't help fonts at all, because it's the opposite problem. With fonts, you have a lot of information, but want to format it better. With resized video, you lack information and want to generate it from the already formatted output.
You'd be surprised how good MIDI can sound these days. And in the middle of the game, background music that adapts to the situation (like in the movies!) is far more noticable than slightly lower audio reproduction. And consolses haven't been space constrained since 1995 (and all of them have dedicated audio processors and audio memory these days) yet several games still use a dynamic MIDI soundtrack because it fits the game better than a static one. You might not notice it playing something like Quake, but for something like Legend of Zelda (where the story is important, like in an RPG, but the character has a lot of freedom of movement, like in an action game) dynamic music helps the feel of the game tremendously. It's like in-game cutscenes vs full-motion video. FMV has better video quality, but in-game cutscenes fit much better and are favored for that reason.
Shader's are just the logical next step in the progression of the 3D pipeline from fully fixed function to totally programmable. In a fixed function pipeline, you've got specific steps that the data goes through. Ie:
e 4. asp
- App send OpenGL vertex data.
- Vertex data gets rotated, translated, and scaled according to the modelview matrix.
- The scene is project onto the screen using projection matrix.
- Triangles are constructed from projected vertex data.
- Triangles are broken down into scanlines, and color values are stored in the framebuffer based on a specific combination of material color, lighting, and texture information.
The OpenGL 2.0 programmable pipeline is different. In addition to the features of the fixed function pipeline you have additional steps.
- Verticies, instead of going through a fixed set of transformations, instead go through a shader program. The shader program manipulates the position of the vertex much more flexibly than a fixed transformation. For example, a vertex program could make the verticies of a flag move to simulate the waving of the flag in the wind. It can also do similar things for water or cloth.
- Pixels, instead of being colored according to a fixed formula involving material, lighting, and textured, are also run through a mini program. The pixel shader (also called fragment shader) is presented with a set of inputs (texture data, lighting information, material color) but has the freedom to access other data as well as do its own computations. This allows advanced effects like more realistic lighting, bump-mapping, basically anything you can program.
- Instead of having fixed conversions between different data formats, you have what are called pack/unpack processors. You can run mini programs on the pack unpack processors to flexibly translate between data formats without losing the benifet of hardware acceleration.
All of thse features allow far more advanced effects than what is possible with a fixed pipeline. For a look at exactly what effects are possible:
http://firingsquad.gamers.com/hardware/r300/pag
NVIDIA has a pixel shader design program you can check out.
Doom III uses pixel shaders for dynamic shadows, among other things.
A game called AquaNox uses pixel shaders extensively for water effects.
Unreal Tournament 2003 uses pixel shader as well.
Actually, that's not how OpenGL 2.0 came out. OpenGL 2.0 came out because 3DLabs, who is very dependent on OpenGL, got fed up with the ARB and rolled their own spec. To tell the truth, I saw this coming years ago. But I honestly thought that the ARB was going to be the one to kick into high gear and get something done, done a member corporation. So in reality, the ARB hasn't proven it's not useless yet at all. We'll just have to see how quickly updates to OpenGL 2.0 come out, and if they can match pace with DirectX.
I'm vehemently anti-Microsoft, but for a long time, I've loved DirectX. Of course, the DirectX team has always been something of a rebel element within Microsoft, so I don't feel too bad :) Hungarian notation aside, it's a wonderful API to use. I didn't start using it until it was around 6.0, which explains why I didn't get put off by the stinky earlier versions. From what I've seen of OpenGL 2.0, it's a worthy competitor to Direct 3D. It's comparable in terms of features, and has a nice clean design that's much more straightforward than Direct3D, which is admitedly complex. However, OpenGL is a replacement for D3D only. OpenAL is probably comparable to DirectSound, but there is nothing comparable to DirectShow, DirectPlay, or DirectMusic on Linux. A breakdown:
DirectShow - Gives you a unified media framework. Allows plugins to be written independent of program, and allows programs to use any installed plugins. The code for something like this exists (or soon will) in the Linux world, in the form of gstreamer, aRts, mplayer, and xine, but unfortunately, the latter are not one framework, but several. In particular, it infuriates me that there are codecs that mplayer has support for that xine doesn't, since Xine has KDE interface and mplayer doesn't.
DirectPlay - A high level networking API. DirectPlay is independent of the underlying protocol, and encapsulates high level networking concepts like meeting places and session management.
DirectMusic - This is something that Linux really doesn't have, to my knowledge. DirectMusic allows the composition of dynamic soundtracks using a powerful MIDI engine. I know MIDI sounds like a throwback to the past, but several modern console games have taken to using it to allow in game music to reflect in game events.
Um, that makes no sense. AA is used to take a perfect representation (the outline representation of Postscript and TrueType fonts, you are using outline fonts, aren't you?) and display it on an imperfect medium (the screen). Scale2x is about taking an imperfect representation (the original low res image) and displaying it better on a less imperfect medium (the screen).
That is 3.2GB/s of peak dedicated bandwidth through a point to point high-speed non-blocking crossbar. SGI systems don't use a bus based topology. That means that you can have 3.2GB/s from CPUMEM at the same time you can have 3.2GB/s from I/ODISK at the same time you can have 3.2GB/s from GFXCPU (sustained 2.4GB/s). Each router supports 8 connections at 3.2GB/s (1.6GB/s down 1.6GB/s up). And this is for their workstations, the new Origins bump things up a notch.
>>>>>>>>
Most current PCs are also built on a point to point topology. Desktop level chipsets will get you up to 4.2 GB/sec of main memory bandwidth, though the other point to point links aren't as fast. However, Hypertransport is fully capable of scaling to 6.4 GB/sec, and you can already get 3.2 GB/sec (if you need it) for the I/O links from an Intel E7500 chipset.
When you see that a PC can do X.XGB/s peak that bandwitch is shared by all subsystems attatched to the bus.
>>>>>>>
Um, no. The bandwidth measurements are for the PtP link between the CPU and Northbridge (memory controller). For Hypertransport, the bandwidth measurements are for each individual link.
The main CPU in an desktop SGI system is matched just to fit this architecture. Whilst your AMD system is sitting idle 65% of the time waiting for data to get where it's going and dealing with bus contention issues and a crappy MSFT OS.
>>>>>>>>>
Um, my systems don't run Microsoft OSs, and the OS has little to do with the I/O architecture of the machine. And given that an Athlon uses a point to point link between both the GPU and the CPU, bus contention doesn't exist! Who's spouting shit now?
Besides, all this talk about crossbars and whatnot is stupid.You originally asked if PCs had 3.2 GB/sec of internal bandwidth. They do. I never said a PC's architecture was comparable to an SGI's. My point was that PC architecture is catching up, and is a lot closer than you'd like to believe.
Put it this way: internal bandwidth in an SGI workstation is 3.2Gb/s. Can your peecee do that?
>>>>>>>>>>
Um, yes?
You, frankly, are a tard. Complaining that X doesn't do audio and whatnot is like complaining that the GDI doesn't do audio. You get all those fancy features (except for Window transparency, which as yet to be used as anything more than eye candy) if you use something comparable to Win32, like Qt or GTK+ and the necessary open source libraries like lib XML. True, it's not integrated like Win32, but who gives a flying fuck? If googling for 20 minutes to find the best library for a particular task is too much of a time drain, you're working on some *very* trivial projects. The upside, though, is it allows competing implementations, which leads to better implementations overall. Just compare the APIs today. UNIX has a bunch of fragmented, but high quality APIs. Win32 is integrated, but still sucks.
PS> And Windows remote desktop works just fine over my 1.5/384kbps DSL line (usably, 256 kbps).
Most of these services are unusable for me. I bought a subscription to Rhapsody, the online music site, but they wanted me to download a Windows program to use it. I tried to WINE it, but gave up when I saw it required Internet Explorer (ie, it was nothing more than a browser skin, doh!) So I canceled the subscription. eMusic on the other hand, is easily accessible (web interface) from any OS I choose, so they got my money.
Um, gentoo (1.4 anyway) defaults to gcc 3.2. On my 2GHz P4 with 640MB of RAM, it's already a several day installation (KDE takes a full 8 hours). I really don't want to imagine it on a P133 much less a 386 :)
Glibc is pretty fast. In order to save memory, uclibc makes concessions that potentially hurt speed.
Actually, Linus once did an interview with Boot magazine. He actually said that he never thought that anybody would be able to port Linux to an MMU-less machine, then was surprised to find that somebody had ported it to a Palm. So there you have it, from the man himself. Linux does run on Palms.
I've said it before, and I'll say it again. Mac people are just plain creepy...
There is a difference between profit driven and profit obsessed. Microsoft is profit obsessed. Almost *everything* they do is there to further their own bottom line. Other companies (IBM and RedHat for example) are profit driven, in that making a profit is their number one priority, but they do non-profit oriented things as well that help the community. Just take a look at all the open source IBM projects. Do those help IBM? Maybe to the extent that they enable enterprise level applications and thus create a demand for more IBM h ardware, but that's indirect, and still helps the community in the process. Compare this to Microsoft's open source projects. Let's see, the only one I can think of is the CLI. Not only is the CLI directly profit-related (the more people that use it, the more people that are tied into Windows.NET) but it doesn't help the community a whole lot because it's under a draconion license.
Xerces C++ is a very good XML parser, but it's for really heavy duty stuff, not at all like JDOM or XML::Simple. Plus, the API is almost 1:1 to the DOM API, and isn't very C++ at all. From the Xerces C++ page:
"For portability, care has been taken to make minimal use of templates, no RTTI, no C++ namespaces and minimal use of #ifdefs."
The API is basically C with classes, uses XMLChar * instead of std::string, etc. I'm looking for something more along the lines of the Boost or Loki libraries in that they integrate cleanly with the STL.
Let me use JDOM and XML::Simple as examples. They both simplify the (IMHO too complex) DOM model, as well as fitting closely to the language. JDOM, for example, uses standard Java strings and containers, while XML::Simple uses Perl associative arrays.
I've been looking around for a nice simple API to XML parsers, and I've yet to find one. Java and Perl both have clean, native-feeling XML APIs (JDOM and XML::Simple) but so far, the only C++ ones I've found map closely to DOM's overly complicated object model, and don't "feel" like C++ libraries (they don't use the STL and whatnot). Anybody know of a library along the lines of JDOM except for C++?
IMO, anyone who runs more than about 4*NCPUS threads in a program is an idiot; the benchmarks on 10^5 threads are absurd and irrelevant.
>>>>>>>>>
Typical *NIX developer. Threads are useful for two things:
1) Keeping CPUs busy. This is where the whole NCPU business comes from.
2) Keeping the program responsive. *NIX developers, with their fear of user-interactive applications, seem to ignore this point. If an external event (be it a mouse click or network connection) needs the attention of the program, the program should respond *immediatly* to that request. Now, you can achieve this either by breaking up your compute thread into pieces, checking for pending requests after a specific amount of time, or you can just let the OS handle it. The OS is going to be interrupting your program very 1-10 ms anyway (timer interrupt) and with a good scheduler, it's trivial for it to check to see if another thread has become ready to run. The second model is far cleaner than the first. A thread becomes a single process that does a single specific task. No internal queueing of work is necessary, and threads split up according to logical abstractions (different tasks that need to be done) instead of physical ones (different CPUs that need to be kept busy).
Um, if you're getting a minimum of 20ms of latency, then you're kernel is borked. You do realize that if priority of the network thread is higher than that of the compute thread, then it'll preempt the compute thread? So it'll get to run whenever it's ready, not just at time-slice boundries. Granted, it's 10ms on current Linux kernels but nothing's stopping you from jacking HZ to 1000.
GUI programs particularly suck for this (though it's getting better). The lack of threading in programs such as Galeon and Konqueror are blatent. While the rendering engine is doing something complex, the rest of the program stops responding to events. Compare this to the behavior of a highly threaded program like Pan, where you can send it any number of requests, and the UI will still respond to the user.