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 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
