On Thu, Oct 30, 2008 at 12:32 PM, Filip Konvička <[EMAIL PROTECTED]>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:* [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] *On > > Behalf Of *Gustavo Gutierrez > > *Sent:* Wednesday, October 29, 2008 9:19 AM > > *To:* Christian Schulte > > *Cc:* [EMAIL PROTECTED] > > *Subject:* Re: [gecode-users] Reporting memory usage > > > > > > > > > > > > On Tue, Oct 28, 2008 at 6:19 PM, Christian Schulte > > <[EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]>> 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 > > [EMAIL PROTECTED] > > https://www.gecode.org/mailman/listinfo/gecode-users > > > _______________________________________________ > Gecode users mailing list > [EMAIL PROTECTED] > https://www.gecode.org/mailman/listinfo/gecode-users > -- Gustavo Gutierrez
gecode_to_stl_allocator.hh
Description: Binary data
_______________________________________________ Gecode users mailing list [EMAIL PROTECTED] https://www.gecode.org/mailman/listinfo/gecode-users