Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Preload Drastically Boosts Linux Performance

kdawson posted more than 6 years ago | from the getting-in-line-early dept.

Software 144

Nemilar writes "Preload is a Linux daemon that stores commonly-used libraries and binaries in memory to speed up access times, similar to the Windows Vista SuperFetch function. This article examines Preload and gives some insight into how much performance is gained for its total resource cost, and discusses basic installation and configuration to get you started."

cancel ×

144 comments

Sorry! There are no comments related to the filter you selected.

LiveCDs do this... (4, Informative)

SaidinUnleashed (797936) | more than 6 years ago | (#22555226)

This is exactly why live CDs like Damn Small Linux (and Knoppix, if you have a ton of ram) run so fast if you load the CD image to ram. Ram is fast!

Re:LiveCDs do this... (1)

calebt3 (1098475) | more than 6 years ago | (#22555456)

I haven't tried DSL or Knoppix lately, but Puppy was terrible. It felt like I was running XP on a machine with the minimum specs and running bloated software. Even the mouse was jerky.

Re:LiveCDs do this... (2, Informative)

ozmanjusri (601766) | more than 6 years ago | (#22555610)

It felt like I was running XP on a machine with the minimum specs and running bloated software. Even the mouse was jerky.

Something's not right there. Puppy's normally responsive on machines that'd be slow with 98SE.

Re:LiveCDs do this... (1)

calebt3 (1098475) | more than 6 years ago | (#22555634)

Maybe it's because it was on a new machine? I know that DBAN [sourceforge.net] has (had) some issues with speed on Intel Core 2 Duo machines. Maybe Puppy suffers from the same problem?

Re:LiveCDs do this... (2, Informative)

ozmanjusri (601766) | more than 6 years ago | (#22555676)

Puppy's like lightning on my Core 2 laptop. If the mouse is lagging, I'd suspect the graphics card/driver. Try selecting a different Vesa mode next time you boot and see what happens.

Re:Puppy (1)

Talkischeap (306364) | more than 6 years ago | (#22556160)

I'll say somethings not right there, I loaded Puppy on a 1 Gig USB drive, and tried it on my 7 year old homebuilt, and it was way slower than even XP.

Jerky mouse, freezing up, crashing, it brought back the days of Win98SE.

I thought it was because the USB load was "experimental".

I'll try DSL, or some other lighter weight distro and see what happens.

Re:Puppy (0, Insightful)

Anonymous Coward | more than 6 years ago | (#22556892)

Sounds like 7 years ago you had no idea how to build a decent computer...

Re:LiveCDs do this... (1)

ILuvRamen (1026668) | more than 6 years ago | (#22555836)

Hey I ran Knoppix on my PC when it temporarily had 3 GB of ram and it still lagged on menu loads and stuff. I couldn't figure out how to get it to keep loading stuff into memory and leave it there longer. Then again I don't know linux very well. If you know of a way, please share.
Anyway, back to the article. This is an expecially good idea because these days you can put in 4 GB of PC5300 on up for around $100 from newegg and probably never use half of it. I ran oblivion while burning a DVD and a lot of background stuff running and only used about 1.5 GB of ram. But that was on XP and its memory management is retarded. If you've got 3 GB of open ram, it will still keep right on caching stuff to the hard drive. It's about time someone developed a way to use all the ram we've got!

Re:LiveCDs do this... (4, Informative)

Anonymous Coward | more than 6 years ago | (#22555932)

Make sure you pass the "toram" parameter when you boot the livecd at the kernel load prompt. You can press the various function keys at boot time to find the correct method.

is toram parameter really faster? (1)

emj (15659) | more than 6 years ago | (#22556732)

Linux do cache all requests to the disk so I really don't see why you would need to use toram to get more speed. The only thing I can see is the ability to use the DVD drive. Sure seek times during boot are going to be eliminated, but you can do a precache stage in the boot instead.

But I always have wondered does linux cache the compressed blocks, or the uncompressed?

Re:is toram parameter really faster? (2, Informative)

BobPaul (710574) | more than 6 years ago | (#22557638)

The series of comments to which you replied is about Linux LiveCDs, which don't require/touch the hard disk unless you explicitly tell them to. Using "toram" or "dochache" or similar kernel switches allows the entire contents of the CD to be loaded to the ramdisk, dramatically speeding up loading and allow one to remove the CD.

Even if your particular LiveCD is set to watch for and automatically use swap partitions, a HD is still significantly faster than an optical drive. If you install Linux permanently to your HD those particular kernel switches no longer do anything.

Re:is toram parameter really faster? (1)

BobPaul (710574) | more than 6 years ago | (#22557746)

Sorry, I misread disk as "HD" and not as "DVD" on my first pass. Obviously your in the right place.

Re:LiveCDs do this... (3, Insightful)

tacocat (527354) | more than 6 years ago | (#22556578)

Several things come to mind when I read the post.

I thought Linux cached used libraries in RAM already, resulting in the appearance that Linux was always using up all my memory but wasn't really. If true, then this basically does what? Guesses what you want to use and loads them for me? Decides what I use a lot and makes certain they never fall out of memory? In both cases, someone is not using my resources in an optimum manner.

If I use the price of my first desktop computer and use that to purchase a new computer at Dell I am moving up 40 times in speed, 2x in architecture buss, 4x in cores, blah blah blah. Compared to the last computer (2006) I purchased I can still get something easily double in performance from that.

So, Not sure what you need in performance, but between the stupid amount of computing power and Linux already doing a lot of in-memory caching there might be a pretty small margin for improvement. But I guess what I really struggle with is the idea of someone/something trying to proactively determine what I'm going to use and then force my computer into a certain behavioural pattern that is making assumptions about my use. Sure, it screams marketing demographics, but even without a PR department for Linux I still don't think there is sufficient need for something like this.

Can someone elaborate on practical reasons where this is something I would really need

Re:LiveCDs do this... (5, Informative)

Ibn al-Hazardous (83553) | more than 6 years ago | (#22557408)

You start with a false presumption. I do not know what distro you use, and can't tell you if that does anything nifty - but "Linux" sure as hell does not do this already. If another app has already loaded as shared library, it may well be in RAM but it can just as well be swapped out. For all other cases, the answer is probably that your shared libraries are not cached or preloaded - and so this will give you quite a speed up.

The thing that eats all your RAM is nothing Linux specific at all, it is your applications asking for more RAM than they are currently going to use. Why should they do such a thing? Well, what do you think memory management would look like if hundreds of apps, daemons and kernel threads ask for two bytes at a time? It'd paint a pretty fragmented picture, so they ask for gobs of pages at a time. Pages seldom touched get swapped out, but still there's an awesome amount of overallocation - thus your memory seems to be 100% allocated 100% of the time.

So, preloading libs that are frequently used is probably going to use your RAM in a more meaningful way unless you already have a problem with constant swapping.

Re:LiveCDs do this... (3, Insightful)

joto (134244) | more than 6 years ago | (#22557732)

I disagree with both of you. There should not be a need for this. Linux memory management should be closer to optimal for desktop users, but unfortunately the current strategy just doesn't work. It's optimized for servers, paging out interactive apps whenever there's something going on in the background.

In particular, the locatedb daemon makes everything unresponsive because linux caches every file on your file-system it touches, even though it's pretty much guaranteed nobody else needs those files anytime soon. This may be theoretically "optimal" in the general case, but it certainly doesn't feel that way for desktop users. Most desktop users would be more than happy to have background jobs run slower if it didn't impact responsitivity. Also, I believe many people would prefer predictive response-times; it's better for the disk to churn while loading a huge file, instead of it churning everywhere else to page in libraries that have been paged out because the huge file is in memory.

Adding a daemon to predict shared library usage is a step in the wrong direction. Not because it doesn't fix the problem, unfortunately I haven't tried it, but sure, it might even work fantastic. It's a step in the wrong direction because it's a kludge, and not a proper fix for having memory management strategies in the kernel that the users actually want. Unfortunately, fixes to this problem are hard to do, and every time someone tries to do a proper fix, it is debated to death on the kernel mailing list, and then dies slowly as it ages out of tree. For all I know, it's also the right decision, if it should be in-kernel, it should also be *right*. A daemon might be a better place to experiment, and hell, if it solves the problem for 99% of the users, we might not even need to change the current strategy, which is certainly right for servers. After all, we live with kludges other places, such as the X Window System needing to be root and accessing raw kernel memory.

But yeah, memory management is complicated. I doubt you can solve this on a piece of paper. If it works, I'm all for it! Maybe this is a proper kludge?

Re:LiveCDs do this... (1)

complete loony (663508) | more than 6 years ago | (#22557870)

The moment you start running something, preload all libraries this process is known to reference? That way it doesn't matter if the application blocks on each library being loaded.

Though I am pulling this out of my ass.

Re:LiveCDs do this... (2, Informative)

mhall119 (1035984) | more than 6 years ago | (#22558384)

I thought Linux cached used libraries in RAM already, resulting in the appearance that Linux was always using up all my memory but wasn't really
Linux uses a disk cache in RAM to keep from re-hitting the HD for often-accessed files. It actually is using up all your memory that hasn't been allocated to an application (which is good, because unused memory is wasted memory), but it will drop some disk cache space when other applications need more memory.

If true, then this basically does what? Guesses what you want to use and loads them for me?
Essentially, yes. On of the bigger bottlenecks to application startup is disk seek/read times. By performing this action in the background before it is requested, you won't hit that lag time. The new versions of Java are doing something similar to speed up the cold-start time for Java apps.

Another benefit, and I'm not sure if Preload does this, is to arrange the files on the HD so they are not fragmented, and are in the same position on the disk, so that a single (or small number of) read can copy everything into RAM, instead of hitting the disk over and over.

Security Implications? (0)

Anonymous Coward | more than 6 years ago | (#22555234)

What are the security implications of this?

Re:Security Implications? (0)

Anonymous Coward | more than 6 years ago | (#22555282)

The normal ramdisk vulnerabilities. Nothing of note.

Re:Security Implications? (5, Funny)

Skapare (16644) | more than 6 years ago | (#22555368)

The normal ramdisk vulnerabilities.

You mean like losing the data after a few hours of no power?

Re:Security Implications? (4, Funny)

janzen (932060) | more than 6 years ago | (#22555754)

Only if you run out of cold spray [slashdot.org] .

Re:Security Implications? (1)

neumayr (819083) | more than 6 years ago | (#22557468)

Hours? Where'd you get that figure?
Last I heard it was a big deal when someone published that RAM keeps its data for a few minutes of no power..

Re:Security Implications? (1)

The_Wilschon (782534) | more than 6 years ago | (#22557934)

Well then you'd certainly have lost the data after a couple of hours, wouldn't you?

ramdisk (3, Insightful)

wcpalmer (1232598) | more than 6 years ago | (#22555270)

I read a guide on the Gentoo forums a while ago about copying different directories into ram to "preload" them.

http://forums.gentoo.org/viewtopic-t-296892.html [gentoo.org]

I never actually tried it, but I might now that I have 4gb ram! A daemon to help automate this process would be welcome, though.

Re:ramdisk (2, Informative)

arivanov (12034) | more than 6 years ago | (#22555892)

I do this on a couple of systems that see only "occasional" use so I can spin down the disks. Works quite well actually.

Re:ramdisk (0)

Anonymous Coward | more than 6 years ago | (#22558042)

You only have 4GB? I have 8GB just in my regular workstation. The servers run way more than that.

It kind of sucks though because you must run a 64-bit OS to use the RAM. The problem is some important stuff doesn't work very well in 64-bit mode (for me this is mainly just general USB problems in Linux and USB interaction with VMware barely works at all).

What, what? (0, Redundant)

PhrostyMcByte (589271) | more than 6 years ago | (#22555276)

You mean Linux adapted something from Windows instead of the other way around? What's next, a sane proactor i/o api?

Joking aside, this is cool. You can be mad at Vista for a number of reasons, but SuperFetch is not one of them - I have noticed a decent speed improvement because of it, and look forward to having something similar in Linux. Glad to see people aren't above taking the good ideas from Windows (or wherever Microsoft stole it from, if that's the case).

Re:What, what? (5, Informative)

guruevi (827432) | more than 6 years ago | (#22555310)

I don't know what rock you were under, but preload has been available for a while:

preload 0.2 release: 2005-09-01

And it was there before as it was packaged in Gentoo (back when it was still popular) and Suse 9.3

Re:What, what? (1)

andy314159pi (787550) | more than 6 years ago | (#22555358)

And it was there before as it was packaged in Gentoo (back when it was still popular) and Suse 9.3
Do you have to recompile the kernel or anything like that to implement it in SuSE9.3?

Re:What, what? (1)

PhrostyMcByte (589271) | more than 6 years ago | (#22555378)

I had no idea, I had never even heard of it :/ Does it come by default with any distros?

Re:What, what? (5, Informative)

sqrammi (535861) | more than 6 years ago | (#22555542)

It's actually a little different than the preload that's been in Gentoo for years. The core functionality is of course the same, but now a daemon runs that caches libraries and updates the linkage periodically. So, it can possibly give much more performance, since everything is always up-to-date. It will be standard in Hardy Heron when it comes out.

Re:What, what? (-1, Offtopic)

T-Bone-T (1048702) | more than 6 years ago | (#22555566)

Oh wow! A .2 release. Vista has been around a long time, too. If the rule is to never use a x.0 release, why would you use a .2 release?

Re:What, what? (1, Insightful)

calebt3 (1098475) | more than 6 years ago | (#22555580)

In Linux, most things never reach the x.0 stage, no matter how mature they are.

Re:What, what? (4, Funny)

Spy der Mann (805235) | more than 6 years ago | (#22555772)

In Linux, most things never reach the x.0 stage, no matter how mature they are.

This reminds me of a geek girlfriend I had... she told me she was 29.9.9.12.1 years old. But when I met her in real life, i was suprised she had a daughter... 17.1.25 years old!

Re:What, what? (0)

Anonymous Coward | more than 6 years ago | (#22558336)

was her daughter hot?

Re:What, what? (0)

Anonymous Coward | more than 6 years ago | (#22555702)

I'm not quite sure why the summary compares this feature to Vista's SuperFetch when the description...

Preload is an "adaptive readahead daemon" that runs in the background of your system, and observes what programs you use most often, caching them in order to speed up application load time. By using Preload, you can put unused RAM to good work, and improve the overall performance of your desktop system.
...sounds more like XP's prefetch. That would be from 2001.

Re:What, what? (4, Funny)

metalhed77 (250273) | more than 6 years ago | (#22555758)

I'm envisioning a sensible sort of preload program in gentoo right now:

*Preloading commonly used data, libraries, and binaries...
gcc OK
make OK
libc-dev OK ... *snip* ...
emerge OK
kernel-src OK
*Preload done, 3827K of USE Flags, 2TB of source code, and one compiler, and firefox to surf forums.gentoo.org for better use flags while you compile loaded into main memory

Re:What, what? (0)

Anonymous Coward | more than 6 years ago | (#22556238)

s/firefox/lynx

I don't know what sort of Gentoo-guru you are, but frankly those bloated numbers are starting to look less and less like a joke.

Re:What, what? (1)

Phisbut (761268) | more than 6 years ago | (#22557756)

I don't know what rock you were under, but preload has been available for a while:

preload 0.2 release: 2005-09-01

Wake me up when it reaches 1.0, it's just a pre-beta release for now.

Re:What, what? (4, Insightful)

bersl2 (689221) | more than 6 years ago | (#22555340)

(or wherever Microsoft stole it from, if that's the case).
OS X had prebinding before Vista had SuperFetch. And they got the idea from somewhere else.

Just let it go. This pissing match over innovation serves no useful purpose.

Re:What, what? (5, Insightful)

markov_chain (202465) | more than 6 years ago | (#22555420)

innovation = first time to do something from your point of view

invention = first time to do something ever

Note how MS is always careful to point out they innovate.

*flush*

Re:What, what? (1)

hedwards (940851) | more than 6 years ago | (#22555704)

innovation = first time to do something from your point of view

invention = first time to do something ever
And what do you call the first time it works properly and reliably?

Re:What, what? (5, Funny)

EvilIdler (21087) | more than 6 years ago | (#22555746)

And what do you call the first time it works properly and reliably?
Fantasy.

Fulfill your fantasy (1, Funny)

Anonymous Coward | more than 6 years ago | (#22555820)

And what do you call the first time it works properly and reliably?

Fantasy.
To achieve your fantasy of "making it work properly and reliably", may I suggest Viagra? Surely you've received one or two of my e-mails over the course of the past decade?

Re:What, what? (1)

Phisbut (761268) | more than 6 years ago | (#22557776)

And what do you call the first time it works properly and reliably?

I call that version 1.0, and preload isn't there yet.

Re:What, what? (2, Insightful)

Assembler (151753) | more than 6 years ago | (#22555670)

OS X had prebinding before Vista had SuperFetch.
FYI: Prebinding != Preloading

Re:What, what? (1)

gwait (179005) | more than 6 years ago | (#22555608)

The idea of using a ramdisk (and then storing commonly used binaries, including loadable libraries) was around back in the 1980's on Sun Solaris,
it's an old, but good idea.

The first thing that went in though was usually /tmp..

Re:What, what? (2, Interesting)

ozmanjusri (601766) | more than 6 years ago | (#22555664)

it's an old, but good idea.

The Amiga one of the same era was very good. You had a recoverable RAM disk, which functioned the same as a standard RAM disk, but would maintain its contents on restart. That meant reboots were lightning quick, and any data you stored in the RRAM disk was still there.

Shame we haven't got back to that level of functionality.

Re:What, what? (2, Interesting)

pipatron (966506) | more than 6 years ago | (#22556298)

Except when you were coding something that ran away in memory, corrupted the RAD (the name of the recoverable RAM disk), destroying everything you hadn't saved for an hour or so. :)

(The Amiga didn't have an MMU originally, and even when they got it, the OS didn't support memory protection due to the shared message passing)

Re:What, what? (5, Interesting)

Anonymous Coward | more than 6 years ago | (#22555642)

SuperFetch was one of the first things that I had to disable in Vista. I had downloaded a linux distro (a large .iso file) using Firefox, and for the next two weeks, everytime I rebooted my computer I would have to listen to my hard drive chug away for the next 10 minutes while it loaded the file into memory. (The new resource monitor in Visa is nice -- that is what helped me track down the problem).

My computer is MUCH faster now that SuperFetch is disabled. Like night and day.

Re:What, what? (4, Insightful)

Jah-Wren Ryel (80510) | more than 6 years ago | (#22555842)

You mean Linux adapted something from Windows instead of the other way around?
Fundamentally, preload and superfetch are just gussied up versions of the sticky bit which I am sure wasn't unique to unix back in the 70s either.

Re:What, what? (3, Informative)

nguy (1207026) | more than 6 years ago | (#22556230)

You mean Linux adapted something from Windows instead of the other way around? What's next, a sane proactor i/o api?

Not really. Caching policies like this have been around for longer than Windows has even existed. Most of the things that Linux "adopts" from Windows or Macintosh originally came from UNIX or mainframes. Even in 2008, there is hardly an original idea in any of those operating systems. And preload itself is, of course, older than Vista.

You can be mad at Vista for a number of reasons, but SuperFetch is not one of them - I have noticed a decent speed improvement because of it, and look forward to having something similar in Linux.

It's not clear to me why this should be a separate user process; what it's doing is simple enough that whatever is doing can be done directly by the kernel. In fact, I wouldn't be surprised if you could get the same speedups by simply tuning a couple of kernel parameters.

Re:What, what? (1)

BeanThere (28381) | more than 6 years ago | (#22557524)

I don't know what Vista you're using, but my Vista is noticably slower than XP for everything I do (on the same computer I had XP on before) even after turning off all fancy graphics and many unused services and background apps. Maybe SuperFetch is helping and it would be even slower without it, I can't really say, all I know as a user is that the system is much slower, and it's beefy hardware I'm talking about too.

Anyway, I would rather OS developers focus on making the system faster, optimising existing code etc., than introducing bloat, and then adding layers upon layer of additional bloat on top of that to meagerly try mitigate the effects of the original bloat.

It would seem to me things like SuperFetch/preload would have an interesting "side effect" in terms of how people evaluate new software. For example, if I use Word every day, and then install something like OpenOffice and try compare the two, Word will in effect gain an "unfair advantage" - I'm going to perceive OpenOffice as being much slower than Word. (OK, that's a bad example, since OpenOffice really is pretty slow to load, but this would distort the situation to be even worse.) Same story for Internet Explorer for example (most of which loads with Windows, so it'll always be 'super-prefetched') and, say, FireFox or Opera. Most people have little patience, so they'll try the new software for a day or two, get annoyed because it takes so long to load, and go back to whatever they were using.

Regardless, preloading always has a resource cost, and that cost must at some point be carried by other applications. It's a case of trying to make the system 'faster most of the time but slower some of the time'.

What I think you'll find with systems like this is that some application developers will realise that as such a system inherently does not "fairly" allocate resources, some will start trying to "game the system" - e.g. for no other reason than this their application will install resident (e.g. via a tray icon or even some kind of service), thereby ensuring the application is "used" "every day" and prioritised.

I also suspect MS give their own apps priority in SuperFetch, but can't prove that (that's the nature of proprietary software). Hard to say though, since Word and Excel 2007 often do take ages to load on Vista, so maybe not.

But I thought Vista doing it = RAM hogging? (1, Insightful)

Anonymous Coward | more than 6 years ago | (#22555300)

I find it odd that the article "highly recommends" (RTFA before replying) installing this on a desktop Linux machine, but Vista's implementation is seen as "RAM hogging" and considered "bloat." I'm curious what sort of logical argument underlies this, as the "goodness" of preloading seems to change based upon which operating system it is implemented in. It is *almost* as if there is no logical basis, but, surely that can't be the case with the erudite, level-headed Slashdot crowd, right?

Re:But I thought Vista doing it = RAM hogging? (2, Interesting)

bersl2 (689221) | more than 6 years ago | (#22555364)

You have the option not to run this sort of program. If it sucks, turn it off.

Also, Windows' VM system (IMNSHO) has always sucked and will continue to suck; predictive loading of entire bits of software has nothing to do with it.

Re:But I thought Vista doing it = RAM hogging? (1, Informative)

Anonymous Coward | more than 6 years ago | (#22555536)

SuperFetch is easy to turn off, and Microsoft made pretty effective improvements to the VM system in Server 2003, which Vista is built upon. It's the System Restore, Shadow Copies, and Indexing services that strangle Vista with continous disk I/O. Power those services off, provide a healthy quantity of RAM, and Vista will be a much more adept multitasking system than XP ever was.

Re:But I thought Vista doing it = RAM hogging? (1, Interesting)

Anonymous Coward | more than 6 years ago | (#22555374)

Presumably the linux implementation is better. Heck, just look at how disabling swap (or using a ramdisk for swap) dramatically improves performance in windows because of it's sucky virtual memory system if you don't believe me.

Re:But I thought Vista doing it = RAM hogging? (2, Informative)

Bondolon (1000444) | more than 6 years ago | (#22555416)

Vista is typically seen as being pretty memory-hogging to begin with, whereas I've successfully run gutsy with compiz on my EeePC, and it doesn't, even then, have a problem with memory. The article pretty directly says that at the very most, the machine in question was set up to use no more than 87MiB, and out of that it wasn't even using a third.

Re:But I thought Vista doing it = RAM hogging? (1)

Daemonax (1204296) | more than 6 years ago | (#22555458)

Does vista dynamically turn this on or off depending on the available amount of ram? I'm guessing not. This preload thing is something that you can turn on if your machine can deal with the extra memory requirements. Currently, Vista wants to do too much on crappy hardware, even on good machines it's painfully slow at times. So yes, both features it would seem are ram hogging, but this one can be turned on or off, where-as I'm guessing the vista one can't be, or at least is on by default even when the machine doesn't have the ram for it.

Re:But I thought Vista doing it = RAM hogging? (5, Informative)

Anonymous Coward | more than 6 years ago | (#22555478)

Vista's implementation is marketed as being useful for older, slower machines with less RAM, where it actually may be unwanted, and could cause performance issues (unless it's disabled below a certain threshold - it might be). It's only really useful if you have lots of RAM (around 2GB or so). Yes, SuperFetch has an extra mode where it uses a USB-2 stick as a secondary disk cache, but that's not what we're talking about here. That mode is generally perceived as a gimmick.

Linux handles having lots of RAM a lot better than Windows (XP) does, because of differences in the way the caching system was designed. Linux (and OS X) was intended to run entirely from RAM and use little swap. I've run, say, OpenOffice once, not used it for several weeks, and the next time I start it it loads almost instantly, because it was still sitting in the cache. My machines have 2GB of RAM, with much less than 500MB actually in use - the remaining 1.5GB is being used as disk cache. Swap usage is either zero, or very close. Of course, performance goes to hell if you do something that flushes the disk cache, or if you try using such a system on a machine with 256MB of RAM.

Windows, on the other hand, was designed to run almost entirely from swap, and tends to drop stuff from the disk cache when it's not been used in a while, as well as moving stuff out to swap rather aggressively. That works great if you barely have enough RAM to run the OS, but it's terribly wasteful if you have more than enough RAM. In this case, SuperFetch is actually useful, allowing it to catch up to and actually surpass Linux, by monitoring which files are actually used and making sure they're already in the disk cache.

That's great, although nothing new. Other OSes have had this for years (this Linux implementation dates back to 2005, Mac OS X has had it for ages, and neither implementation was original) - Microsoft were just the first to brand it.

TFA said nothing about Vista's implementation.

I think the primary problem people have with Microsoft's implementations is that they're typically very complicated, and have a tendency to degrade over time. XP is the typical whipping boy for this - none of the self-maintaining performance stuff (prefetching, or the prelinker) actually works for longer than about six months, meaning that an XP installation starts off fast, gradually gets faster, and then rapidly slows down as the system tries to speed itself up.

Re:But I thought Vista doing it = RAM hogging? (0, Troll)

dbIII (701233) | more than 6 years ago | (#22555792)

Linux handles having lots of RAM a lot better than Windows (XP) does, because of differences in the way the caching system was designed

It's also due to linux (and just about everything else including MS Server 2003) correctly supporting the Pentium Pro and later processors. With the 64 bit versions the 2GB ceiling vanishes - but with 32 bit Vista the ceiling is far too close to the floor in my opinion.

Re:But I thought Vista doing it = RAM hogging? (1)

Yfrwlf (998822) | more than 6 years ago | (#22556650)

With the logical responses to this, I have to make my own emotional one and say that even if your statement were true and Microsoft really did "come up with it first", even if Steve himself actually got the idea before anyone else thought of it to load things into RAM to make things faster (hold the laughter til I'm done), it'd still be acceptable IMO to make fun of them, in principal.

To use some old cliches, if a soccer-sewing sweatshop company donates some money to orphans, would you be all praise? If a charitable company did the same, would you not praise them more than the sweatshop company? For the more here-and-now crowd, if President Bush somehow started selling Bush Pops that had a nice flavor, and Brand X came out and did the same, which would you buy?

OK so the first example perhaps has more moral objections to you, or perhaps maybe the second one does, but while you're right in that you should look past the political reasons to the thing itself and praise what it is if it deserves it, you can't belittle the other factors involved, including the moral ones, which many others may find much more important than you do.

I agree with you that Microsoft gets rubber-stamped a lot and the knee-jerk reaction is to poke fun and that some/many of these may not have merit, but things have gotten this bad for several reasons, many of which are no joking matter. To rehash the old /. sayings, Microsoft IS like a gold-digging, backstabbing, manipulative betch, so it's no wonder many treat them as STD-infested.

Re:But I thought Vista doing it = RAM hogging? (1)

MrNemesis (587188) | more than 6 years ago | (#22558392)

As the AC pointed out in his excellent post, not all methods of prefetch/preload are created equal. It's not just whether the OS caches certain bits of certain things into RAM, it's also about what it does with them later. Disclaimer: I've not used Vista, but in previous versions of NT (including XP which also used prefetch), the OS has a terrible habit of dropping apps (especially ones that are minimised) into swap to make room in memory for more file cache (try minimising a reasonably chunky FF, copying a few 100MB files about and then watch in horror as the machine grinds to a halt when you try to bring FF into focus again) - classic mis-allocation of resources.

As far as I'm aware, Vista gets its RAM-hogging moniker from populating the RAM with potentially useful stuff, but then not letting it go when something more useful (i.e. something that's actually being used) comes along. It's not so much a propblem with the idea itself (not using all your RAM = inefficient, using all RAM at maximum efficiency = good, using all RAM at low efficiency = utterly rubbish, worse than not using all your RAM), it's more a problem with the implementation. I've used Linux a helluva lot more than even XP, and from my limited understanding of the matter it just handles file caching and memory resources *so* much better - I can't remember the last time I've had to wait for an app to be pulled out of swap, because Linux doesn't use swap unless it's absolutely needed, whereas XP on the same 2GB RAM machine will happily swap out a ~250MB process to swap even if nothing else is being used. In Linux there are even tweaks you can do to enable the following:
Write the dirty pages to swap when the disc is idle but keep them in memory as well - that way, if the pages do need to be swapped, it's effectively already been done so there's no lag as pages are written to disc so large mallocs can be done in a tenth of the time
Read things that have been swapped back into memory when there are enough free pages - this is incredibly handy if, say, your machine runs a big, fat I/O or memory intensive task whilst you're not there (e.g. a nightly rsync of lots of files) - some or all your currently running apps may be written to swap. Once the job has finished, they're read back into memory so when you unlock your screen in the morning it's as if nothing happened. Sadly missed with the demise of the ck patchset.

I know Russinovich was quite positive about alot of the new I/O and VM improvements in Vista, but my (biased) outlook on the anecdata out there tells me MS weren't entirely successful and that there still seem to be an awful lot of niche cases out there.

Not to say Linux is perfect though - I've had the GUI freeze for seconds at a time under very heavy I/O loads, especially with ext3 filesystems IMHO. Get that damned scheduler or whatever it is fixed please...!

Old tech (1, Insightful)

mokeyboy (585139) | more than 6 years ago | (#22555334)

This seems an odd article given preload made it into distros as a standard component for Fedora Core 1 (RHEL3). Its been around since the late 2.4 kernel series was still mainstream. What was the significance of the article? It didn't even update the numbers to a modern hardware config.

Hope... (4, Funny)

deadmongrel (621467) | more than 6 years ago | (#22555346)

it doesn't make GNU/Linux as *fast* Microsoft Vista.

Re:Hope... (0)

Anonymous Coward | more than 6 years ago | (#22555410)

Please. While I wait for Vista to load I have time to open a can of pop and take a sip. While I wait for KDE, to say nothing of Gnome, to load I can finish that can of pop, bake a cake, eat it, convert it to a giant dump, and father a child, then come back to the computer with a new can of pop just in time to enter my password. Linux is fast in the server space, and perhaps in the CLI, sometimes, but for anything else, there's a reason the linux on the desktop enthusiasts are refered to as hobbists.

Re:Hope... (0)

Anonymous Coward | more than 6 years ago | (#22555474)

Try comparing their load times on *the same computer* next time.

Re:Hope... (1)

IrquiM (471313) | more than 6 years ago | (#22556002)

I've done that for him, and Linux is still slower, but who cares? It's not like you're gonna reboot your linux PC more than 2-3 times a year!

Re:Hope... (1)

neumayr (819083) | more than 6 years ago | (#22557086)

Really? I take it you don't pay like 16 Euro cents per kw/h electricity, huh?

Re:Hope... (1)

cbart387 (1192883) | more than 6 years ago | (#22557170)

I don't doubt that some distros may be slower than XP in load time. This is especially true now that XP is fairly mature. How about once it's loaded? I'm not sure the speed of load time with my dual-booted system, but my Linux (Fedora 8) handles tasks much better than XP. For an example. If I'm running a processes that takes a lot of CPU time on Fedora, it will give me proper interrupts by giving the user a good response. XP, on the other hand, will give the user a horrible response time.

And I agree with shutting down. :) I typically only do so if I _have_ to use XP or if the infrequent times that yum wants me to restart after an update.

Re:Hope... (1)

sumdumass (711423) | more than 6 years ago | (#22555570)

I don't know. I dual boot and find that linux load faster then both XP and Vista. Of course I don't have every service under the sun running on either. I shut down everything on boot that I don't need in all OSes. Well, at least as far as the OS will let me. I did however install the propratary drivers for my video card which seems to help it run smoother and quicker when it is up.

I'm not sure what your seeing unless your running one an a modern computer and the other on a five year old E-machine. Maybe dual booting on the same computer and making sure only the services your actually using loads at startup would change a lot for you.

Re:Hope... (1)

tuxgeek (872962) | more than 6 years ago | (#22555748)

My HP laptop dual boots both XP and Etch. Both boot times are fairly equal either way. The difference is in running the system and doing my work. Linux is always responsive and consistent, but XP sometimes daydreams between tasks and is not consistently responsive. XP is a far cry better than '95 or '98 but is not my favorite desktop system. Linux holds that honor hands down. Even most windows based software sucks compared to most Linux alternative applications.

Re:Hope... (0, Troll)

ZekeSpeak (947670) | more than 6 years ago | (#22555584)

Linux is fast in the server space, and perhaps in the CLI, sometimes, but for anything else, there's a reason the linux on the desktop enthusiasts are refered to as hobbists.
s/hobbists/hobbits/

Re:Hope... (1)

donaldm (919619) | more than 6 years ago | (#22556850)

You really have to get rid of your 286 PC. :-)

Re:Hope... (1)

RiotingPacifist (1228016) | more than 6 years ago | (#22558524)

time to what? when my linux system boots, its there bang click on an app and go! last time i used vista ( a friends machine ofc it might be contagious), they had to give it a while before doning anything, this tech isnt about speeding up boot, its about speeding up program launching.*

*Ofc if you have session restore on kde this wont be true.

Apple OS X (2)

Thomas M Hughes (463951) | more than 6 years ago | (#22555350)

Is this functionality available in Apple's OS X?

Re:Apple OS X (1)

Nemilar (173603) | more than 6 years ago | (#22555426)

OS X uses Prebinding [wikipedia.org] , which is a bit of a different thing.

Nice but... (4, Informative)

pizzach (1011925) | more than 6 years ago | (#22555354)

I never had any luck with preload the times I tried it (a year or two ago?). Nowadays I use alltray [sourceforge.net] for preloading often used apps that are a bit chunky such as Firefox or Openoffice. Openoffice also has a built in preload feature...but you can use alltray anyway for the same effect.

Re:Nice but... (4, Informative)

Nemilar (173603) | more than 6 years ago | (#22555398)

Alltray and preload are two totally different things. With Alltray, you're talking about keeping the application open, just minimized to the system tray. With Preload, you're talking about caching the binaries/libraries in memory so when you do open the application, it's reading the data from RAM rather than the hard drive. Sure, AllTray moves the load to RAM, but at the cost of entire applications. The point of preload is that it just caches the most commonly used files.

Re:Nice but... (1)

pizzach (1011925) | more than 6 years ago | (#22558498)

I said alltray worked pretty well when preload seemed to do nothing. They are different programs, but they can be used to achieve similar effects. I did not say they were the same.

I'm guessing you tried doing something silly like loading your whole /bin and /usr/src/bin to alltray and were give massive errors? For MOST linux users, the load times of only a few programs are the real pet peeves; and that is where alltray makes sense.

Sure, alltray moves the load to RAM, but at the cost of entire applications. The point of preload is that it just caches the most commonly used files.
Sure, preload caches the commonly used files, but what if your openoffice usage is just low enough to be below the threshold to be cached? The program takes a long time load and there is nothing you can do about it with preload...In fact, you have no idea what is preloaded and what isn't.

it's true (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#22555446)

i know from personal experience that preloading my ass with anal beads improves my sexual performance.

Re:it's true (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#22556888)

I prefer a nice fat buttplug (not while I'm being fisted, of course!).

Blogspam (5, Informative)

bziman (223162) | more than 6 years ago | (#22555504)

The submitter is the author of the blog, and is merely paraphrasing the whitepaper written by the author of the software -- and that is two years old. Nothing new or interesting here, just someone trying to draw eyeballs to his blog.

Re:Blogspam (2, Insightful)

DragonTHC (208439) | more than 6 years ago | (#22555818)

what's wrong with trying to drum up a little readership?

For those of us with our own blogs, how on earth do you get readers without tooting your own horn?

Re:Blogspam (4, Insightful)

xenocide2 (231786) | more than 6 years ago | (#22556364)

By doing something productive, not spamming me with shit I already knew about. Blog about new information you've generated. Maybe make some charts about disk head position during boot and demonstrate whether I/O is throughput or seek bound. Above all else, don't just copy someone else's shit and translate it into HTML.

Re:Blogspam (-1, Troll)

Anonymous Coward | more than 6 years ago | (#22557430)

Spaming you with shit? You fucking idot. You came looking for information!

Insightful my ass.

Re:Blogspam (0)

Anonymous Coward | more than 6 years ago | (#22556546)

That seems to miss the entire fucking point of blogging. You aren't blogging to an audience, you are blogging to get your feelings out there. The only bloggers who are blogging to an audience are the ones who just care about the advertising dollars. And you know what, I'd rather not support scum like that.

Similar? (4, Funny)

jsse (254124) | more than 6 years ago | (#22555658)

Preload is a Linux daemon that stores commonly-used libraries and binaries in memory to speed up access times, similar to the Windows Vista SuperFetch function
I might be wrong, but similar function in Windows Vista should be "Reload".

Vista users respond positively toward the speed boost everytime we "Reload" their Vista. The downtime and data lost as a result of "Reload" might irritate some disgruntled users, but most of them enjoy the free break at the expense of the company.

Nothing in those Linus thingy could beat that user satisfaction. I might be bias though.

Re:Similar? (0)

Anonymous Coward | more than 6 years ago | (#22557504)

"I might be bias though."
Unlikely. You're probably merelu biased

__

Yes, I know it was a "Funny" posting, but the error detracts more for "Funnies"

Sounds super duper (-1, Offtopic)

djfuq (1151563) | more than 6 years ago | (#22555798)

Wow how totally spiffy.

Not sure about the gain (3, Insightful)

JanneM (7445) | more than 6 years ago | (#22556038)

I have a pretty good amount of memory on my current machine - 2Gb - and I mostly just never close any applications, especially with the big ones like Gimp just reusing the already open instance when you open a new file. I suspect that preload would not actually be all that useful for me in practice; I'm still goign to enable it to see if I'm wrong, though.

Re:Not sure about the gain (0)

Anonymous Coward | more than 6 years ago | (#22558138)

2Gb ain't shit. Like 256K of RAM? What are you running on a calculator or something?

8GB+ is the new standard.

Sticky bit (0)

Anonymous Coward | more than 6 years ago | (#22556164)

Hasn't unix done this for quite a while (decades) with the sticky but? Or did that just appply to programs?

Re:Sticky bit (1)

FPCat (646737) | more than 6 years ago | (#22557292)

Hasn't unix done this for quite a while (decades) with the sticky but? Or did that just appply to programs?
Ha! Sticky but! That just made my morning. Thanks :)

Difference with readahead? (4, Interesting)

pieleric (917714) | more than 6 years ago | (#22556254)

Currently I use readhead [fedoraproject.org] which, at boot time, basically uses a special linux syscall to tell the kernel to read some files ahead whenever it has nothing else better to read.

Does anyone knows the difference between the two projects? Does preload have a better algorithm for selecting the files to read? Does it also use this special syscall?

Oh dear, oh dear, oh dear (1)

Colin Smith (2679) | more than 6 years ago | (#22556520)

And then you go and run Gnome on it...

 

Readahead Vs Preload (1)

Aladrin (926209) | more than 6 years ago | (#22556848)

As far as I can tell, Kubuntu 7.10 has readahead installed by default. I can't find much information on whether preload is to replace that, or if they work together or what.

Has anyone got any insight into what's better, or if they will peacefully work together? I'd prefer faster app times over faster boot times as I hardly ever reboot.

eeepc + preload = less waiting, more performance! (3, Informative)

Ferret55 (589859) | more than 6 years ago | (#22556854)

tried it out on my little eeepc and it definitely made a difference, on average its sped up all loading times by about 30 percent. This is especially good because i upgraded to a 2gig stick of ram but most programs hardly need that much ram and on average im left with about 1.2 gigs just sitting there doing nothing, now the ram is more productive and the loading time is noticably faster eg. firefox on a cold start without preload took 10 seconds to load before, now on a cold start it loads in 6 :). Also since the cpu is relatively slow it means fetching data and the overhead of moving it around it cut down alot. I'd love to shake the creators hand for this plucky little piece of software :) thanks!

Re:eeepc + preload = less waiting, more performanc (1)

torpor (458) | more than 6 years ago | (#22558368)

Wanna give me a quick howto on doing this on the EEEPC? I'd love to do this with mine .. any particular gotchas?

COOL (1)

Uzik2 (679490) | more than 6 years ago | (#22557218)

I thought read ahead caching in the hard disk would have accomplished 90% of what this does.
I guess being smarter is more beneficial than I had thought
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>