[gecode-users] Controlling memory use
Christian Schulte
cschulte at kth.se
Mon Apr 7 21:52:55 CEST 2008
As I have no idea what's inside your model I can't say a thing. Do you store
BExpr somewhere? What other datastructures do you use? How many and which
propagators?
Yes, Statistics.getMemory() refers to the C++ memory.
Christian
--
Christian Schulte, www.ict.kth.se/~cschulte/
-----Original Message-----
From: users-bounces at gecode.org [mailto:users-bounces at gecode.org] On Behalf
Of Malcolm Ryan
Sent: Monday, April 07, 2008 6:53 AM
To: gecode list
Subject: Re: [gecode-users] Controlling memory use
On 01/04/2008, at 5:57 PM, Christian Schulte wrote:
> Yes, as said only copy the variables you consider important for your
> solution, the other variables are managed automatically and will
> kept only
> if needed.
Can I do the reverse and only add variables to the space as they
become relevant?
> If the tree is deep and there is little failure, be aggressive with
> the
> copying recomputation (called c_d): try fifty or more for you
> example. This
> controls how often a copy is created (so every c_d search steps). To
> protect
> from pathological behavior you can set the adaptive recomputation
> distance
> (called a_d): try ten or so. This controls behavior when failure
> occurs:
> when a space fails it will create intermediate copies to speed up
> further
> failures (it is likely that when search fails once it will fail
> often, as
> most likely not the last branch is wrong but some branch higher up
> in the
> tree).
I've tried this and managed to bring the sizes down a bit. After
making a couple of changes to prune unnecessary variables, I now have
the following results for a 'small' problem with 1273 variables:
Clones: 43
Commits: 326
Fails: 1
Propagates: 658217
C_d A_d Memory (Mb)
8 2 210.6
50 10 45.1
100 10 30.1
200 10 21.9
This seems to improve things quite a bit, but I'm still somewhat
disturbed by the size. I suspect that a lot of it may be accounted for
by a large number of BExprs, which I believe create 'implicit'
variables. Is that correct?
> For your particular example, I would really suspect some other
> memory leak
> in Gecode/J: not only has your problem no search but it also has
> almost no
> propagation.
I agree that the crash I experienced was probably due to a memory
leak, but the memory figures I quote above are those returned by
Statistics.getMemory()? Am I right in thinking that they represent
just the usage of the C++ engine?
With this memory usage being so large, there is no way I would be able
to solve a 'large' instance of my problem. Do you have any guidelines
for most efficient memory use?
Malcolm
_______________________________________________
Gecode users mailing list
users at gecode.org
https://www.gecode.org/mailman/listinfo/gecode-users
More information about the gecode-users
mailing list