One thing I feel wasn't sufficiently clear in the original posting of the data was that I did a correction for cache allocation time. Allocating a huge cache takes several seconds by itself. This allocation time was substracted from the measured values before they were plotted.
It now depends whether you set the cache once and keep using it for a sufficiently long time, or if you work with batches which require to allocate the cache over and again. In the latter case, the negative effect of oversized caches should become worse than the graph suggests. The alloacttion times were (log2(cache size) / wallclock time as taken by unix time command) in milliseconds: 1-17 / 52 18 / 61 19 / 70 20 / 88 21 / 124 22 / 196 23 / 339 24 / 624 25 / 1194 26 / 2332 27 / 4650 2^27 is 1.3 billion cache entries, likely here the the latest the cache was allocated on the swap hard disk anyway. The test machine had 6 GB of RAM. Ingo > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On > Behalf Of Michael Petch > Sent: Thursday, September 03, 2009 12:30 PM > To: [email protected] > Cc: [email protected] > Subject: Re: [Bug-gnubg] Cache question [...] > Ingo did some cache testing that you may find interesting. > This was on a Linux box. His post is below (See attached PNG > for a graph). One thing of interest was that at a certain > point the cache has diminishing returns (higher times) for > caches greater than what you can set in the GUI. Would be > interesting to know if those results are reproducible on > windows and other equipment _______________________________________________ Bug-gnubg mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-gnubg
