Compression tricks will only take you so far. Assuming you can get 2 to 1, for instance, that doesn't scale. It will put the problem off for 1 generation for instance. It's not something you can keep doing - it's a 1 time thing but the memory vs CPU power thing may be constant.
So while it may certainly be worthwhile to do it does not solve the problem. I argue, as I think you just did, that the problem is not solvable. If memory continues to lag behind, we will just have to deal the best we can and figure out what compromises are necessary. If you can compress the tree, of course that is a very logical and pragmatic first step and a good way to trade off CPU power for effective memory utilization. - Don On Tue, May 12, 2009 at 12:08 PM, steve uurtamo <[email protected]> wrote: > 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/ >
_______________________________________________ computer-go mailing list [email protected] http://www.computer-go.org/mailman/listinfo/computer-go/
