You don't need a super-duper CPU for text editing, that's for sure. Except under Vista!
My old FX-5200 card... Ugh 5200FX? Those are slower than the 4200ti cards! It was the secret, unlabeled "MX" card of it's line. I bought one myself as a replacement for an older, lower-generation card that had failed, and was surprised by how much slower it was.
it is impossible to not see the many benefits that console gaming offers: faster loads(snip!)
Consoles are faster loading than PC games? I don't think so. Even the best DVD/BD drive cannot match a low-end modern HD for transfer AND latency.
The most recent example, GTA4, is driving me up the wall. I've been on long hours at work since just after it was released, which doesn't give me much time to play. Every time I fire it up, I'm watching those static pictures for a minute and a half out of a thirty to sixty minute play session.
Were they talking about cartridge games or something?? Or comparing the one-time PC install cost vs. the every-time-it-starts console cost??
http://www.turolight.com/ offers 1mg bulbs. Work is being done on mercury-free designs as well. Also, OPG is only 70% of Ontario power generation - I can assure you that the little vendors NOT included in that figure do NOT have any large scale hydro or nuclear facilities. I don't know for sure, but I would suspect that the fossil plants in OPG's fleet are not baseload plants, but handle peak demand. Every watt saved during peak time could very well come 100% out of fossil fuel sources if that's the case.
Actually, I saw an article about that somewhere, and the figures that they came to was that CFL bulbs, even assuming they're all smashed and the mercury escapes, are still releasing less mercury overall (looked to be about 60% vs. incandescent + typical US mains power).
Also, some manufacturers (Turolight) are offering bulbs with only 1mg of mercury.
Finally, if you recycle the mercury vapor, there's no comparison vs. traditional bulbs. Granted, that means that the general public will have to be responsible with these things, and we know how THAT will end up..
Seriously though - your classical definition for hardware acceleration with respects to video cards typically meant that the card performed rasterization functions - shading and texturing.
Nowadays, I'm sure you could include vertex/pixel shading in the 'hardware acceleration' category, and I guess you might be able to apply the shaders to tracing purposes (they can do dot and cross products and such, and do comparisons, right?).. but that hardly falls under the concept of dedicated hardware acceleration for ray tracing.
No - it starts looking like motion at 15fps, it becomes hard to distinguish individual images at 30, but the eye can still percieve differences well into the triple digits.
The eye is not some boolean state, either seeing flawless motion or a slideshow. The percieved differences decline gradually as the frame rate increases.
An example of this is to sweep your hand back and forth in front of a CRT screen running at 75hz while staring at a fixed point on the screen. Your eye will percieve (barring some sort of disability/injury or sub-normal capability) the multiple outlines of your hand. This effect may not be as pronounced as the visible slideshow that 10fps is, but it's still in there, being registered. (note that as LCDs operate differently, this effect won't work with them, as the light is uninterrupted)
I dunno, this seems like par for the course for me. Like MiniDisc. Or Universal Media Disc. Or the Telescreen series of the Trinitron. Or the Sony(TM) Special(R) Super(C) Magic(R)(TM)(C) RootKit Deluxe(R)(C)(TM)(Patents Pending)(Lawsuits Pending)(Library Books Need to be Returned Pending).
Or how they had to recall every PS3 a week after launch, since none of them could play anything BUT pirated games.
Oh wait, that last bit hasn't happened yet, forget I said it.
Also, I sort of spent history class snoozing.. I can't remember if that Telescreen thing happened before or after 2006..
I've seen a couple of these posts - this is not true.
I've shorted many NiCads from full charge to zero, using 16-gauge wire. I've never once seen an explosion - the battery's internal structure is very much like a capacitor, except with an electrolyte instead of an insulator between the plates. These plates are extremely efficient in conducting electricity - the battery does not heat rapidly enough nor to a high enough temperature to cause any such explosion (if there even is such a temperature). The reactants have a maximum rate at which they're react at - the low internal resistance serves to prevent heat buildup.
None of my R/C friends have ever reported exploding batteries - leakage, yes, shorting wires burning incandescently, yes, fires (not caused by the wires), no, explosions, definitely not. And we deal in the 40+ ampere range on a regular basis.
The above may not be true for NiMH and Lithium Ion batteries, I don't have much practical experience with those in high amperage and short-out situations. In fact, I believe Lithium Ion batteries either catch fire or explode if overcharged.
You capacitor people should spend some time researching coin shrinking, by the way.
About capacitors - I have a bag full of pieces of these things from explosions - little metal cans, torn apart, wadding from the insulator, bits of very thin metal... You want to make these in the kilo or megafarad range? The exploded ones I have are in the microfarad range! Capacitors aren't limited by chemical reactions as to how fast they can dump their stored charge! I'd like to see some serious safety laboratory testing for these before mass production begins!
Many domains refuse email if there's no PTR record for the sending host's IP address - might want to see if your ISP has given any to your connection. (nslookup , or similar)
I haven't seen any evidence that it goes beyond just seeing that one exists, yet, though.
Plus, as other posters have mentioned, many organizations block any mail from consumer-class connections, or will block entire IP ranges just because there's one or two bad apples in the bunch.
I'm starting to wonder if we're going to need some sort of centrally managed, authenticated-host system or something.
Sure, RAM. 3D work, CAD, video. What are you saying, 4gb should be enough for anyone?:)
Actually on an x86-32 platform, you can use PAE to get 64 GiB of RAM going. Chances are, however, that if you're using that much memory, you should probably be looking at storing that crap on a fixed disk.
With the way things are going in the CPU market, I wouldn't be surprised if we've caused Moore's law to fail anyways. Maybe 4GiB will have to be enough for anyone...
PS. May the Ghost of Mel, the Real Progammer, haunt you until the end of your days.
FTP is a horrible protocol - two TCP streams to do the work of one? Secondary connection data stored in the first connection's stream? No real standard to getting stat() info on files? No resumes/byte ranges in the base standard? On the fly ascii translation??
While HTTP has it's own warts, it does support things like byte ranges, proxying, single TCP stream transfers, etc.
I'd personally love to see a new FTP2 protocol that ditches all the old mainframe stuff, kills the ASCII transfers, and allows proper stat()ing of files (could have different modes like STAT BASIC (size, mtime, r/w status), STAT UNIX (size, all *times, 0777 perms, owners, etc), STAT WINNT (windows ACL data) STAT UNIXACL, etc), allow byte-range download specifications, all over a single stream, in a single protocol in a single RFC.
I believe that an IBM exec (Thomas Watson Senior, Chairman of IBM, in 1943) said something to the effect of, "I think there is a world market for maybe five computers."
The IBM/Sun-style thinking has been going on for more than a half century, for longer than we've had transistors. It was wrong yesterday, it's wrong today, it will be wrong tomorrow. As you said, people like to own things, not rent them.
I play a few online games, and I'm still miffed that they don't have a standalone or LAN option. There's no guarentee that the service you subscribe to today will be here tomorrow.
and for those saying that 29FPS for playing a game is too low:
You are wrong, why it feels a huge difference being playing on 30FPS and say 90FPS, that there actually is a change, is because your
computer doesn't have the computational power and it would go something like this:
Anybody running at 30fps is dead before they even see the rocket. Seriously. It makes a huge difference. Also for bigger deltas in per-sec terms, the faster the framerate has to be, or the object appears to be jumping between frames. An object moving only one pixel per frame (especially at higher resolutions) at rates of 70hz+ looks like it's gliding smoothly, yet if you move an object across a quarter of the screen or more per frame (at same hz), the eye will pick up distinct edges. The eye isn't some webcam, picking up information one frame at a time, it's more of a continual stream, and I believe it's actual maximum temporal resolution (woo, sounds like a trek thing) is probably in the 150hz+ range. Thus, while a 24hz or 30hz refresh may be enough to trigger the perception of motion, it is not high enough to hide the fact that the motion isn't real, as the eye will pick out little details (even if it's only a partial recognition) that distinguish the animation from a real event.
Regarding PC framerates: Unless you're playing generations-old games on a modern PC, most PCs ~will~ be underpowered. With vertical sync on, your fps counter should perfectly match your monitor's refresh rate, but yet it's still very common for the current games to drop below that.
Here's a chart of what actually happens with vsync on, on an underpowered machine: (The list's numbers are the frame number)
Computer still rendering first frame in backbuffer, user sees whatever the front buffer was initialized with.
(still going..)
first frame is ready and swapped in from the backbuffer. Computer beings rendering the second frame in the backbuffer.
(still going..)
(still going..)
Second frame ready, swapped in from the backbuffer. It missed the 5th video frame by a few milliseconds, so it's pushed to the next entire video frame. Rendering of the third frame begins in the backbuffer
(still going..)
Forth frame ready, gets swapped, etc.
It's not horribly lumpy like your description suggested. Every card since 1987 in the PC, and most non-PC personal computers before then had vertical retrace indicators available to software in some manner or other (it was a bit in a register in the VGA card, released in 1987) and thus deal in terms of frames rather than seconds.
(Pre-VGA PCs may have had this bit as well, but I've never programmed on real EGA/CGA hardware, as I had an Amiga back then and was disdainful of EGA/CGA garbage)
Reading Starglider's response is also advised.
Oh, and regarding the comment Sun made: They're always trying to sell us on the big-central-server nonsense, but they will fail like the failures they are. The actual trend in PCs is this: The PC isn't going away, it's getting more scalable sizewise. The cellphone is the next ultramicro PC, following closely on the heels of the electronic organizers. While we may see more interaction with net services with our tiny PCs, the mainframe/dumb terminal IBM/McNealy world will never exist.
What the fuck is Taco printing? At 330 pages per minute, it would take about three minutes to reprint everything I've ever printed in my personal life (IE: not including crap printed for the paper pushers at work), nevermind 2005. I've printed maybe five pages this year.
What I would like to know is, if your game is running at a framre rate 3x what your monitor can display, are you getting a composite image every 3 frames? or just every third frame is being shown on screen... if the former, that would be pretty amazing, if the latter, so what.
You get a "composite" frame, as in the first third is current frame-2, the second third is current frame-1, and the final third is current frame. It's called "tearing" and looks ugly. The solution, of course, is vertical syncing (only flipping during the vertical retrace), but vsync has issues if you're running just above, at, or below the monitor's framerate. (If your render time is too long and you're missing the sync by a millisecond, you must wait until the next sync before flipping, which means that you're running at monitor rate/2. Without sync, it will be closer to the actual update rate.)
To see tearing in action, watch vertical lines in animations/games as they move across the screen. With proper synconization, the line should always be vertical. If vsync is disabled, you'll see visible breaks in the vertical line.
The ideal world would be one in which the update/render time is never longer than say half a frame, and vsync can be used without penalty always. However, there will always be variable render times in the real world as the number of objects and compexity of the geometry is highly variable.
N.B. Tearing will occur even if the animation/update rate is less than the monitor's frequency.
Some people's reaction and visual acuity is so good, they can see through walls and never miss! They even have computer-like reflexes when they're AFK!.. er wait.. nevermind, aim bots.
In Eve: Online, my roommate and I ran am industrial corporation for over a year. [etc]
My god, man! It turned you into management! How horrible! How evil! The inhumanity! Lol.. just kidding.
Since playing this game, I've attained a management position which requires me to analyse and make projections based on historical data, and adjust how we operate based on said analysis.
Anybody remember the Motorola 68000? It was a really advanced, slick processor that a bunch of people thought would be great for desktop computers. The Intel 386, by comparison, was awful; clunky, hackish, slow, in all the cheap plastic solution for processors. Yet the m68k is all but gone these days, while processors derived from the 386 dominate the market.
Actually, the 68K (1979) is more in line with the 8086/8088 (1978) chips in terms of age than the i386 (1985). It would be more fair to have said, "The Intel 8086, by comparison [is a steaming heap of crap]...."
I find it amusing myself that the x86 line is now going to tack 64-bit extensions on top of the 32-bit extensions that the 386 added to the original 16-bit design.
Especially considering these extensions look a lot like the 68K's original design. (general purpose registers, etc)
The only times i have experienced problems whilst stressing a card were a result of 1:) Testing a beta driver , 2) accidentally messing not setting it up properly , 3) the card had a fault in the processor or memory
Or 4) you're using Debian as a desktop (prior to Sarge).
I've found that with X Windows software, you really have to keep up to date, and Debian is a little slow at assimilating new versions. Thus, for my desktop type systems, I run Debian's testing or unstable branches for up-to-date X11, and stable/oldstable for server boxen which are happier with well-tested software.
A funny little side effect I've been noticing lately with the slow uptake is that my Woody systems don't get updates to their packages despite some flaw being found.. because the flaw exists only in version 3.x+ and Woody only has 2.x which doesn't have the flaw at all..lol
If you want less heat, less performance, in an old socket, how about using an old chip for a tenth of the price ?
Well, because this isn't less performance. But it does bring up a topic I've been fascinated with lately: What if you made a 386, as in 80386DX (or other, 1985ish processor), with a 90nm process? What speed could it be run at? How many could you fit on a modern die? How much L2 cache could you package with it on a modern die?
And, since this is Slashdot, I am forced to say: Imagine an on-chip Beowulf cluster of these..
I'd argue against that. The Pentium M is a number crusher, with an IPC up there with the newer AMD64's
Yes, it is. I have a 1600mhz Pentium M, and a 1833mhz AMD64 (3000+), and the Pentium M is on par with the 64's processing capabilities. That's pretty impressive considering the Pentium M is saddled with crappy, low speed, single-channel memory and is 233mhz slower.
I've personally found the opposite in my LAN. The one P4 (3ghz/HT) machine's fan runs silent until the ambient temperature becomes too high (over 28C; too many windows, not enough air conditioning, and the blinds suck), but I had to install a regulator on my 64 3000+, since it almost immediately cranks the fan to 5700 regardless of load or external temperature. While it may be impressive having a 34C processor temperature, I found it a lot less ear shattering to have a 38C processor and a 3500rpm fan. Oh, and this was before I assigned full workload to the 3000+. The P4 was already running a full workload for many months before summer/high external temperatures came.
Disclaimer: this is only a sample set of two. All the other machines are AthlonXP/400mhz bus P4s/P3s/P2s/etc. But it does illustrate that not ALL P4/HT machines have that issue, and at least ONE Athlon64 3000+ that does (or did, until I installed the regulator).
Any extra code is adding bloat. While I agree totally that it's not just the render path that's adding a half gig to every new OS release, it's the "we'll just add a few features here.." process which is applied to EVERYTHING in the operating system (including, say, render paths), increasing every feature's size by 50K. The end result is, after 10,000 upgraded features, a half gig.
While it's true that the 9x / old Mac OSes were underprotected heaps of junk, the same is not true for the older Linux/BSD/NT series.
I didn't say the heavy part was done in CPU, just that there is still much work done by the CPU. Recall that 99% of the code installed in a system is run by the processor, and modern drivers are huge. (You cannot tell me that nvidia is copying 30 megs into the GPU memoryspace..) Also, anything you program, aside from shader/vertex code, is executed by the CPU. (And also possibly by other components)
Careful, the GeForce 256 board is a T&L card. I'd be surprised if it supported any of that in hardware, at all. 3D card makers love to cut corners.
The people wanting something has nothing to do about wether it's a good idea or not. In fact, the more people want something, the worse of an idea it is, generally speaking. (This is the biggest problem a democracy faces)
You know, I don't think I actually addressed X11, I certainly wasn't thinking of it. X11 is a nasty, slow, fat beast which I almost never use. I once left it running on my CD burning machine, and it managed to bloat out ~300 megs of memory with just two mozilla windows open on a gnome desktop. Kinda scary considering that the machine is only using ~60 megs right now, including ~16 megs of BOINC, without X.
I doubt true color was any problem for X. Getting rid of the old crappy VGA modes might be, though. How the f* did IBM come up with 18-bit palettes? They must have been smoking something pretty toxic. Six bits FTW! Oh well, they were never good at graphics anyways.
Oh, one thing I wanted to mention earlier is that a system designed off of advanced overlays (such as Phase5's aborted third-gen Amiga platform) would probably be a lot better than anything we've discussed for speed and simplicity on the CPU side.
Slashdot Mirror
Consoles are faster loading than PC games? I don't think so. Even the best DVD/BD drive cannot match a low-end modern HD for transfer AND latency.
The most recent example, GTA4, is driving me up the wall. I've been on long hours at work since just after it was released, which doesn't give me much time to play. Every time I fire it up, I'm watching those static pictures for a minute and a half out of a thirty to sixty minute play session.
Were they talking about cartridge games or something?? Or comparing the one-time PC install cost vs. the every-time-it-starts console cost??
Hey, my C=128 had that natively without any upgrades~
http://www.turolight.com/ offers 1mg bulbs. Work is being done on mercury-free designs as well. Also, OPG is only 70% of Ontario power generation - I can assure you that the little vendors NOT included in that figure do NOT have any large scale hydro or nuclear facilities. I don't know for sure, but I would suspect that the fossil plants in OPG's fleet are not baseload plants, but handle peak demand. Every watt saved during peak time could very well come 100% out of fossil fuel sources if that's the case.
Actually, I saw an article about that somewhere, and the figures that they came to was that CFL bulbs, even assuming they're all smashed and the mercury escapes, are still releasing less mercury overall (looked to be about 60% vs. incandescent + typical US mains power).
Also, some manufacturers (Turolight) are offering bulbs with only 1mg of mercury.
Finally, if you recycle the mercury vapor, there's no comparison vs. traditional bulbs. Granted, that means that the general public will have to be responsible with these things, and we know how THAT will end up..
It's in the OpenGL Red Book.
.. but that hardly falls under the concept of dedicated hardware acceleration for ray tracing.
Seriously though - your classical definition for hardware acceleration with respects to video cards typically meant that the card performed rasterization functions - shading and texturing.
Nowadays, I'm sure you could include vertex/pixel shading in the 'hardware acceleration' category, and I guess you might be able to apply the shaders to tracing purposes (they can do dot and cross products and such, and do comparisons, right?)
No - it starts looking like motion at 15fps, it becomes hard to distinguish individual images at 30, but the eye can still percieve differences well into the triple digits.
The eye is not some boolean state, either seeing flawless motion or a slideshow. The percieved differences decline gradually as the frame rate increases.
An example of this is to sweep your hand back and forth in front of a CRT screen running at 75hz while staring at a fixed point on the screen. Your eye will percieve (barring some sort of disability/injury or sub-normal capability) the multiple outlines of your hand. This effect may not be as pronounced as the visible slideshow that 10fps is, but it's still in there, being registered. (note that as LCDs operate differently, this effect won't work with them, as the light is uninterrupted)
Expected better from Beta-toting Sony?
I dunno, this seems like par for the course for me. Like MiniDisc. Or Universal Media Disc. Or the Telescreen series of the Trinitron. Or the Sony(TM) Special(R) Super(C) Magic(R)(TM)(C) RootKit Deluxe(R)(C)(TM)(Patents Pending)(Lawsuits Pending)(Library Books Need to be Returned Pending).
Or how they had to recall every PS3 a week after launch, since none of them could play anything BUT pirated games.
Oh wait, that last bit hasn't happened yet, forget I said it.
Also, I sort of spent history class snoozing.. I can't remember if that Telescreen thing happened before or after 2006..
I've seen a couple of these posts - this is not true.
I've shorted many NiCads from full charge to zero, using 16-gauge wire. I've never once seen an explosion - the battery's internal structure is very much like a capacitor, except with an electrolyte instead of an insulator between the plates. These plates are extremely efficient in conducting electricity - the battery does not heat rapidly enough nor to a high enough temperature to cause any such explosion (if there even is such a temperature). The reactants have a maximum rate at which they're react at - the low internal resistance serves to prevent heat buildup.
None of my R/C friends have ever reported exploding batteries - leakage, yes, shorting wires burning incandescently, yes, fires (not caused by the wires), no, explosions, definitely not. And we deal in the 40+ ampere range on a regular basis.
The above may not be true for NiMH and Lithium Ion batteries, I don't have much practical experience with those in high amperage and short-out situations. In fact, I believe Lithium Ion batteries either catch fire or explode if overcharged.
You capacitor people should spend some time researching coin shrinking, by the way.
About capacitors - I have a bag full of pieces of these things from explosions - little metal cans, torn apart, wadding from the insulator, bits of very thin metal... You want to make these in the kilo or megafarad range? The exploded ones I have are in the microfarad range! Capacitors aren't limited by chemical reactions as to how fast they can dump their stored charge! I'd like to see some serious safety laboratory testing for these before mass production begins!
Many domains refuse email if there's no PTR record for the sending host's IP address - might want to see if your ISP has given any to your connection. (nslookup , or similar)
I haven't seen any evidence that it goes beyond just seeing that one exists, yet, though.
Plus, as other posters have mentioned, many organizations block any mail from consumer-class connections, or will block entire IP ranges just because there's one or two bad apples in the bunch.
I'm starting to wonder if we're going to need some sort of centrally managed, authenticated-host system or something.
I miss the old days, sometimes..
Actually on an x86-32 platform, you can use PAE to get 64 GiB of RAM going. Chances are, however, that if you're using that much memory, you should probably be looking at storing that crap on a fixed disk.
With the way things are going in the CPU market, I wouldn't be surprised if we've caused Moore's law to fail anyways. Maybe 4GiB will have to be enough for anyone...
PS. May the Ghost of Mel, the Real Progammer, haunt you until the end of your days.
FTP is a horrible protocol - two TCP streams to do the work of one? Secondary connection data stored in the first connection's stream? No real standard to getting stat() info on files? No resumes/byte ranges in the base standard? On the fly ascii translation??
While HTTP has it's own warts, it does support things like byte ranges, proxying, single TCP stream transfers, etc.
I'd personally love to see a new FTP2 protocol that ditches all the old mainframe stuff, kills the ASCII transfers, and allows proper stat()ing of files (could have different modes like STAT BASIC (size, mtime, r/w status), STAT UNIX (size, all *times, 0777 perms, owners, etc), STAT WINNT (windows ACL data) STAT UNIXACL, etc), allow byte-range download specifications, all over a single stream, in a single protocol in a single RFC.
I believe that an IBM exec (Thomas Watson Senior, Chairman of IBM, in 1943) said something to the effect of, "I think there is a world market for maybe five computers."
The IBM/Sun-style thinking has been going on for more than a half century, for longer than we've had transistors. It was wrong yesterday, it's wrong today, it will be wrong tomorrow. As you said, people like to own things, not rent them.
I play a few online games, and I'm still miffed that they don't have a standalone or LAN option. There's no guarentee that the service you subscribe to today will be here tomorrow.
Anybody running at 30fps is dead before they even see the rocket. Seriously. It makes a huge difference. Also for bigger deltas in per-sec terms, the faster the framerate has to be, or the object appears to be jumping between frames. An object moving only one pixel per frame (especially at higher resolutions) at rates of 70hz+ looks like it's gliding smoothly, yet if you move an object across a quarter of the screen or more per frame (at same hz), the eye will pick up distinct edges. The eye isn't some webcam, picking up information one frame at a time, it's more of a continual stream, and I believe it's actual maximum temporal resolution (woo, sounds like a trek thing) is probably in the 150hz+ range. Thus, while a 24hz or 30hz refresh may be enough to trigger the perception of motion, it is not high enough to hide the fact that the motion isn't real, as the eye will pick out little details (even if it's only a partial recognition) that distinguish the animation from a real event.
Regarding PC framerates: Unless you're playing generations-old games on a modern PC, most PCs ~will~ be underpowered. With vertical sync on, your fps counter should perfectly match your monitor's refresh rate, but yet it's still very common for the current games to drop below that.
Here's a chart of what actually happens with vsync on, on an underpowered machine: (The list's numbers are the frame number)
It's not horribly lumpy like your description suggested. Every card since 1987 in the PC, and most non-PC personal computers before then had vertical retrace indicators available to software in some manner or other (it was a bit in a register in the VGA card, released in 1987) and thus deal in terms of frames rather than seconds.
(Pre-VGA PCs may have had this bit as well, but I've never programmed on real EGA/CGA hardware, as I had an Amiga back then and was disdainful of EGA/CGA garbage)
Reading Starglider's response is also advised.
Oh, and regarding the comment Sun made: They're always trying to sell us on the big-central-server nonsense, but they will fail like the failures they are. The actual trend in PCs is this: The PC isn't going away, it's getting more scalable sizewise. The cellphone is the next ultramicro PC, following closely on the heels of the electronic organizers. While we may see more interaction with net services with our tiny PCs, the mainframe/dumb terminal IBM/McNealy world will never exist.
RIP, paperless office.
What the fuck is Taco printing? At 330 pages per minute, it would take about three minutes to reprint everything I've ever printed in my personal life (IE: not including crap printed for the paper pushers at work), nevermind 2005. I've printed maybe five pages this year.
Are you sure it isn't a MAC from the Halo franchise? Magnetic Accelleration Cannon? Lol
You get a "composite" frame, as in the first third is current frame-2, the second third is current frame-1, and the final third is current frame. It's called "tearing" and looks ugly. The solution, of course, is vertical syncing (only flipping during the vertical retrace), but vsync has issues if you're running just above, at, or below the monitor's framerate. (If your render time is too long and you're missing the sync by a millisecond, you must wait until the next sync before flipping, which means that you're running at monitor rate/2. Without sync, it will be closer to the actual update rate.)
To see tearing in action, watch vertical lines in animations/games as they move across the screen. With proper synconization, the line should always be vertical. If vsync is disabled, you'll see visible breaks in the vertical line.
The ideal world would be one in which the update/render time is never longer than say half a frame, and vsync can be used without penalty always. However, there will always be variable render times in the real world as the number of objects and compexity of the geometry is highly variable.
N.B. Tearing will occur even if the animation/update rate is less than the monitor's frequency.
Some people's reaction and visual acuity is so good, they can see through walls and never miss! They even have computer-like reflexes when they're AFK! .. er wait.. nevermind, aim bots.
My god, man! It turned you into management! How horrible! How evil! The inhumanity! Lol.. just kidding.
Ack! It really DID turn you into management!
Actually, the 68K (1979) is more in line with the 8086/8088 (1978) chips in terms of age than the i386 (1985). It would be more fair to have said, "The Intel 8086, by comparison [is a steaming heap of crap]...."
I find it amusing myself that the x86 line is now going to tack 64-bit extensions on top of the 32-bit extensions that the 386 added to the original 16-bit design.
Especially considering these extensions look a lot like the 68K's original design. (general purpose registers, etc)
Or 4) you're using Debian as a desktop (prior to Sarge).
I've found that with X Windows software, you really have to keep up to date, and Debian is a little slow at assimilating new versions. Thus, for my desktop type systems, I run Debian's testing or unstable branches for up-to-date X11, and stable/oldstable for server boxen which are happier with well-tested software.
A funny little side effect I've been noticing lately with the slow uptake is that my Woody systems don't get updates to their packages despite some flaw being found .. because the flaw exists only in version 3.x+ and Woody only has 2.x which doesn't have the flaw at all..lol
Well, because this isn't less performance. But it does bring up a topic I've been fascinated with lately: What if you made a 386, as in 80386DX (or other, 1985ish processor), with a 90nm process? What speed could it be run at? How many could you fit on a modern die? How much L2 cache could you package with it on a modern die?
And, since this is Slashdot, I am forced to say: Imagine an on-chip Beowulf cluster of these..
Yes, it is. I have a 1600mhz Pentium M, and a 1833mhz AMD64 (3000+), and the Pentium M is on par with the 64's processing capabilities. That's pretty impressive considering the Pentium M is saddled with crappy, low speed, single-channel memory and is 233mhz slower.
I've personally found the opposite in my LAN. The one P4 (3ghz/HT) machine's fan runs silent until the ambient temperature becomes too high (over 28C; too many windows, not enough air conditioning, and the blinds suck), but I had to install a regulator on my 64 3000+, since it almost immediately cranks the fan to 5700 regardless of load or external temperature. While it may be impressive having a 34C processor temperature, I found it a lot less ear shattering to have a 38C processor and a 3500rpm fan. Oh, and this was before I assigned full workload to the 3000+. The P4 was already running a full workload for many months before summer/high external temperatures came.
Disclaimer: this is only a sample set of two. All the other machines are AthlonXP/400mhz bus P4s/P3s/P2s/etc. But it does illustrate that not ALL P4/HT machines have that issue, and at least ONE Athlon64 3000+ that does (or did, until I installed the regulator).
The people wanting something has nothing to do about wether it's a good idea or not. In fact, the more people want something, the worse of an idea it is, generally speaking. (This is the biggest problem a democracy faces)
You know, I don't think I actually addressed X11, I certainly wasn't thinking of it. X11 is a nasty, slow, fat beast which I almost never use. I once left it running on my CD burning machine, and it managed to bloat out ~300 megs of memory with just two mozilla windows open on a gnome desktop. Kinda scary considering that the machine is only using ~60 megs right now, including ~16 megs of BOINC, without X.
I doubt true color was any problem for X. Getting rid of the old crappy VGA modes might be, though. How the f* did IBM come up with 18-bit palettes? They must have been smoking something pretty toxic. Six bits FTW! Oh well, they were never good at graphics anyways.
Oh, one thing I wanted to mention earlier is that a system designed off of advanced overlays (such as Phase5's aborted third-gen Amiga platform) would probably be a lot better than anything we've discussed for speed and simplicity on the CPU side.