[gecode-users] embedded gecode

Christian Schulte cschulte at kth.se
Fri Apr 8 13:47:12 CEST 2011


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/

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gecode.org/pipermail/users/attachments/20110408/5ac125fa/attachment-0001.htm>


More information about the users mailing list