473,325 Members | 2,860 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,325 software developers and data experts.

Different C++ compiler exec. sizes

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?
Jul 19 '05 #1
11 6646

"Chris Mantoulidis" <cm****@yahoo.com> wrote in message news:a8**************************@posting.google.c om...
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.
Jul 19 '05 #2
> 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.br...als/minexe.htm

--
Peter van Merkerk
peter.van.merkerk(at)dse.nl
Jul 19 '05 #3
In article <a8**************************@posting.google.com >,
cm****@yahoo.com 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.
Jul 19 '05 #4

"Chris Mantoulidis" <cm****@yahoo.com> wrote in message news:a8**************************@posting.google.c om...
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.....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:al****@connect.to
http://mathforum.org/library/view/10978.html
news://news.gmane.org/gmane.comp.lang.c++.perfometer
=====================================


Jul 19 '05 #5
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?


Jul 19 '05 #6
"Marc Ferry" <mf********@rd.francetelecom.com> wrote in message news:bo*********@news.rd.francetelecom.fr...
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:al****@connect.to
http://mathforum.org/library/view/10978.html
news://news.gmane.org/gmane.comp.lang.c++.perfometer
=====================================

Jul 19 '05 #7
In article <bo*************@ID-79865.news.uni-berlin.de>,
al****@bigfoot.com says...
"Marc Ferry" <mf********@rd.francetelecom.com> wrote in message news:bo*********@news.rd.francetelecom.fr...
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.
Jul 19 '05 #8

"Jerry Coffin" <jc*****@taeus.com> wrote in message news:MP************************@news.clspco.adelph ia.net...
In article <bo*************@ID-79865.news.uni-berlin.de>,
al****@bigfoot.com says...
"Marc Ferry" <mf********@rd.francetelecom.com> wrote in message news:bo*********@news.rd.francetelecom.fr...
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....uni-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:al****@connect.to
http://mathforum.org/library/view/10978.html
news://news.gmane.org/gmane.comp.lang.c++.perfometer
=====================================


Jul 19 '05 #9
In article <bo*************@ID-79865.news.uni-berlin.de>,
al****@bigfoot.com 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.
Jul 19 '05 #10

"Jerry Coffin" <jc*****@taeus.com> wrote in message news:MP************************@news.clspco.adelph ia.net...
[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....uni-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:al****@connect.to
http://mathforum.org/library/view/10978.html
news://news.gmane.org/gmane.comp.lang.c++.perfometer
=====================================


Jul 19 '05 #11
In article <bo*************@ID-79865.news.uni-berlin.de>,
al****@bigfoot.com says...

[ ... ]
Weird output.
Yes, to put it mildly.
http://groups.google.com/groups?selm....uni-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.
Jul 19 '05 #12

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

2
by: Jeff Epler | last post by:
Hello. Recently, Generator Comprehensions were mentioned again on python-list. I have written an implementation for the compiler module. To try it out, however, you must be able to rebuild...
6
by: r.e.s. | last post by:
Should one expect the following execution times to be so different? ... Module_A takes about 4 seconds to run: x = (stuff_1) (stuff_2) Module_B takes about 80 seconds to run: x = (stuff_1)...
3
by: JR | last post by:
Take a look at TestStruct1 and TestStruct2. Clearly, the D2 part of the union is MUCH larger than the D1 portion. I would expect sizeof(TestStruct1)==sizeof(TestStruct2) but that is not the case...
233
by: E. Robert Tisdale | last post by:
I have access to a wide variety of different platforms here at JPL and they all have pretty good C 99 compilers. Some people claim that they have not moved to the new standard because of the...
16
by: Martin Roos | last post by:
hy ppl, i'm trying to create some multiplatformed software here and i'm very curious about the sizes of common variables on different machines. if you are running something different than a 32-bit...
9
by: CptDondo | last post by:
I am working on an embedded platform which has a block of battery-backed RAM. I need to store various types of data in this block of memory - for example, bitmapped data for control registers,...
9
by: serge | last post by:
/* Subject: How to build a procedure that returns different numbers of columns as a result based on a parameter. You can copy/paste this whole post in SQL Query Analyzer or Management Studio...
0
by: rgettman | last post by:
Hello, I'm attempting to use Pro*C to create a nested table and send that data to a stored procedure as a parameter. However, I'm getting a Pro*C compiler error that I'll describe below. I'm...
14
by: shyam.lingegowda | last post by:
Hi all, If I have two c++ programs and I compile that using two different compilers on Unix. Is it possible for these two exe's to communicate with one another. Since the way the exe's are...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.