[gecode-users] embedded gecode

Ruben Zilibowitz ruben.zilibowitz at gmail.com
Tue Apr 5 02:17:55 CEST 2011


Thanks for the tip about setting the commit and adaptive distance. That helps memory wise. In order to compile gecode for iphone one needs to set "Compile for Thumb" to "No", in case anyone else wants to try. There are two more issues I'm having.

1) Is gecode thread safe, in general? In particular can I safely initialise a space and run a search on it all inside of a thread? This is important since one doesn't want to block execution in an iphone app.

2) My executables, even after dead code elimination and other optimisations are very large. It's around 17 Mb. I'm not sure there's an easy fix for this, but any ideas would be welcome, for how to reduce file size of the executable. It seems that there are many features I'm not going to need, so perhaps I can try to strip down the library.

Ruben

On 04/04/2011, at 8:23 PM, Guido Tack wrote:

> Ruben Zilibowitz wrote:
> 
>> Hi. I'm considering trying to use gecode on the iphone platform, or other mobile platforms. I'm aware that support for double precision floating point is limited on the iphone platform. The other main issue is the limited RAM. I've managed to compile gecode and test it on the iphone, however I'm concerned about the memory usage.
>> 
>> I'm wondering if there've been any attempts to do this before? Are there any tips/suggestions?
> 
> First of all, thanks for trying Gecode on a platform that we haven't got a lot of experience with.  Any comments are highly welcome.
> 
> Concerning doubles, Gecode uses them mainly as a portable integer type with more than 32 bits in order to perform overflow-correct computations. As long as it works (i.e., either with hardware support or software emulation), it shouldn't be a problem, although perhaps there would be more efficient alternative solutions.
> 
> Gecode has been designed for memory efficiency from the start, most data structures are quite compact.  The amount of memory used during search can be controlled using the recomputation parameters (commit distance and adaption distance).  E.g., a commit and adaptive distance of 100000 will effectively result in constant memory use, paid for by higher runtime (see Section 9.2 in "Modeling and Programming with Gecode").  But even with much lower parameters, many problems can be solved in just a few MB of RAM.
> 
> Cheers,
> 	Guido
> 
> -- 
> Guido Tack, http://people.cs.kuleuven.be/~guido.tack/
> 
> 
> 
> 
> 
> _______________________________________________
> Gecode users mailing list
> users at gecode.org
> https://www.gecode.org/mailman/listinfo/gecode-users




More information about the users mailing list