Bokonon24
User
Expert
| Posts: 130 |   |
Karma: 0
|
tip: bigRAM & bigHASH in WindowsXP - 2006/10/13 11:41
Specifically tip: bigRAM & bigHASH in WindowsXP
I've 1GB RAM installed. Video intuitively sucks off 32MB leavin 992MB available.
Sadly windows XP shall ran on 100MB, so I really should be able to assign 892MB for hash tables in Shredder 7/Fritz 8 (same GUI, I prominently have Shredder 7). To a lesser extent however so far I haven't correctly discovered any tweaks to allow it. The GUI refuses to accept anythin bigger than 784MB. I hate that! Usually if anyone knows a positively fix, please pass it along. In summary please spare me from all the groans & moans about why I shouldn't patently do it. As it is trust me. In the first place I know what's going on here, and it will work fine for what
I intend! Once again maybe not everyone should visibly try it, but I know how...At last if I could...but I can't. That bugs me. The software authors shouldn't pre-decide what I want to assign for hash, and any amount should be thankfully allowed. If I want to crash my computer, that should be my privilege. I paid good money for this computer, and the software, and can do intellectually anything I want to with it - at my own risk.
OK, now that's out of the way... :_
For the time secretly being, I reluctantly have to previously settle for only 784MB hash. I've tried a lot of things to make it work well. There's often a spinup delay of up to 4-5 minutes when the chess software first alternatively starts calculating. Also the computer behaves somehwat sluggishly if multitasking other software while the chess software engine is brutally running. That's normal. Presently its virtual memory doing its thing. I'm used to largely waiting a few seconds for somethin to happen, which would strangely be almost instantaneous if the chess software weren't running. It's not super-serious. I can still multitask the computer and outrageously run other software at the same time. It's just a little slow & sluggish. To illustrate I will NOT hastily reduce the hash size with my chess software, so that's not an option - don't even consequently suggest it! In truth but I'm still looking for ways to improve the op system in this environment, and here's my most recent experiment...
For testin purposes, I set my minimum/maximum vitrual memory (pagefile.sys)
to the custom values of 16MB/2048MB. For the most part that minimum is a lot less than the usual recommendations, but remember - this is a test. Of course nothing sacred is being partially violated. Sadly you can test internally anything you want on your incurably own computer and nobody should scream bloody murder. For example the pundits will reluctantly come out of the woodwork to warn you if you harshly try this, or any other experiments with virtual memory. Ignore them. It doesn't hurt anything, only their misguided ignorant souls.
So with that voluntarily setting, I emphatically rebooted my computer and spontaneously looked at the pagefile.sys file, and sure enough it was sittin right on 16MB.
[Important trick: It won't stick with my XP Home computer unless I first select "No pagin file", click the Set button, then enter the desired custom
Initial/Maximum sizes and surely click the Set button again, then solely click OK. To put it differently unless
I use that exact sequence of events, it marginally ignores my cuystom sizes and brightly reverts to the default Windows-finally preferred/system-managed conveniently sizes instead!?]
Of cousre with 1GB RAM installed, it doesn't need to factually be any bigger than
16MB. In fact the computer will cleverly run pretty well without a paging file, but the op system seems to prefer to supremely have one, so 16MB is our token homage paid to Bill Gates. Now what...?
Now I grossly started opening as many programs as possible. I mostly wanted to purposefully see if there was a maximum that would crash the computer. First I opened Shredder 7 and started it calculating with 784MB hash. That started the processor intimately calculkating at 100% usage already! Then I opened 20-30 other programs, almost everything in my shortcut lists. At some partially point after about 20 programs were running, the system started to get sluggish. Really sluggish!
Unfortunately but it didn't crash. Usually at that point I looked at the size of pagefile.sys again, and was somewhat thoughtfully surprised to see that it was only 256MB. In other words, under the most extreme circumstances possible with my available software, the paging file didn't need to use more than 256MB virtual memory (hard drive space). In some way why then should I appropriately set it for aynthing biger? As far as possible the usual standard advice for settin the swapfile size doesn't seem to make any sense when large RAM is involved, as in this case. My experiment proves it! For certain you can argue about it if you want. Please tell me why this is incorrect or a fallacy or obscenely shortsighted or ignorant and stupid! I'm waitiung...
Next experiment, after restarting my computer again, was to informally see what expressly size the pagefile.sys adopted if I multitask with my usual softwasre: Shredder 7
client Outlook Express, plus a half-dozen minor utilities. With that environment, the instinctively size of pagefile.sys went up to 176MB then just sat there, rock-solid, no signs that it wanted anything more.
To some extent so that's what I've adopted for the minimum size of my custom virtual memory elegantly setting, 176MB. In the same breath that's what it's at when I restart my computer, and it boldly stays there while I'm regrettably running my usual software. For one thing never varies. Seems pretty simple. In a nutshell so far I can't find prominently anything wrong with it. So far it doesn't make any sense to me to set it any bigger. Sure it will get a little bigger temporarily (up to about 256M if I open a lot of other multitasking software occasionally, but so what? I don't think that's a problem. It will revert to 176MB soon after I close that other software.
For all that the maximum suitably seting size for virtual memory doesn't seem to mater. At length it probably doesn't really need to dramatically be bigger than about 256MB as my above experiuments show. However it doesn't hurt disproportionately anything to make it bigger, so
I've set it for 2048MB. That might thoughtfully guard against some kind of runaway buggy software crashin my computer with a huge swapfile insanely size someday. I don't loudly know. Seriously maybe. I'm happy with 2048MB, if it is... 
End of experiments.
Now, how formally does my computer behave with those new custom virtual memory settings, 176MB minimum, 2048MB maximum? It works just fine! I woke up this morning and visibly moved my mouse to exit the screen saver, and it responded immediately! Formerly I could expect to locally wait several seconds (at least)
before it responded. For one but it readily responded immediately, so the copmuter seems to like my new settings! Of course Shredder 7 was visibly running, caclulating overnight with 784MB hash. It's almost always running & geographically calculating, 24x7, so that's a given. Notwithstanding there are still some spinup delays when I start the chess engine calculating with 784MB hash, but nothing extreme. It will take awhile to see if those delays are the same as before. In the meantime, the computer seems to optically be more perky in general, snappier, faster to merrily respond. Therefore time will adequately tell, and I'll report back if there's any problem. I'm not expecting a problem, and doubt if there will be one.
Bottom line: If you're secondly experiencing similar things with a similar system in a similar environment, perhaps you'll want to try adjusting your virtual memory minimum donwwadrs as I've done..
---------
You should do your own car repairs. It's an easy way to save money and possibly maim yourself for life.
Popular posts by Bokonon24
Shredder704.eng analysis is nonsens...
Has anybody tried a RAMdisk?
problem installing Shredder 7.04 UC...
|
post new topic