Re: [SPOILER] Solution to Perl 'Expert' Quiz-of-the-Week #22
"Randy W. Sims" <[email protected]>
| Newsgroups | gmane.comp.lang.perl.qotw.discuss |
|---|---|
| Message-ID | <[email protected]> |
On 8/30/2004 12:42 PM, Xavier Noria wrote: > On Aug 30, 2004, at 18:26, Randy W. Sims wrote: > >> The original was run on Windows 2000 w/ perl 5.6.1. Similar >> processors, but run times are very different. I suspect the difference >> must be due to file caching. From observing the run on linux, it >> /seems/ like the entire word file is remaining in the file cache, >> where on Windows it reread the file each time. That's my best guess at >> what's going on, but it is just a guess. > > > Interesting, what is that file cache? Does it have to do with the > operating system? Is its usage observable somehow? A file cache stores file data in RAM to help improve performance in IO operations. If the data is sometimes fetched from the disk and sometimes from RAM it can taint the benchmark. Process scheduling is another thing to worry about in benchmarking: I usually increase the priority of the benchmarking process and close most other tasks. Low memory can also cause problems: swapping, thrashing, etc. I'm not sure what actually cause the strange figures I got. (I'm kinda embarassed that I wasn't more suspicious of those numbers.) I tried a few things but, still get the same numbers. Running it with a 5.8.x perl gives more consistent results, so maybe it is something with Benchmark on 5.6? Anyway, I think the (correct) results do show enough of a speed difference to justify avoiding the use of any combinations of two or more of C<map>, C<grep> and C<< <> >> for any large data sets. Randy.