[gecode-users] embedded gecode
Guido Tack
tack at gecode.org
Fri Apr 8 23:11:32 CEST 2011
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: users-bounces at gecode.org [mailto:users-bounces at gecode.org] On Behalf Of Guido Tack
>> Sent: Friday, April 08, 2011 12:45 PM
>> To: Mikael Zayenz Lagerkvist
>> Cc: users at gecode.org list
>> Subject: Re: [gecode-users] embedded gecode
>>
>> Mikael Zayenz Lagerkvist wrote:
>>
>>
>> On Fri, Apr 8, 2011 at 6:54 AM, Ruben Zilibowitz <ruben.zilibowitz at gmail.com> 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
>> users at gecode.org
>> https://www.gecode.org/mailman/listinfo/gecode-users
>
> _______________________________________________
> Gecode users mailing list
> users at gecode.org
> https://www.gecode.org/mailman/listinfo/gecode-users
--
Guido Tack, http://people.cs.kuleuven.be/~guido.tack/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gecode.org/pipermail/users/attachments/20110408/4c5bb897/attachment-0001.htm>
More information about the users
mailing list