[gecode-users] Reporting memory usage

Thu Oct 30 15:57:15 CET 2008

That looks indeed easy enough. However I would like to have if you guys would integrate it into the gecode/support part as it is really useful.

Then, in 3.0.0 there will be three memory areas for allocation:

 - The global heap (there a normal stl allocator works anyway).

 - Space allocated memory: so one would just have to adapt to the new Gecode 3.0.0 memory management.

- Region allocated memory for temporary memory usage. That's new in 3.0.0.

Regions work as follows: if one has a space one can get a region for that space. One can allocate memory (very very efficiently) from a region. However, the memory will only be freed when the region is destructed. (Actually, what happens there is that all spaces for one thread share a small memory area and that a Region provides access to this shared memory area. If a request cannot be fulfilled from this area, memory will be allocated transparently from the heap). Very simple as you don't have to deallocate to a region, very efficient, and much cleaner than alloca.

So, what I would like to ask you guys: would you be willing to

 - Write stl allocators for both regions and spaces.

 - Test with your own programs that these allocators work.

 - Send me a patch for Gecode 3.0.0 so that I can integrate your stuff into the trunk into gecode/support (as a separate file).

 - Test the stuff again after I integrated.

 - Negotiate among you who does what.

Thanks in advance (hoping that you will jump at it).

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: Thursday, October 30, 2008 2:39 PM
To: Filip Konvička
Cc: users at gecode.org
Subject: Re: [gecode-users] Reporting memory usage

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/c8f0d2d9/attachment.htm>