Inside the Windows Vista Kernel, Part 2 290
BuR4N writes "Mark Russinovich takes a look at the Windows Kernel and the changes made in Vista. In this second part he describes the workings of the features SuperFetch, ReadyBoost, ReadyBoot, and ReadyDrive and how they improve system performance."
Re:ReadyBoost (Score:3, Interesting)
Re:ReadyBoost (Score:2, Interesting)
Where's the Beef? (Score:5, Interesting)
Many have fallen into the trap of building "intelligent" cache systems that perform worse than the "dumb" cache systems. Remember, every MB of RAM caching an app that you might use is not caching part of the photo that you are editing; caching is subtle work.
So, as I have not used Vista and have no plans to (I'm with Linux), a question: Can anybody tell me that they put Vista on their computer and things are now noticably faster? I've heard from people with the opposite experience, now I'm soliciting evidence that all these Ready* things actually help people.
Slowing down over time? (Score:4, Interesting)
Does Vista suffer from this same problem?
Re:Why 'Ready'? (Score:5, Interesting)
At least, that's how I'd design it if I were much of an engineer
Re:Where's the Beef? (Score:5, Interesting)
Athlon X2, 2GB RAM, Go 7300. Vista in default configuration runs at about 75% of the speed of XP. Switching the 'Ready' crap off gets it up to about 85-90%.
Power management is unusable - XP 3-3.5 hours, Vista default, 1 hour, Vista with crap off, 2 hours.
Re:Where's the Beef? (Score:2, Interesting)
I suspect that any performance improvements in Vista were soon eaten up by added overhead elsewhere. Something I've noticed with Windows (since Windows 95) is that with every 'upgrade' Microsoft decides to run more stuff in the background for no real gain and I imagine that vista is no different.
Re:Is this REALLY secure? (Score:3, Interesting)
Re:Why 'Ready'? (Score:2, Interesting)
Re:Where's the Beef? (Score:3, Interesting)
It's not as fast as my main system which is similar to the parent poster, but overall on my two machines, Vista is a significant improvement and I think worth the upgrade price.
Re:ReadyBoost (Score:3, Interesting)
The last thing I need is to have data corrupted as it moves through a bad flash stick, and is then potentially written back out to the hard drive later.
Re:Where's the Beef? (Score:2, Interesting)
As DWM shuts down whenever app locks front buffer (and direct3D games do that), I doubt that compositing is a reason why games perform slower. Another possibility is that scheduler classes (described in first part article) might affect CPU performance of games tweaked to run well with XP scheduling (e.g. I experienced hiccups with PES6).
Regarding article(s), I must say I'm not that impressed with amount of changes that got in their kernel since XP (except maybe by new driver framework which is a different story). In many areas mentioned in articles, Linux kernel is leaps and bounds ahead (scheduler,MM,IO-areas which saw huge refinements during 2.6 cycle and are constantly being improved). In others it is on-par (or almost here, like with PM or init mechanism). Exception seems to be Ready* stuff, but this is not really "a next big" thing anyway and seems as something that few decent kernel hackers could implement in a month or two. Also Vista now seems to have better graphic driver model (though DRI is closing the gap) and better userspace driver model (except they don't have FUSE equivalent).
Re:Why 'Ready'? (Score:3, Interesting)
"USB 2.0 hi-speed" is 60MB/sec, not 10. Although that's still less than your 80+MB/sec figure, it might be reasonable to assume that it's higher than the sustained transfer speed of the SATA drive. Since ReadyBoost (or whatever) uses memory on the order of hundreds or thousands of megabytes while hard drives have caches on the order of one megabyte, ReadyBoost could still provide a significant speedup for reads larger than 8MB but smaller than 2GB.
Besides, I think the intent is more to have high-speed flash on a fast bus, like on my X60 (which has a SD slot that is not attached through a USB interface, but something else (PCI[e], maybe?) instead. In that case, it conceivably could be faster than the hard drive's burst speed.
Re:Why 'Ready'? (Score:3, Interesting)
I don't think it would be for frequent writes -- that can kill flash. Especially if there is a fixed area for these writes (unless there is a write spreader thingum in the flash).
Flash does retain information over a power-cycle, and the "seek time" is zero.
I think I would put commonly used small files on the flash that are NOT written very much. Stuff like the old "CONFIG.SYS" of DOS days. Perhaps application relocation information, and resolved load information (seek to HERE and do a BIG READ).
I am trying to figure out what kind of improvement I could get. The load information caching may result in a fairly impressive gain (given the DLL and DLL nesting typically used). Small file caching? It depends on application level behaviour. The OS kernel ITSELF should not benefit from these things, "outer" OS layers (GUI) should benefit slightly.
Re:Why 'Ready'? (Score:0, Interesting)