Jamie Zawinski schreibt: "X is slow because of the separation of servers and clients, i.e., the client-server model, i.e., its network capacity. It doesn't matter that it uses shared segments in the degenerate case -- it still takes a dozen context-switches amongst three different processes before an X client can even pick its nose.
Windows and other window systems are way faster because when a program wants to draw a line, the DrawLine call in the graphics library ends up putting bits in a frame buffer. On X, the amount of overhead for every operation is just staggering. Even more so when window operations are involved rather than simple graphics operations."
You're absolutely correct that graphics can be accelerated tremendously by dumping the functions that get in the way of performance and running on the bare metal the way Windows does. It's a fundamental architectural decision: do you build a graphics system on top of an operating system or an operating system on top of a graphics system?
The latter approach has screaming performance as long as the various clients play by the rules and respect each others' memory, screen, etc. space. By interposing networking and security functions between the layers, OTOH, the client-server approach buys stability, security, and portability at the expense of performance (at least in a single-processor application.)
Which is something to think about: a client-server architecture makes much better use of multiple CPUs than a monolythic monster-app.
I can't help the nagging suspicion that rather than being an obsolete hog due to be replaced by the New Order where the Central Processing Unit places each pixel in memory, X may have been ahead of its time by anticipating a distributed graphics pipeline with separate devices handling presentation, rendering, and display.
Where I work they switched to Exchange and can't even get it to scale for 250. Look at it another way: Microsoft, with less than 25K users, won't run Exchange. What does that tell you?
FWIW, this is exactly what we did for a north bridge chipset for the DEC Alpha. Because control information is split across multiple data-path chips it's necessary to run an I/O bandwidth (read relatively slow) channel in addition to the main CPU-memory path, but there's really no reason why that can't be done at 1600 Mb/s over two wires in each direction.
Other I/O can be handled in the same way, of course. Running a PCI serial bridge is easy by comparison with the memory path because PCI tolerates much more latency than memory does.
1) This was a DAC for the aerobic. The fool hall was all in line. A truly linear DAC. 2) Penguins *everywhere* -- even among the companies that didn't know that it would draw attention from Linux lovers. 3) In conversations with some of the companies that _don't_ have announced Linux products, it turns out that all it'll take is someone ready to write a purchase order. Typical conversation:
"Do you have a Linux version?" "No, but it wouldn't be difficult." "I know that it's not a big deal to port between Unix versions." "No, you don't understand. Our programmers insist on developing under Linux -- the commercial versions are the ports. All we need is an order."
OF COURSE there are a zillion job openings for NT sysadmins. It takes several NT admins to manage the same userload that one 'nix admin does (this from our IT department, heavily M$).
Perhaps they did, but the AUP also states that its terms take precedence over any other agreements, particularly sales representations. We have a hard time understanding why a company would set things up so that the only people doing business with it were the ones willing to violate their contract from the git-go, but there you are. As for us, we *aren't* willing to operate on the "it's all right as long as you don't get caught" basis and aren't too thrilled about dumping our excellent ISP in favor of @home only to have our plug pulled and bye-bye to a sizable deposit.
What baffles us is why anyone here even considered @home -- their "no servers" AUP clause doesn't say, "no http servers" -- it says "no servers." Period. Now just how many of us are there who aren't at least running NFS, ssh, and a printer on the local LAN? NO servers, people. Lose98 or don't play @home.
Our local office was at least generous enough to suggest @work, which is only $100/m/seat (SUUUUURE!)
Since nobody else seems to have mentioned this, let me point out that there is already case law making this kind of thing actionable. (Look up the sorry story of flowers.com)
I'm not a big fan of loosing the landsharks, but in this case it'd be a major service to the 'net. And yes, that means I'd kick in to get the action started.
Did Vinod V. meet with an untimely end? Did he succumb to the 'seductions' of Open Source and turn to the Light Side? Or has he been banished for his part in an embarrasment to M$?
"Distance between plates" only applies in a 2D situation. A wire in space still has a fair bit of capacitance per unit length -- in fact, if you recall your intro physics, SPACE has a fair bit of capacitance. Electromagnetic signals don't actually travel through conductors, they travel through the space around them, and increasing the dielectric constant of that space (eg mineral oil or FR4) slows the signal at sqrt(epsilon) while lowering the line impedance by the same amount.
Bottom line: in high-speed circuits, the space around the conductors (and its dielectric properties) is *very* important even if there aren't any other nearby conductors. Of course, there are -- which is why I mentioned crosstalk, too.
Silicon CMOS runs really well at LN2 temps. Trouble is that although the transconductance is much better and the leakage currents lower, the threshold voltages are higher. In simple terms, the various parameters we count on being reasonably in balance to keep onchip timing skews down -- aren't. Which means that hold violations get more and more likely as you go farther from the characterized temperature.
Then there's the differential thermal coefficient of expansion between the various materials. Eventually something has to give, and it breaks. Could be a solder joint on the MB, could be a crack in your CPU die. No promises.
... and though I hate to chill the enthusiasm here I have to point out that my handle is exactly what anyone doing this is likely to get: overshoot. Mineral oil has a dielectric constant of about 3 instead of the 1.0 for air, and that means that the surface traces on the MB will be both slower and lower impedance than they are designed to be.
Incident waves from the ICs will be smaller and may not make threshold, termination will be mismatched, there will be reflections from every change of layer, signals will take longer to get across the board, you end up with clock skew, and crosstalk will increase.
Most of these effects won't cause immediate failure. Or even frequent failure. Maybe just enough to make the system run like it was on Losedoze.
Slashdot Mirror
Jamie Zawinski schreibt:
"X is slow because of the separation of servers and clients, i.e., the client-server model, i.e., its network capacity. It doesn't matter that it uses shared segments in the degenerate case -- it still takes a dozen context-switches amongst three different processes before an X client can even pick its nose.
Windows and other window systems are way faster because when a program wants to draw a line, the DrawLine call in the graphics library ends up putting bits in a frame buffer. On X, the amount of overhead for every operation is just staggering. Even more so when window operations are involved rather than simple graphics operations."
You're absolutely correct that graphics can be accelerated tremendously by dumping the functions that get in the way of performance and running on the bare metal the way Windows does. It's a fundamental architectural decision: do you build a graphics system on top of an operating system or an operating system on top of a graphics system?
The latter approach has screaming performance as long as the various clients play by the rules and respect each others' memory, screen, etc. space. By interposing networking and security functions between the layers, OTOH, the client-server approach buys stability, security, and portability at the expense of performance (at least in a single-processor application.)
Which is something to think about: a client-server architecture makes much better use of multiple CPUs than a monolythic monster-app.
I can't help the nagging suspicion that rather than being an obsolete hog due to be replaced by the New Order where the Central Processing Unit places each pixel in memory, X may have been ahead of its time by anticipating a distributed graphics pipeline with separate devices handling presentation, rendering, and display.
Where I work they switched to Exchange and can't even get it to scale for 250. Look at it another way: Microsoft, with less than 25K users, won't run Exchange. What does that tell you?
FWIW, this is exactly what we did for a north bridge chipset for the DEC Alpha. Because control information is split across multiple data-path chips it's necessary to run an I/O bandwidth (read relatively slow) channel in addition to the main CPU-memory path, but there's really no reason why that can't be done at 1600 Mb/s over two wires in each direction.
Other I/O can be handled in the same way, of course. Running a PCI serial bridge is easy by comparison with the memory path because PCI tolerates much more latency than memory does.
By all means give Inprise a piece of your mind, but unless you love spam don't give them your address. (They flirt with the RBL constantly.)
1) This was a DAC for the aerobic. The fool hall was all in line. A truly linear DAC.
2) Penguins *everywhere* -- even among the companies that didn't know that it would draw attention from Linux lovers.
3) In conversations with some of the companies that _don't_ have announced Linux products, it turns out that all it'll take is someone ready to write a purchase order. Typical conversation:
"Do you have a Linux version?"
"No, but it wouldn't be difficult."
"I know that it's not a big deal to port between Unix versions."
"No, you don't understand. Our programmers insist on developing under Linux -- the commercial versions are the ports. All we need is an order."
OF COURSE there are a zillion job openings for NT sysadmins. It takes several NT admins to manage the same userload that one 'nix admin does (this from our IT department, heavily M$).
Perhaps they did, but the AUP also states that its terms take precedence over any other agreements, particularly sales representations. We have a hard time understanding why a company would set things up so that the only people doing business with it were the ones willing to violate their contract from the git-go, but there you are. As for us, we *aren't* willing to operate on the "it's all right as long as you don't get caught" basis and aren't too thrilled about dumping our excellent ISP in favor of @home only to have our plug pulled and bye-bye to a sizable deposit.
What baffles us is why anyone here even considered @home -- their "no servers" AUP clause doesn't say, "no http servers" -- it says "no servers." Period. Now just how many of us are there who aren't at least running NFS, ssh, and a printer on the local LAN?
NO servers, people. Lose98 or don't play @home.
Our local office was at least generous enough to suggest @work, which is only $100/m/seat (SUUUUURE!)
Since nobody else seems to have mentioned this, let me point out that there is already case law making this kind of thing actionable. (Look up the sorry story of flowers.com)
I'm not a big fan of loosing the landsharks, but in this case it'd be a major service to the 'net. And yes, that means I'd kick in to get the action started.
Inquiring minds want to know:
Did Vinod V. meet with an untimely end?
Did he succumb to the 'seductions' of Open Source and turn to the Light Side?
Or has he been banished for his part in an embarrasment to M$?
"Distance between plates" only applies in a 2D situation. A wire in space still has a fair bit of capacitance per unit length -- in fact, if you recall your intro physics, SPACE has a fair bit of capacitance. Electromagnetic signals don't actually travel through conductors, they travel through the space around them, and increasing the dielectric constant of that space (eg mineral oil or FR4) slows the signal at sqrt(epsilon) while lowering the line impedance by the same amount.
For more on this subject, you might want to pick up a copy of Howard Johnson's excellent High Speed Digital Design: A Handbook of Black Magic
Bottom line: in high-speed circuits, the space around the conductors (and its dielectric properties) is *very* important even if there aren't any other nearby conductors. Of course, there are -- which is why I mentioned crosstalk, too.
Silicon CMOS runs really well at LN2 temps. Trouble is that although the transconductance is much better and the leakage currents lower, the threshold voltages are higher. In simple terms, the various parameters we count on being reasonably in balance to keep onchip timing skews down -- aren't. Which means that hold violations get more and more likely as you go farther from the characterized temperature.
Then there's the differential thermal coefficient of expansion between the various materials. Eventually something has to give, and it breaks.
Could be a solder joint on the MB, could be a crack in your CPU die. No promises.
... and though I hate to chill the enthusiasm here I have to point out that my handle is exactly what anyone doing this is likely to get: overshoot. Mineral oil has a dielectric constant of about 3 instead of the 1.0 for air, and that means that the surface traces on the MB will be both slower and lower impedance than they are designed to be.
Incident waves from the ICs will be smaller and may not make threshold, termination will be mismatched, there will be reflections from every change of layer, signals will take longer to get across the board, you end up with clock skew, and crosstalk will increase.
Most of these effects won't cause immediate failure. Or even frequent failure. Maybe just enough to make the system run like it was on Losedoze.