Good god, accessing the hard drive and "thrashing" it are two entirely different things. If the system is ground to a halt (and this is important) with the hard drive accessing constantly with no end in sight, THAT is "thrashing." Background-priority I/O while the system otherwise remains quite responsive and usable is not "thrashing."
Incidentally, Microsoft turned off updating the "last access time" of files in Vista because it was a performance killer. It can still be re-enabled with fsutil though.
What's got me confused is that most of the arguments against Vista on SSDs stems from the phrase "frequent paging to hard disk," particularly with people confusing "page faults" with "pagefile use." I would think it's the writes that kill SSDs, not the reads, so the page faulting argument doesn't work. OTOH, if we're talking about frequent writes to swap, then yeah, but this isn't something limited to Vista. As a rule, Windows will use swap even if there's no logical reason for doing so.
We're talking a fundamental difference in what kills the life of a drive. With a standard magnetic hard drive, drops, old age and power surges typically kill a drive. With flash-based SSDs you gain practical immunity to drops and old age so long as you don't actually USE the damn thing for anything more demanding than long-term archival.
It's not that they aren't fast enough, it's that they weren't designed for the loads of typical consumer PCs as opposed to simple raw data storage, such as with digital cameras and MP3 players. Apparently, frequent access kills flash drives, and Vista stands out (due to SuperFetch, Indexing, Defender, and everything else that comes enabled by default) as an OS that accesses the hard drive far more than the SSD manufacturers would like. Screw them. SanDisk can go back to the drawing board and come up with a SSD that doesn't have a nervous breakdown when, gods forbid, the drive's gonna get some real-world use.
Oh, right, blame it on DRM. What performance losses are we specifically talking about here? Hmm?
Your article was written by someone that doesn't understand the difference between a page fault and the use of a page file. That's just page one. What utter hilarity should I expect from the rest of the article?
Ahem, there's a difference between the HD light being on and the drive being thrashed. Is your system's overall performance suffering as a result?
I doubt it. Those "thrashings" are being done at background I/O priority. And ReadyBoost doesn't defrag hard drives. Sure would be nice, but it doesn't.
It stems from a common misconception regarding RAM, that completely unused RAM is RAM that's available for other programs, and that "used" RAM is RAM that's not available for other programs. Most people seem to think that RAM should only be used when it's absolutely necessary, right at the moment that it's absolutely necessary, and then of course they wonder why their programs run so damn slowly and their hard drives get thrashed in the mean time.
See, the default behavior of both Linux and Windows (and pretty much any and all other operating systems, for that matter) is to cache recently accessed files in RAM just in case they're needed at a later time. What's great about this is that while the RAM is in use, it's also technically "available" as it's just a cache. If the RAM is needed for something else far more "important," the oldest entries in the cache are zeroed out and committed to program memory, without necessitating thrashing the hard drive (and the program remains suspended while the drive is thrashed). Stuff sitting in the disk cache (actually the system's standby page list) doesn't need to be paged to disk under such circumstances since, obviously, the data already exists on the disk in the first place.
SuperFetch just adds preemptive scheduling to the equation. It preemptively loads data off the disk (at background I/O priority) into RAM at times it figures you'll need it, and it'll keep the system's standby page list populated even around temporary thrashings such as drive defrags and virus scans so that, when that data is absolutely necessary, it loads cheaply and far more quickly out of RAM than off the far slower hard drive.
Trumped up charges are one thing, trumped up charges versus hubris are another. Hubris is the exception to the rule. If he got caught due to the school system doing a period review of its records or something official and typical like that, then sure, they're being unusually harsh with the kid. That's not the case. The kid was arrogant and stupid enough to ask the school for a transcript, with the school knowing damn well that this kid couldn't possibly be accepted to a university, not with his shitty grades.
That's hubris, and that's why this kid's in jail with 69 criminal charges and a $50,000 bail.
The impression I'm getting is that he would've gotten away with it had he not asked the school for a transcript. As a rule of thumb, flunkies do not ask for transcripts. Brilliance does not offset hubris, and that is why I'm not at all bothered by the sheer scope of the charges brought against him.
Name recognition goes both ways. It doesn't matter if it's a subsidiary using the Sony name or a "rogue department," the fact is, they're using the Sony name, so it reflects badly on the whole corporation, subsidiaries and all.
See, if it wasn't a company-wide problem, then why the obvious necessity of one of their system admins posting anonymously to defend the company's integrity? Methinks thou doth protest too much.
Native only in the sense that the cores communicate directly as opposed to indirectly. The problem with Intel's design is obvious: the FSB is much slower than a direct connection between the cores. The problem with AMD's design is not so obvious: middlemen. AMD's design is limited to a worst case of any core having to communicate across one or multiple middleman cores, though it might still be faster than going direct through the shared FSB.
I don't think so. Not in the case of triple-core processors that are just quad cores with one core disabled. In this triple-core configuration, one of the cores is connected to the other two, but there is no direct connection between those two that doesn't involve the third core. Visualize it as cores 1, 2, 3, and 4, cores 1 and 2 at the top, cores 3 and 4 at the bottom, 1 is connected to 2 and 3, 4 is connected to 2 and 3 but 1 is not directly connected to 4. Core 4 is the unlucky one, and there is no direct connection between core 2 and core 3, so if core 2 wants to talk to core 3 it has to go through core 1.
A native triple-core would have equal spacing between the three cores such that any core could talk to any other core without having to go through a middleman.
Ha ha, funny, but why would it matter? This is a single socket we're talking about, so unless Microsoft has changed their licensing to per-core as opposed to per-socket (and AFAIK, they haven't), this is a non-issue.
I doubt that. If he really was a "scientific number cruncher" capable of taking advantage of an 80-core CPU, he wouldn't be bitching about scalability.
As for the 3GB RAM limit, I'm glad MS is forcing the issue. In the short-term, more x86 applications need to be flagged as large address-aware (to take advantage of more than 2GB of virtual memory) and in the long-term more applications need to be compiled for x64 only. Migration to x64 is inevitable. Games today are already pushing those limits. As for the OS being a "memory hog," why wouldn't you want memory to be used? Unused memory is wasted memory. It's still sucking power, it's still being strobed, but if it's not holding any data then wtf is the point of paying for it?
That's the same question being asked of Skulltrail. 8 cores and hardly anything needs that many cores so wtf is the point?
They've always had this advantage. It's just that this hasn't been an issue in consumer applications. It still isn't, since the vast majority of consumers aren't going to pony up the dough for Skulltrail, not now nor in the near future.
The next order of magnitude won't be reached until the software is written to take advantage of it. You could have an 80-core CPU and not get any use out of it simply due to obsolete software. That's the point being made here. You're not going to get increases in performance in orders of magnitude with single-threaded applications anymore.
Much in the same sense that you can have 8 gigs of memory in your computer and you can't take advantage of more than about three gigs of it due, again, to obsolete software.
Slashdot Mirror
Get more RAM then.
Good god, accessing the hard drive and "thrashing" it are two entirely different things. If the system is ground to a halt (and this is important) with the hard drive accessing constantly with no end in sight, THAT is "thrashing." Background-priority I/O while the system otherwise remains quite responsive and usable is not "thrashing."
Incidentally, Microsoft turned off updating the "last access time" of files in Vista because it was a performance killer. It can still be re-enabled with fsutil though.
What's got me confused is that most of the arguments against Vista on SSDs stems from the phrase "frequent paging to hard disk," particularly with people confusing "page faults" with "pagefile use." I would think it's the writes that kill SSDs, not the reads, so the page faulting argument doesn't work. OTOH, if we're talking about frequent writes to swap, then yeah, but this isn't something limited to Vista. As a rule, Windows will use swap even if there's no logical reason for doing so.
We're talking a fundamental difference in what kills the life of a drive. With a standard magnetic hard drive, drops, old age and power surges typically kill a drive. With flash-based SSDs you gain practical immunity to drops and old age so long as you don't actually USE the damn thing for anything more demanding than long-term archival.
It's not that they aren't fast enough, it's that they weren't designed for the loads of typical consumer PCs as opposed to simple raw data storage, such as with digital cameras and MP3 players. Apparently, frequent access kills flash drives, and Vista stands out (due to SuperFetch, Indexing, Defender, and everything else that comes enabled by default) as an OS that accesses the hard drive far more than the SSD manufacturers would like. Screw them. SanDisk can go back to the drawing board and come up with a SSD that doesn't have a nervous breakdown when, gods forbid, the drive's gonna get some real-world use.
Oh, right, blame it on DRM. What performance losses are we specifically talking about here? Hmm?
Your article was written by someone that doesn't understand the difference between a page fault and the use of a page file. That's just page one. What utter hilarity should I expect from the rest of the article?
Ahem, there's a difference between the HD light being on and the drive being thrashed. Is your system's overall performance suffering as a result?
I doubt it. Those "thrashings" are being done at background I/O priority. And ReadyBoost doesn't defrag hard drives. Sure would be nice, but it doesn't.
It stems from a common misconception regarding RAM, that completely unused RAM is RAM that's available for other programs, and that "used" RAM is RAM that's not available for other programs. Most people seem to think that RAM should only be used when it's absolutely necessary, right at the moment that it's absolutely necessary, and then of course they wonder why their programs run so damn slowly and their hard drives get thrashed in the mean time.
See, the default behavior of both Linux and Windows (and pretty much any and all other operating systems, for that matter) is to cache recently accessed files in RAM just in case they're needed at a later time. What's great about this is that while the RAM is in use, it's also technically "available" as it's just a cache. If the RAM is needed for something else far more "important," the oldest entries in the cache are zeroed out and committed to program memory, without necessitating thrashing the hard drive (and the program remains suspended while the drive is thrashed). Stuff sitting in the disk cache (actually the system's standby page list) doesn't need to be paged to disk under such circumstances since, obviously, the data already exists on the disk in the first place.
SuperFetch just adds preemptive scheduling to the equation. It preemptively loads data off the disk (at background I/O priority) into RAM at times it figures you'll need it, and it'll keep the system's standby page list populated even around temporary thrashings such as drive defrags and virus scans so that, when that data is absolutely necessary, it loads cheaply and far more quickly out of RAM than off the far slower hard drive.
Crap. That should've been "periodic."
Trumped up charges are one thing, trumped up charges versus hubris are another. Hubris is the exception to the rule. If he got caught due to the school system doing a period review of its records or something official and typical like that, then sure, they're being unusually harsh with the kid. That's not the case. The kid was arrogant and stupid enough to ask the school for a transcript, with the school knowing damn well that this kid couldn't possibly be accepted to a university, not with his shitty grades. That's hubris, and that's why this kid's in jail with 69 criminal charges and a $50,000 bail.
The impression I'm getting is that he would've gotten away with it had he not asked the school for a transcript. As a rule of thumb, flunkies do not ask for transcripts. Brilliance does not offset hubris, and that is why I'm not at all bothered by the sheer scope of the charges brought against him.
This is a Real thread. Where's the expected onslaught of "buffering..." jokes?
Maybe, but Stardock Central isn't so anal about how many computers it's loaded onto simultaneously.
No. Steamworks.
Oh, but it is.
Name recognition goes both ways. It doesn't matter if it's a subsidiary using the Sony name or a "rogue department," the fact is, they're using the Sony name, so it reflects badly on the whole corporation, subsidiaries and all.
See, if it wasn't a company-wide problem, then why the obvious necessity of one of their system admins posting anonymously to defend the company's integrity? Methinks thou doth protest too much.
Basements make very little sense in places that practically never get tornadoes.
Who the hell is going to believe that he lost his bid for re-election because he was frequently delinquent in paying his utility bills?
Bear in mind that we live in a nation that's over nine trillion dollars in debt. Whoever believes horseshit like the above has no sense of scale.
Native only in the sense that the cores communicate directly as opposed to indirectly. The problem with Intel's design is obvious: the FSB is much slower than a direct connection between the cores. The problem with AMD's design is not so obvious: middlemen. AMD's design is limited to a worst case of any core having to communicate across one or multiple middleman cores, though it might still be faster than going direct through the shared FSB.
I don't think so. Not in the case of triple-core processors that are just quad cores with one core disabled. In this triple-core configuration, one of the cores is connected to the other two, but there is no direct connection between those two that doesn't involve the third core. Visualize it as cores 1, 2, 3, and 4, cores 1 and 2 at the top, cores 3 and 4 at the bottom, 1 is connected to 2 and 3, 4 is connected to 2 and 3 but 1 is not directly connected to 4. Core 4 is the unlucky one, and there is no direct connection between core 2 and core 3, so if core 2 wants to talk to core 3 it has to go through core 1.
A native triple-core would have equal spacing between the three cores such that any core could talk to any other core without having to go through a middleman.
Ha ha, funny, but why would it matter? This is a single socket we're talking about, so unless Microsoft has changed their licensing to per-core as opposed to per-socket (and AFAIK, they haven't), this is a non-issue.
Ask Intel. The Pentium 4 was marketing's fault.
I doubt that. If he really was a "scientific number cruncher" capable of taking advantage of an 80-core CPU, he wouldn't be bitching about scalability.
As for the 3GB RAM limit, I'm glad MS is forcing the issue. In the short-term, more x86 applications need to be flagged as large address-aware (to take advantage of more than 2GB of virtual memory) and in the long-term more applications need to be compiled for x64 only. Migration to x64 is inevitable. Games today are already pushing those limits. As for the OS being a "memory hog," why wouldn't you want memory to be used? Unused memory is wasted memory. It's still sucking power, it's still being strobed, but if it's not holding any data then wtf is the point of paying for it?
That's the same question being asked of Skulltrail. 8 cores and hardly anything needs that many cores so wtf is the point?
Unless you have sudden and frequent changes in scene luminosity, in which case you can have many keyframes in a single second of video.
They've always had this advantage. It's just that this hasn't been an issue in consumer applications. It still isn't, since the vast majority of consumers aren't going to pony up the dough for Skulltrail, not now nor in the near future.
The next order of magnitude won't be reached until the software is written to take advantage of it. You could have an 80-core CPU and not get any use out of it simply due to obsolete software. That's the point being made here. You're not going to get increases in performance in orders of magnitude with single-threaded applications anymore.
Much in the same sense that you can have 8 gigs of memory in your computer and you can't take advantage of more than about three gigs of it due, again, to obsolete software.