473,689 Members | 2,838 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

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 6690

"Chris Mantoulidis" <cm****@yahoo.c om> wrote in message news:a8******** *************** ***@posting.goo gle.com...
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.merke rk(at)dse.nl
Jul 19 '05 #3
In article <a8************ **************@ posting.google. com>,
cm****@yahoo.co m 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.c om> wrote in message news:a8******** *************** ***@posting.goo gle.com...
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_cygw in.a;
its size = 2406816.

--
=============== =============== =======
Alex Vinokur
mailto:al****@c onnect.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.c om> wrote in message news:bo******** *@news.rd.franc etelecom.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****@c onnect.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.c om> wrote in message news:bo******** *@news.rd.franc etelecom.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.a delphia.net...
In article <bo************ *@ID-79865.news.uni-berlin.de>,
al****@bigfoot. com says...
"Marc Ferry" <mf********@rd. francetelecom.c om> wrote in message news:bo******** *@news.rd.franc etelecom.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****@c onnect.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] = 124406183631190 3
Fib [47] = 124406297121507 3
Fib [48] = 248812480752697 6
Fib [49] = 373218777874204 9
Fib [50] = 622031258626902 5
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

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

Similar topics

2
2331
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 Python from source, because it also requires a change to Grammar. 1. Edit Python-2.3/Grammar/Grammar and add an alternative to the "listmaker" production: -listmaker: test ( list_for | (',' test)* )
6
1478
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) def f(y):
3
2003
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 using Microsoft Visual C++ 2003. Here is what I get sizeof(TestStruct1)==0x108 sizeof(TestStruct2)==0x104 Is this normal C++ compiler behavior, or a bug in the compiler?
233
8345
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 lack of C 99 compliant compilers. Is this just a lame excuse for back-sliding?
16
2674
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 x86 box under your desk, please check what this program outputs. //-- program starts -- #include <stdio.h> #define showsize(x,y) printf("Size of %s %d \n",x,sizeof(y));
9
2434
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, strings for logging, and structures for data points. I want to use one function to read data from this block and one function to write data, for example: sram_read(OBJECT_IDENTIFIER) would return a pointer to the appriate object and
9
2692
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 and run it once you've made sure there is no harmful code. Currently we have several stored procedures which final result is a select with several joins that returns many
0
1507
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 using Oracle 10.2 on Unix. 1. First I created a nested table type in the database: CREATE TYPE varchar2_list AS TABLE OF VARCHAR2(15); 2. Then I created the input file for "ott", called "acttest.typ":
14
1822
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 generated by two different compilers are different is it possible to communicate at all. Is there any alternative for the same. What about libraries compiled with two different compilers. If someone can give some feedback on the same it will be of...
0
8598
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look ! Part I. Meaning of...
0
9077
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. Here is my compilation command: g++-12 -std=c++20 -Wnarrowing bit_field.cpp Here is the code in...
1
8786
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
0
7623
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own.... Now, this would greatly impact the work of software developers. The idea...
1
6457
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 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 a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms. Adolph will...
0
5811
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert into image. Globals.ThisAddIn.Application.ActiveDocument.Select();...
1
2965
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
2
2225
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.
3
1952
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...

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.