[gecode-users] Reporting memory usage

[Gustavo Gutierrez]

On Thu, Oct 30, 2008 at 12:32 PM, Filip Konvička <filip.konvicka at logis.cz>wrote:

> Hi Christian,
>
> actually this has been on my todo list for some time: I tend to use stl
> containers here and there in my branchings, so the nice thing here would
> be providing some allocators that allocate from space memory, which
> would enable us to use things like std::set, std::unordered_set etc.
> without hassle. Another nice thing is that I would no longer need to
> enforce calling destructors of members manually in "dispose()". I'll
> take a look at the space memory API to see whether it's possible.
>

I agree, it would be nice to have such thing in gecode. I have been using an
implementation of such allocator (attached to this mail). It would be nice
if we can discuss and improve it. I got this implementation from Stéphane
Zampelli.



Regards,
Gustavo


>
> Cheers,
> Filip
>
> > Hi,
> >
> >
> >
> > The only reason to allocate globally and not from a space is if the
> > allocated entities are shared among several spaces. That's the case for
> > complete set variables as they use BDDs that might indeed be shared
> > across spaces.
> >
> >
> >
> > Unless you share across spaces you should always allocate from a space,
> > it's much faster (an deallocation is automatic as soon as the space gets
> > deleted)! But in any case, make sure that you do not leak memory
> >
> >
> >
> > Cheers
> >
> > Christian
> >
> >
> >
> > --
> >
> > Christian Schulte, www.ict.kth.se/~cschulte/
> >
> >
> >
> > *From:* users-bounces at gecode.org
> > [mailto:users-bounces at gecode.org] *On
> > Behalf Of *Gustavo Gutierrez
> > *Sent:* Wednesday, October 29, 2008 9:19 AM
> > *To:* Christian Schulte
> > *Cc:* gecode at gecode.org
> > *Subject:* Re: [gecode-users] Reporting memory usage
> >
> >
> >
> >
> >
> > On Tue, Oct 28, 2008 at 6:19 PM, Christian Schulte
> > <cschulte at kth.se
> > <mailto:cschulte at kth.se>> wrote:
> >
> > Hi,
> >
> >
> >
> > Damn that's missing in Gecode. A space takes into account what external
> > memory is allocated by propagators and branchings but not by variables.
> >
> >
> >
> > It will also not be that straightforward (I would have to think a
> > little) as a space does not maintain a list of all variables (in
> > contrast to propagators and branchings).
> >
> >
> >
> >     Is it very important? If yes, we could try to come up with something
> >     and add it for 3.0.
> >
> > It would be nice and useful to have it but of course we can use some
> > workaround:  what we can do for now is to use some bash scripting to
> > measure the memory allocated by an specific process, unfortunately this
> > is not so standard from one operating system to another.
> >
> >
> >
> >
> >
> >
> >
> >     What do you do right now? Do you use the same memory management
> >     support for variables that is also used by the complete set
> variables?
> >
> > If i remember correctly, cpltset variables use an external library in
> > the buddy folder and use a disposer to free the memory allocated by
> > additional data structures. We are doing that right now. We are trying
> > to use boost libraries for our implementation and fortunately those
> > libraries provide a way to parametrize the allocator. The other
> > possibility will be to use an allocator that allocates memory from the
> > gecode heap and *never* deallocate it (this is because gecode memory
> > manager takes care of that (am i right?). Can you recommend or comment
> > on the advantages of one approach over the other?
> >
> >
> >
> > Regards,
> >
> > Gustavo
> >
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Gecode users mailing list
> > users at gecode.org
> > https://www.gecode.org/mailman/listinfo/gecode-users
>
>
> _______________________________________________
> Gecode users mailing list
> users at gecode.org
> https://www.gecode.org/mailman/listinfo/gecode-users
>



-- 
Gustavo Gutierrez
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ps.uni-sb.de/pipermail/users/attachments/20081030/f1480ea4/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gecode_to_stl_allocator.hh
Type: application/octet-stream
Size: 2179 bytes
Desc: not available
URL: <http://www.ps.uni-sb.de/pipermail/users/attachments/20081030/f1480ea4/attachment.obj>