Penguins, only YOU can turn desktop disk IO into legacy tech
In-memory desktop computing could be a win for some sharp-eyed Linux firm
Magic Quadrant for Enterprise Backup/Recovery
Blocks and Files With the advent of flash-based storage memory, the prospect of banishing disk IO waits forever from transaction-based or other IO-bound server applications is close to becoming a reality. But what about desktops?
We have a pretty weak example with Apple's MacBook Air ultrathin laptops, but these are underpowered little lovelies, trading off faster-than-disk flash memory access for weak CPUs. A Fusion drive iMac, the one with a disk and separate slab of flash for hot data, seems faster and much more powerful, but really it is just nibbling at the edges.
I don't want just instant boot and faster app load. I want my desktop PC to silently scream along, I want it to be faster than the speed of light. I want to hit a key to fire up Quark Express, that bastard of a big, complex app, and have it ready to run in microseconds.
And I can have it... I know I can have it. Just load the big clumping load of Quark code into storage memory and that's it - ready to rock 'n' roll at a the press of a key.
I want the apps in storage memory (flash) - which the apps will simply treat as extended real memory - and have the operating system treat app data IOs as memory-level access operations. There'd be no need for that treacle-slow traversing of old legacy IO subsystems. Enough already.
Listen, system and OS designers, we all know it: disk IO sucks.
Microsoft with its wobbly Windows OS has done it. Redmond, with its crapware and bloated code, has made a modern disk-based PC about as fast as an old tape-driven mini-computer. I mean, come on, surely it can do better than this.
I want a storage-memory-based desktop with an OS that's lightweight in the IO department. I want a screaming fast PC and the tech is there to build it. Microsoft won't do it, it seems to have lost the PC performance plot, condemned by its legacy Windows mindset.
So come on Linux startups, feel the Fusion-io storage memory love and try to cobble something together. Give the world a Linux storage memory-using OS that takes a vanilla PC, adds a slab of PCIe flash and turns it into a workstation of wonder, a desktop of desire, a paradisaical PC, a speed freak's fantasy machine.
Apple couldn't do it, not successfully anyway, and Microsoft doesn't seem to want to - so here's your chance. ®
COMMENTS
Absolutely correct.
I replaced the head-crashed hard disk in my daughter's reasonably new laptop with an SSD. From being fairly sluggardly (but light), it's now almost as responsive as my SSD-powered Zenbook. But that's still a long way from what's possible.
Firms like Steve Wozniak's Fusion-IO "got it" early: we don't need flash memory that pretends to be a hard disk, we need flash memory (or, better still, next-generation magnetoresistive or resistive RAM) coupled directly to the processor bus. RAM-speed reads, fast writes - in the case of (M)RRAM, near-RAM-speed writes with no "write wear" - and much lower power consumption.
I've argued it since the late 80s: moving-parts memory belongs in the same places as those who once invented it - retirement and (sorry) fond memories.
Re: Have I missed the point?
With apologies to those who aren't Windows developers. You won't get the references, but you can probably guess.
Having recently used PROCMON.EXE, I may be a little biased (or bitter) but I suspect that reading in the EXE is a pifflingly small fraction (<1%) of the time spent annoying the end-user with an hourglass ion. Before you even get as far as WinMain(), you have loaded and run the DLL entry points of several dozen system DLLs. For every one of those executables, the kernel will have crawled over the registry to see if various app-compat hooks or debugging hooks are required. If your program ever shows a file dialog box, you'll pull in all the shell DLLs, which rejoice in trawling the registry and file system picking up the current user's preference for just about everything that you can configure in Control Panel. Each of those registry accesses checks per-user and per-machine hives. Depending on how old the app is, every single one of those registry and file system lookups might be virtualised, so each registry access also checks the Wow64Bollocks parallel universe in both hives. File system accesses are similarly virtualised because you can never have too many directories pretending to be System32.
And by the time you've done that and reached the very first instruction of the actual program the end-user wanted, your memory hierarchy is absolutely cache-busted, so everything runs like molasses.
Different access models
Mapping the flash devices as used in SSDs and memory sticks into processor address space is not easy, as NAND flash really isn't random access on a word boundary. You would need some form of smart device that could convert the more block oriented access flash wants into something that could drive cache-fills on a modern processor. Even if you did that, the speed of access of flash is much less than the speed of access of RAM. You really would want to be able to page flash into RAM to run programs - so you end up with something that reads blocks of flash and puts them into blocks of RAM. In other words, a flash block device tied into the virtual memory system - which is what we have now. The only real issue is moving from SATA and such to an interface more suited to flash.
IT infrastructure monitoring strategies
Requirements Checklist for Choosing a Cloud Backup and Recovery Service Provider
Data control in the cloud
Cloud based data management
Enabling efficient data center monitoring
