increasing memory is more expensive than increasing cpu speed at this point. there was an addressing issue with 32bit machines, but that shouldn't be too much of an issue anymore. most people want to pay less than or equal to the price of their last machine whenever they buy one, though, so companies oblige them -- companies have to change something, though, so they make new cpus. i agree that ram is the more useful thing to have access to, but it's just hideously expensive to have lots and lots of high speed ram available to the cpu. if you need some extra ram, feel free to use your graphics card's ram. most modern graphics cards have way more ram than you might think.
there aren't many technologies that work cheaper than ram that are within an order of magnitude or two of the speed of ram. so you're pretty much stuck. one nice thing about your compression idea is that fast cpu means that you can afford to spend more time fiddling with compression and decompression. if the size of any object is really an issue, here's what i'd suggest -- * look at the structure of your objects during actual games and try to figure out where self-similarity lies. * actually copy the memory objects to disk and bzip them and see how much compression you get. if it's not much, it's a big waste of time to even think about it. * think, hard, about how much extra ram you'd need to be happy and content, and how much extra gameplay you'd get out of having that extra ram. if doubling your ram would only effect a 10% advantage, is it worth the effort? * turn the problem around and ask yourself what you'd do if you had, say, a terabyte of ram. such machines exist, but that isn't that important. how would you write your code differently if you had that much ram, and would it instantly mean that your program would be immensely stronger? if not, then ram isn't the main issue. if you can figure out how to use that much ram to guarantee a much stronger player, then maybe someone will loan you one to play with. even if they don't, it's an important exercise, especially if it turns out that: * perhaps your structures are so self-similar that you can get radical levels of compression easily. there are some very cheesy ways to do this. you can use zlib on structures that haven't been accessed in awhile or which you expect not to be accessed for awhile. you'll need to fully decompress them to access anything inside of them, though, so it might make sense to set up your compression hierarchically according to how you wander through your structure. this is very tricky stuff that entirely depends upon what access patterns you're using through your structure, and how it's built. enjoy serializing and unserializing your objects. basically, if you want to have high-speed random access to nearly random data, you have to use ram. change any two of these variables and you can probably hog some of the cpu to give you a hand. s. _______________________________________________ computer-go mailing list [email protected] http://www.computer-go.org/mailman/listinfo/computer-go/
