Different C++ compiler exec. sizes

Discussion in 'C++' started by Chris Mantoulidis, Nov 4, 2003.

  1. Out of curiosity, I wanted to test executable file sizes of the same
    program from different compilers...

    The 2 compilers I tested (both old, on purpose) were Borland C++ 3.1
    and DJGPP 2.03...

    The program was nothing but a simple hello world program using the
    iostream header file...

    I compiled and linked (both copies) with those 2 different
    compilers... The Borland c++ 3.1 compiler gave me an executable with
    size like 20-30KB (i don't remember) and DJGPP gave me an executable
    with size like 220-240KB...

    I can assume 2 things here... Either DJGPP produces WAY more
    compicated executables (kind of odd though) or DJGPP's header files
    contain kinda different info....

    Anyone seen anything like that? Anyone know why?
    Chris Mantoulidis, Nov 4, 2003
    #1
    1. Advertising

  2. Chris Mantoulidis

    Ron Natalie Guest

    "Chris Mantoulidis" <> wrote in message news:...

    > I can assume 2 things here... Either DJGPP produces WAY more
    > compicated executables (kind of odd though) or DJGPP's header files
    > contain kinda different info....


    Nope, most likely the different has nothing to do with the executable code
    nor the header files. I suspect in one case you have the library code included
    in the executable and in another they are in seperate runtime file (DLL or shared library).

    On little trivial programs the size of the runtime libraries dwarf the user code.
    Ron Natalie, Nov 4, 2003
    #2
    1. Advertising

  3. > Out of curiosity, I wanted to test executable file sizes of the same
    > program from different compilers...
    >
    > The 2 compilers I tested (both old, on purpose) were Borland C++ 3.1
    > and DJGPP 2.03...
    >
    > The program was nothing but a simple hello world program using the
    > iostream header file...
    >
    > I compiled and linked (both copies) with those 2 different
    > compilers... The Borland c++ 3.1 compiler gave me an executable with
    > size like 20-30KB (i don't remember) and DJGPP gave me an executable
    > with size like 220-240KB...
    >
    > I can assume 2 things here... Either DJGPP produces WAY more
    > compicated executables (kind of odd though) or DJGPP's header files
    > contain kinda different info....
    >
    > Anyone seen anything like that? Anyone know why?


    One thing that may explain the difference you are seeing is that one
    compiler stores the debug information in the executable itself while the
    other stores the debug information in a separate file. You are more
    likely to get more sensible numbers if you do an optimized build without
    debug information with both compilers.

    For small and even medium sized programs the runtime library often
    accounts for a large part of the executable size. With small programs
    your own code accounts for only a very small fraction of the total
    executable size (I would be surpriced if it would be more than 200
    bytes). Because you only tested with a small program, it is important to
    realize that the executable sizes you find are not necessarilly
    representative for larger programs. If you do the same test with a large
    (non-trivial) program, it is likely that the difference between the two
    compilers has become smaller. Whether the runtime library is linked
    statically or dynamically can make a big difference. Using a different
    runtime library can dramatically reduce the executable size of small
    programs. I have been able to produce executables with MSVC as small as
    2.5 KB using the libtinyc runtime library (compared to 28KB with the
    standard runtime library).

    The quality of the linker and the linker settings may have some impact
    on the executable size as well. Finally optimization settings of the
    compiler may make a (small) difference too.

    If you really are interested in making your executables as small as
    possible, you may find this page an interesting read:
    http://freespace.virgin.net/james.brown7/tutorials/minexe.htm

    --
    Peter van Merkerk
    peter.van.merkerk(at)dse.nl
    Peter van Merkerk, Nov 4, 2003
    #3
  4. Chris Mantoulidis

    Jerry Coffin Guest

    In article <>,
    says...
    > Out of curiosity, I wanted to test executable file sizes of the same
    > program from different compilers...
    >
    > The 2 compilers I tested (both old, on purpose) were Borland C++ 3.1
    > and DJGPP 2.03...


    BC++ 3.1 produces native DOS executables. DJGPP produces executables
    for a DOS extender, which is basically a small, simple OS that gets
    linked into your executable. Most of what you're seeing in the DJGPP
    executable is the DOS extender code.

    The DOS extender primarily allows your program to access large amounts
    of memory directly, compared to the BC++ 3.1 program, which is limited
    to 640K, even if your machine has hundreds of megabytes of RAM.

    --
    Later,
    Jerry.

    The universe is a figment of its own imagination.
    Jerry Coffin, Nov 4, 2003
    #4
  5. Chris Mantoulidis

    Alex Vinokur Guest

    "Chris Mantoulidis" <> wrote in message news:...
    > Out of curiosity, I wanted to test executable file sizes of the same
    > program from different compilers...
    >
    > The 2 compilers I tested (both old, on purpose) were Borland C++ 3.1
    > and DJGPP 2.03...
    >
    > The program was nothing but a simple hello world program using the
    > iostream header file...
    >
    > I compiled and linked (both copies) with those 2 different
    > compilers... The Borland c++ 3.1 compiler gave me an executable with
    > size like 20-30KB (i don't remember) and DJGPP gave me an executable
    > with size like 220-240KB...
    >
    > I can assume 2 things here... Either DJGPP produces WAY more
    > compicated executables (kind of odd though) or DJGPP's header files
    > contain kinda different info....
    >
    > Anyone seen anything like that? Anyone know why?


    Here are sizes of actual executables which were used
    to measure comparative performance
    of different compilers
    * http://article.gmane.org/gmane.comp.lang.c .perfometer/19

    Compiler Size DLLs
    -------- ---- -----
    gcc, Cygwin 478971 cygwin1.dll, KERNEL32.dll, NTDLL.DLL
    gcc, Cygwin, STLport 712195 cygwin1.dll, KERNEL32.dll, NTDLL.DLL
    gcc, Cygwin, Mingw32 interface 503820 msvcrt.dll, KERNEL32.dll, NTDLL.DLL
    gpp, DJGPP 648443 DJGPP doesn't support dynamic linking
    dmc, DigitalMars, STLport 381468 KERNEL32.dll, NTDLL.DLL, USER32.DLL, GDI32.DLL

    We can see that dynamic linking usually reduces size of the executable.

    Note about <gcc, Cygwin, STLport>.
    This executable contains supplementary library libstlport_cygwin.a;
    its size = 2406816.

    --
    =====================================
    Alex Vinokur
    mailto:
    http://mathforum.org/library/view/10978.html
    news://news.gmane.org/gmane.comp.lang.c .perfometer
    =====================================
    Alex Vinokur, Nov 5, 2003
    #5
  6. Chris Mantoulidis

    Marc Ferry Guest

    Did you strip the executables before comparison ?
    FYI: strip = remove debug info, symbol table, etc

    Also, be sure to have the same level of compiler optimization in your
    Makefile.

    Marc

    Chris Mantoulidis wrote:
    > Out of curiosity, I wanted to test executable file sizes of the same
    > program from different compilers...
    >
    > The 2 compilers I tested (both old, on purpose) were Borland C++ 3.1
    > and DJGPP 2.03...
    >
    > The program was nothing but a simple hello world program using the
    > iostream header file...
    >
    > I compiled and linked (both copies) with those 2 different
    > compilers... The Borland c++ 3.1 compiler gave me an executable with
    > size like 20-30KB (i don't remember) and DJGPP gave me an executable
    > with size like 220-240KB...
    >
    > I can assume 2 things here... Either DJGPP produces WAY more
    > compicated executables (kind of odd though) or DJGPP's header files
    > contain kinda different info....
    >
    > Anyone seen anything like that? Anyone know why?
    Marc Ferry, Nov 5, 2003
    #6
  7. Chris Mantoulidis

    Alex Vinokur Guest

    "Marc Ferry" <> wrote in message news:boagtt$...
    > Did you strip the executables before comparison ?
    > FYI: strip = remove debug info, symbol table, etc
    >

    [snip]

    Very efficient.

    Here are executable sizes before and after stripping.
    Executables are from my first posting in this thread.

    Compiler Before After
    strip strip
    -------- ------ -----
    g++, Cygwin 478971 237568
    g++, Cygwin, STLport 712195 335360
    g++, Cygwin, Mingw32 interface 503820 251904
    gpp, DJGPP 648443 330240


    --
    =====================================
    Alex Vinokur
    mailto:
    http://mathforum.org/library/view/10978.html
    news://news.gmane.org/gmane.comp.lang.c .perfometer
    =====================================
    Alex Vinokur, Nov 5, 2003
    #7
  8. Chris Mantoulidis

    Jerry Coffin Guest

    In article <boao7s$1afast$-berlin.de>,
    says...
    > "Marc Ferry" <> wrote in message news:boagtt$...
    > > Did you strip the executables before comparison ?
    > > FYI: strip = remove debug info, symbol table, etc
    > >

    > [snip]
    >
    > Very efficient.
    >
    > Here are executable sizes before and after stripping.
    > Executables are from my first posting in this thread.
    >
    > Compiler Before After
    > strip strip
    > -------- ------ -----
    > g++, Cygwin 478971 237568
    > g++, Cygwin, STLport 712195 335360
    > g++, Cygwin, Mingw32 interface 503820 251904
    > gpp, DJGPP 648443 330240


    Hmmm...not very impressive, really. Just for comparison, consider that
    compiling your code with VC++ 7.1 using:

    cl -Oxb2 -G6ry

    produces an executable of 106,496 bytes.

    Compiling with Borland 5.5 produces an executable of 179,712, but
    produces an executable that doesn't work correctly -- I haven't tried to
    figure out whether it's a problem with the compiler or with your code
    though.

    --
    Later,
    Jerry.

    The universe is a figment of its own imagination.
    Jerry Coffin, Nov 9, 2003
    #8
  9. Chris Mantoulidis

    Alex Vinokur Guest

    "Jerry Coffin" <> wrote in message news:...
    > In article <boao7s$1afast$-berlin.de>,
    > says...
    > > "Marc Ferry" <> wrote in message news:boagtt$...
    > > > Did you strip the executables before comparison ?
    > > > FYI: strip = remove debug info, symbol table, etc
    > > >

    > > [snip]
    > >
    > > Very efficient.
    > >
    > > Here are executable sizes before and after stripping.
    > > Executables are from my first posting in this thread.
    > >
    > > Compiler Before After
    > > strip strip
    > > -------- ------ -----
    > > g++, Cygwin 478971 237568
    > > g++, Cygwin, STLport 712195 335360
    > > g++, Cygwin, Mingw32 interface 503820 251904
    > > gpp, DJGPP 648443 330240

    >
    > Hmmm...not very impressive, really. Just for comparison, consider that
    > compiling your code with VC++ 7.1 using:
    >
    > cl -Oxb2 -G6ry
    >
    > produces an executable of 106,496 bytes.


    Indeed, considerable distinction.

    What DLLs does this executable depend on?
    What are their sizes?

    >
    > Compiling with Borland 5.5 produces an executable of 179,712, but
    > produces an executable that doesn't work correctly --



    We are talking about the algorithm at
    http://groups.google.com/groups?selm=bo4nls$17vfq6$-berlin.de

    I have compiled the algorithm with
    * GNU gcc (Cygwin, Cygwin with STLport, Mingw, DJGPP) and
    * Digital Mars C++ compiler
    and computed Fibonacci [50,000].
    All results are identical.

    What Fibonacci number does Borland 5.5 produce incorrectly?

    > I haven't tried to
    > figure out whether it's a problem with the compiler or with your code
    > though.


    [snip]

    --
    =====================================
    Alex Vinokur
    mailto:
    http://mathforum.org/library/view/10978.html
    news://news.gmane.org/gmane.comp.lang.c .perfometer
    =====================================
    Alex Vinokur, Nov 9, 2003
    #9
  10. Chris Mantoulidis

    Jerry Coffin Guest

    In article <boluuu$1dpmhv$-berlin.de>,
    says...

    [ ... ]

    > > Hmmm...not very impressive, really. Just for comparison, consider that
    > > compiling your code with VC++ 7.1 using:
    > >
    > > cl -Oxb2 -G6ry
    > >
    > > produces an executable of 106,496 bytes.

    >
    > Indeed, considerable distinction.
    >
    > What DLLs does this executable depend on?


    None other than kernel32.dll, which is part of the OS, so presumably
    you're not trying to count it. If you're actually interested primarily
    in small size, using:

    cl /O1 /G6ry fibo.cpp

    reduces the executable to 98,304 bytes, with the same (lack of)
    dependencies. If you're willing to depend on some DLLs to get a smaller
    executable, you can use:

    cl /Oxb2 /G6ry /MD fibo.cpp /link /align:16

    and get an executable of 15,488 bytes that depends on msvcp71.dll and
    msvcr71.dll (and, of course, kernel32.dll, ntdll.dll, etc.). If you
    want to be able to use the executable under Windows 95/98/SE/Me, you
    have to remove the "align:16", which inflates the executable to 16KB.

    > What are their sizes?


    MSVCR71.dll is 348,160 bytes
    MSVCP71.dll is 499,712 bytes

    > What Fibonacci number does Borland 5.5 produce incorrectly?


    It starts to go wrong at fib(46). Here's a cut-n-paste of output:

    Fib [44] = 701408733
    Fib [45] = 1134903170
    Fib [46] = 1244061836311903
    Fib [47] = 1244062971215073
    Fib [48] = 2488124807526976
    Fib [49] = 3732187778742049
    Fib [50] = 6220312586269025
    CPU time used : 0 sec

    Anytime it gains more than one digit in an iteration, something's
    clearly wrong...

    --
    Later,
    Jerry.

    The universe is a figment of its own imagination.
    Jerry Coffin, Nov 9, 2003
    #10
  11. Chris Mantoulidis

    Alex Vinokur Guest

    Computing very long Fibonacci numbers (was: Different C++ compiler exec. sizes)

    "Jerry Coffin" <> wrote in message news:...
    [snip]
    > It starts to go wrong at fib(46). Here's a cut-n-paste of output:
    >
    > Fib [44] = 701408733
    > Fib [45] = 1134903170
    > Fib [46] = 1244061836311903
    > Fib [47] = 1244062971215073
    > Fib [48] = 2488124807526976
    > Fib [49] = 3732187778742049
    > Fib [50] = 6220312586269025
    > CPU time used : 0 sec
    >
    > Anytime it gains more than one digit in an iteration, something's
    > clearly wrong...
    >

    [snip]

    Weird output.

    http://groups.google.com/groups?selm=bo4nls$17vfq6$-berlin.de

    * GNU gcc (Cygwin, Cygwin with STLport, Mingw, DJGPP : Optimization 0-3) and
    * Digital Mars C++ compiler (No optimization, Space, Speed) .

    All those executables generate the same (valid) output

    ---------
    $ fib.exe all 50
    [---omitted---]
    Fib [40] = 102334155
    Fib [41] = 165580141
    Fib [42] = 267914296
    Fib [43] = 433494437
    Fib [44] = 701408733
    Fib [45] = 1134903170
    Fib [46] = 1836311903
    Fib [47] = 2971215073
    Fib [48] = 4807526976
    Fib [49] = 7778742049
    Fib [50] = 12586269025
    CPU time used : 0 sec
    ---------


    Unfortunaly I don't have Borland compiler. So, I am unable to analyze what is reason for that.


    Regards,

    --
    =====================================
    Alex Vinokur
    mailto:
    http://mathforum.org/library/view/10978.html
    news://news.gmane.org/gmane.comp.lang.c .perfometer
    =====================================
    Alex Vinokur, Nov 10, 2003
    #11
  12. Chris Mantoulidis

    Jerry Coffin Guest

    Re: Computing very long Fibonacci numbers (was: Different C++ compiler exec. sizes)

    In article <bon5rg$1g7m0h$-berlin.de>,
    says...

    [ ... ]

    > Weird output.


    Yes, to put it mildly.

    > http://groups.google.com/groups?selm=bo4nls$17vfq6$-berlin.de
    >
    > * GNU gcc (Cygwin, Cygwin with STLport, Mingw, DJGPP : Optimization 0-3) and
    > * Digital Mars C++ compiler (No optimization, Space, Speed) .
    >
    > All those executables generate the same (valid) output


    In case you care, so do VC++ and Comeau (Ver. 7.1 and 4.3 respectively).

    --
    Later,
    Jerry.

    The universe is a figment of its own imagination.
    Jerry Coffin, Nov 10, 2003
    #12
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Hal Vaughan
    Replies:
    11
    Views:
    1,085
    Gordon Beaton
    May 22, 2006
  2. tedsuzman
    Replies:
    2
    Views:
    7,057
    Michel Claveau, résurectionné d'outre-bombe inform
    Jul 21, 2004
  3. Ted
    Replies:
    1
    Views:
    448
    Duncan Booth
    Jul 22, 2004
  4. Guillermo Riojas
    Replies:
    0
    Views:
    155
    Guillermo Riojas
    Nov 26, 2010
  5. Random Task
    Replies:
    12
    Views:
    631
    Joe Smith
    Dec 4, 2005
Loading...

Share This Page