On 09/04/2011, at 10:55 AM, Ruben Zilibowitz wrote:

> 
> On 09/04/2011, at 7:11 AM, Guido Tack wrote:
> 
>> Ruben Zilibowitz wrote:
>> 
>>> This is a brilliant idea! Definitely helps to reduce file size.
>> 
>> What I was wondering is whether you can use our Makefiles to build Gecode 
>> for iOS, or do you have to turn the whole of Gecode into an XCode project?
> 
> I believe I first did:
> ./configure --enable-static --disable-shared --disable-gist --disable-qt
> in order to generate the config.hpp file

edit: I also ran make

> 
> Then it was just a matter of adding the gecode folder with all the source 
> code to Xcode. Then I removed some files I didn't need and were causing 
> errors. And that was it.
> 
>>> On another matter, I don't seem to be receiving my own emails to the list. 
>>> Even though Receive your own posts to the list is set to yes. Are my posts 
>>> getting to the list at all?
>> 
>> They are.  You can always check the archives at
>> http://news.gmane.org/gmane.comp.lib.gecode.user
> 
> Ok.
> 
> Ruben
> 
>> Guido
>> 
>>> 
>>> Ruben
>>> 
>>> On 08/04/2011, at 9:47 PM, Christian Schulte wrote:
>>> 
>>>> There might be an additional way to make the binaries smaller. After 
>>>> running configure, you can edit the file
>>>>                 gecode/support/config.hpp
>>>> and change the line
>>>>  
>>>> /* How to tell the compiler to really, really inline */
>>>> #define forceinline inline __attribute__ ((__always_inline__))
>>>>  
>>>> to
>>>>  
>>>> /* How to tell the compiler to really, really inline */
>>>> #define forceinline inline
>>>>  
>>>> This reduces the amount of inlining (hopefully). I do not know which 
>>>> difference it makes for gcc though. For MSVC on Windows it saves 35% for 
>>>> the integer module and 50% for the set module.
>>>>  
>>>> Christian
>>>>  
>>>> --
>>>> Christian Schulte, www.ict.kth.se/~cschulte/
>>>>  
>>>> From: [email protected] [mailto:[email protected]] On Behalf 
>>>> Of Guido Tack
>>>> Sent: Friday, April 08, 2011 12:45 PM
>>>> To: Mikael Zayenz Lagerkvist
>>>> Cc: [email protected] list
>>>> Subject: Re: [gecode-users] embedded gecode
>>>>  
>>>> Mikael Zayenz Lagerkvist wrote:
>>>> 
>>>> 
>>>> On Fri, Apr 8, 2011 at 6:54 AM, Ruben Zilibowitz 
>>>> <[email protected]> wrote:
>>>> 
>>>> >> 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.
>>>> >
>>>> > First of all, that sounds like you're linking statically, right?  It's 
>>>> > true, the Gecode libraries are a bit on the fat side.  What you can 
>>>> > definitely do is strip the debug symbols.  Other than that, I think the 
>>>> > linker already only includes the symbols that it needs, so there's not 
>>>> > much you can do in addition.
>>>> 
>>>> Yes, statically. I'm not sure there's any other way when it comes to 
>>>> building iPhone apps. That 17 Mb is for a "fat" binary that supports two 
>>>> architectures (armv6 and armv7). So the real figure is about half that. 
>>>> Still it would be nice if it was smaller.
>>>>  
>>>> Stripping debug symbols helps a lot with size. On my machine, the size of 
>>>> the dynamic libraries goes from 52 MiB to 7.1 MiB when stripped.
>>>>  
>>>> In addition, you can try and compile Gecode with -Os as optimization flag. 
>>>> It won't be as fast, but it might make the executable smaller (I haven't 
>>>> tried it, you'll need to experiment). Also, make sure that you are only 
>>>> including the parts that you need (Gist and flatzinc might not be relevant 
>>>> for example). 
>>>>  
>>>> Gist won't be compiled anyway (no Qt on iOS), and flatzinc is usually not 
>>>> linked unless you actually use it.
>>>>  
>>>> On Darwin (Mac OS, iOS), the option for minimizing size is -Oz (-Os also 
>>>> exists but is slightly less radical).  Here's a table of executable sizes 
>>>> (x86_64 on Mac OS):
>>>>  
>>>>                                                             -O3            
>>>>       -O3 stripped                -Oz                  -Oz stripped    -Oz 
>>>> clang            -Oz clang stripped
>>>> examples/queens:        8,2M    4,9M                            7,6M    
>>>> 3,8M                7,3M                3,3M
>>>> tools/flatzinc/fz:                      15M     9,1M                       
>>>>      13M     7,1M                13M                 6,2M
>>>> 
>>>> 
>>>> If you really want to make the executables as small as possible, then you 
>>>> could start to remove parts that you are not using. You might want to 
>>>> investigate if there is a way to make your compilation tool-chain do 
>>>> automatic dead-code removal.
>>>>  
>>>> I thought the linker did that automatically, but apparently, it doesn't.  
>>>> You can tell the linker explicitly to remove dead code.  On Darwin, that's 
>>>> done using the -dead_strip flag (and that's possibly enabled by default in 
>>>> XCode, I'm not sure).  
>>>> With -dead_strip, examples/queens goes down to 4,4M with -Oz, or 2,3M 
>>>> stripped.  So, comparing -O3 nonstripped to -Oz -Wl,-dead_strip stripped, 
>>>> we can reduce the binary by 70%.
>>>>  
>>>> Still, quite a lot of symbols end up in the executable that I can't 
>>>> explain, e.g. most of the set library seems to be included in the queens 
>>>> executable.  So indeed, if your constraint model does not use set 
>>>> constraints, consider compiling Gecode with --disable-set-vars.  Here are 
>>>> the numbers for queens without set variables:
>>>>                                                             -Oz            
>>>>       -Oz stripped    -Oz -dead_strip           -Oz -dead_strip stripped
>>>> examples/queens:        6,2M    2,9M                3,2M                   
>>>>          1,5M
>>>>  
>>>> We could probably reduce the size even further by carefully looking at the 
>>>> symbols and removing unused stuff.  But anyway, this already saves 80% 
>>>> code size.
>>>>  
>>>> Another thing I tried (just for fun) was to compile using clang with -O4, 
>>>> enabling link-time optimization.  The smallest size I could get for queens 
>>>> (but including set variables) was 2,2M, which is not too bad either, 
>>>> considering that this does full optimization.
>>>>  
>>>> Cheers,
>>>>             Guido
>>>>  
>>>> -- 
>>>> Guido Tack, http://people.cs.kuleuven.be/~guido.tack/
>>>>  
>>>> _______________________________________________
>>>> 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
>> 
>> -- 
>> Guido Tack, http://people.cs.kuleuven.be/~guido.tack/
>> 
>> 
>> 
>> 
> 

_______________________________________________
Gecode users mailing list
[email protected]
https://www.gecode.org/mailman/listinfo/gecode-users

Reply via email to