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