Board index » cppbuilder » EXE image size

EXE image size


2006-07-15 12:33:20 AM
cppbuilder60
Why BCC32/ILINK32 makes an EXE file almost twice the size of file created by
MS CL/LINK?
I made a test with a simple "hellowin.cpp" code. CL (hello.exe = 27k), BCC32
(hello.exe = 48k).
Command lines:
(BCC32 -O2 -k- -d -v- -5 hellowin.cpp)
(CL -O2 -G5 -ML hellowin.cpp kernel32.lib user32.lib gdi32.lib)
Using:
(Borland C++ Builder 6)
BCC32 5.6 for Win32
ILINK32 Turbo Incremental Link 5.60
(Microsoft Visual Studio .NET 2003)
CL 32bit C/C++ Optimizeing Compiler 13.10.3077 for 80x86
LINK Incremental Linker 7.10.3077
And I made the same test with Borland Development Studio 2006...
[]s
Fred
 
 

Re:EXE image size

Quote
Why BCC32/ILINK32 makes an EXE file almost twice the size of file created
by MS CL/LINK?
My guess is that it is because the two executables were built with different
options.
Here is a screen capture of a hello world program.
=======================
C:\Documents and Settings\Edward\My Documents\lookat\q066
Quote
type hello.cpp
#include <iostream>
using namespace std;
int main()
{
cout << "Hello World!" << endl;
return 0;
}
C:\Documents and Settings\Edward\My Documents\lookat\q066
Quote
bcc32 -WCR hello
Borland C++ 5.6.4 for Win32 Copyright (c) 1993, 2002 Borland
hello.cpp:
Turbo Incremental Link 5.66 Copyright (c) 1997-2002 Borland
C:\Documents and Settings\Edward\My Documents\lookat\q066
Quote
hello
Hello World!
C:\Documents and Settings\Edward\My Documents\lookat\q066
Quote
dir hello.exe
Volume in drive C has no label.
Volume Serial Number is FC8D-A209
Directory of C:\Documents and Settings\Edward\My Documents\lookat\q066
07/14/2006 03:24 PM 8,704 hello.exe
1 File(s) 8,704 bytes
0 Dir(s) 29,895,061,504 bytes free
C:\Documents and Settings\Edward\My Documents\lookat\q066
Quote

=======================
If you are building from the command line then you might find these web
pages helpful:
www.mulroy.org/howto.htm
. Ed
Quote
Frederico pissarra wrote in message
news: XXXX@XXXXX.COM ...

Why BCC32/ILINK32 makes an EXE file almost twice the size of file created
by MS CL/LINK?

I made a test with a simple "hellowin.cpp" code. CL (hello.exe = 27k),
BCC32 (hello.exe = 48k).

Command lines:

(BCC32 -O2 -k- -d -v- -5 hellowin.cpp)
(CL -O2 -G5 -ML hellowin.cpp kernel32.lib user32.lib gdi32.lib)

Using:

(Borland C++ Builder 6)
BCC32 5.6 for Win32
ILINK32 Turbo Incremental Link 5.60

(Microsoft Visual Studio .NET 2003)
CL 32bit C/C++ Optimizeing Compiler 13.10.3077 for 80x86
LINK Incremental Linker 7.10.3077

And I made the same test with Borland Development Studio 2006...

[]s
Fred

 

Re:EXE image size

"Ed Mulroy" < XXXX@XXXXX.COM >wrote in message
Quote
>Why BCC32/ILINK32 makes an EXE file almost twice the size of file created
>by MS CL/LINK?

My guess is that it is because the two executables were built with
different options.

Sorry about the delay in my reply....
Ed, those are my compilers switches for both compilers:
bcc32 -O2 -a -k- -v- -d -5 hello.cpp
cl -O2 -G5s hello.cpp
As you can see the options are not that different (-O2 in both, compiles for
Pentium, -k- do not generate stack frames if possible, the same as -Gs in
CL, and I had to make sure that BCC32 do not generate debug info using -v-).
Adding -WC option in bcc32 do not help!
The simple code I use for this test is something like this:
-----------%<--------------%<--------------
#include <stdio.h>
int main()
{
printf("hello\n");
return 0;
}
-----------%<--------------%<--------------
No cout, no streams, no objects... just nice and clear C code...
BCC32/ILINK (BCB2006) generates an EXE image twice the size of that
generated by CL/LINK (VS2003)
[]s
Fred
 

{smallsort}

Re:EXE image size

What you show confirms my suspicions. You used no command line option to
specify dynamic linking so the Borland compiler created a static linked
executable.
I wonder about some of the other bcc32 options used.
The -k- suppresses the use of standard stack frames. It is an option for
specialized use. At best it might not hurt the program. Why did you use
it?
The -v- suppresses generation of debug information and has no effect on the
executable size.
-d merges duplicate strings, -5 enables use of Pentium instructions and -O2
is generate code for fastest rather than smallest size. None of those
options have an expected effect in a hello world program.
Here is a screen capture of the program whose source you posted, showing the
program build, execution and size. Note that neither Microsoft nor Borland
have optimized their compilers for play programs such as "hello world".
Their strong suit is in real world programs. These days disks come with
many gigabytes and the size of a "hello world" style program bears little
relationship to the programs normally placed on those disks.
--------------------------------------------
C:\Documents and Settings\Edward\My Documents\lookat\q070
Quote
copy con hello.cpp
#include <stdio.h>
int main()
{
printf("hello\n");
return 0;
}
^Z
1 file(s) copied.
C:\Documents and Settings\Edward\My Documents\lookat\q070
Quote
bcc32 -WCR hello
Borland C++ 5.6.4 for Win32 Copyright (c) 1993, 2002 Borland
hello.cpp:
Turbo Incremental Link 5.66 Copyright (c) 1997-2002 Borland
C:\Documents and Settings\Edward\My Documents\lookat\q070
Quote
hello
hello
C:\Documents and Settings\Edward\My Documents\lookat\q070
Quote
dir hello.exe
Volume in drive C has no label.
Volume Serial Number is FC8D-A209
Directory of C:\Documents and Settings\Edward\My Documents\lookat\q070
08/01/2006 11:45 PM 6,656 hello.exe
1 File(s) 6,656 bytes
0 Dir(s) 31,831,154,688 bytes free
C:\Documents and Settings\Edward\My Documents\lookat\q070
Quote

--------------------------------------------
. Ed
Quote
Frederico pissarra wrote in message
news: XXXX@XXXXX.COM ...

>>Why BCC32/ILINK32 makes an EXE file almost twice the size of file
>>created by MS CL/LINK?
>
>My guess is that it is because the two executables were built with
>different options.
>

Sorry about the delay in my reply....

Ed, those are my compilers switches for both compilers:

bcc32 -O2 -a -k- -v- -d -5 hello.cpp

cl -O2 -G5s hello.cpp

As you can see the options are not that different (-O2 in both, compiles
for Pentium, -k- do not generate stack frames if possible, the same as -Gs
in CL, and I had to make sure that BCC32 do not generate debug info
using -v-). Adding -WC option in bcc32 do not help!

The simple code I use for this test is something like this:

-----------%<--------------%<--------------
#include <stdio.h>

int main()
{
printf("hello\n");
return 0;
}
-----------%<--------------%<--------------

No cout, no streams, no objects... just nice and clear C code...

BCC32/ILINK (BCB2006) generates an EXE image twice the size of that
generated by CL/LINK (VS2003)
 

Re:EXE image size

"Ed Mulroy" < XXXX@XXXXX.COM >escreveu na mensagem
Quote
What you show confirms my suspicions. You used no command line option to
specify dynamic linking so the Borland compiler created a static linked
executable.

I tried to use the same options for both compilers.... to be completelly
fair I don't use rtl dlls in my tests.... But, using RTL I got the same
results:
Following your tips I supress the aditional options from my tests and did
this:
For BCC: bcc32 -WC (no rtl)
bcc32 -WCR (with rtl)
For CL: cl -ML (no rtl)
cl -MD (with rtl)
Here my directory:
02/08/2006 12:57 <DIR>.
02/08/2006 12:57 <DIR>..
02/08/2006 12:48 75 hello.c
02/08/2006 12:52 55.296 hello_bc.exe
02/08/2006 12:52 6.656 hello_bc_rtl.exe
02/08/2006 12:49 36.864 hello_vc.exe
02/08/2006 12:51 3.584 hello_vc_rtl.exe
So... without RTL MSVC creates 36864 bytes executable.... BCC 55296
with RTL: MSVC 3584, BCC 6656
Why the discrepancy? Of course if you compile and link bigger projects the
size of initialization/finalization code will be pratically hidden from the
rest (2~3k). But this don't explain why BCC creates images almost twice the
size of MSVC!!! In this simple app I'm not linking VCL or any other library
than the standard C library!!
Even if I compile with -c switch and link by hand (ignoring default
libraries), the result are the same (In my tests)....
In theory, BCC code should be smaller than VC code 'cause VC tends to use
table driven optimization for switch() statements (for instance!), and BCC32
tends to create code (if...then..else)... something like this:
VC Code:
---------------------------------------------------
and eax,3
mov ecx,offset table
jmp [ecx+eax]
@1:
call dosomething
jmp @exit
@2:
call dosomethingelse
jmp @exit
@3:
call dosomethingdifferent
jmp @exit
@4:
call dosomethingcrazy
@exit:
ret
table dd offset @1
dd offset @2
dd offset @3
dd offset @4
BCC Code
---------------------------
or eax,eax
jz @1
dec eax
jz @2
dec eax
jz @3
call somethingcrazy
jmp @exit
@1:
call dosomething
jmp @exit
@2:
call dosomethingelse
jmp @exit
@3:
call dosomethingdifferent
@exit:
ret
BCC code is smaller and probably a few cycles less eficient, but it's
smaller!!!
Quote

Here is a screen capture of the program whose source you posted, showing
the program build, execution and size. Note that neither Microsoft nor
Borland have optimized their compilers for play programs such as "hello
world". Their strong suit is in real world programs. These days disks
come with many gigabytes and the size of a "hello world" style program
bears little relationship to the programs normally placed on those disks.

Ok.... a more complex example then:
---------%<--------------%<------------
#include <iostream>
#include <vector>
int main()
{
vector<int>v;
vector<int>::iterator i;
v.push_back(1);
v.push_back(2);
v.push_back(3);
for (i = v.begin(); i != v.end(); i++)
cout << *i << endl;
}
---------%<--------------%<------------
Without RTL: BCC32 ->277504 bytes
CL ->98304 bytes
With RTL BCC32 ->11776 bytes
CL ->9216 bytes
Is VC++ a better compiler than BCC32?
Is MS LINK better than ILINK32 used by Borland?
In my tests CL creates smaller and FASTER (a few cycloes faster) code than
BCC32!
[]s
Fred
 

Re:EXE image size

Frederico pissarra wrote:
Quote
Is VC++ a better compiler than BCC32?
Yes it is. It produces, in general, better code and it is much more
standard compliant.
Quote
Is MS LINK better than ILINK32 used by Borland?
You can compare compilers but not the linkers. Linkers work or not.
Quote

In my tests CL creates smaller and FASTER (a few cycloes faster) code than
BCC32!
So?
 

Re:EXE image size

Ok, so your code demos built with VC report as smaller and you interpret
that as indicating one is "better" than the other. You are entitled to your
opinions.
As for the jump table vs if-else, which the Borland compiler uses depends
upon the source code and a little bit on the options settings. I assume the
other compiler is similar in that regard.
. Ed
Quote
Frederico pissarra wrote in message
news:44d0d46d$ XXXX@XXXXX.COM ...

I tried to use the same options for both compilers.... to be completelly
fair I don't use rtl dlls in my tests.... But, using RTL I got the same
results:
Following your tips I supress the aditional options from my tests and did
this:

For BCC: bcc32 -WC (no rtl)
bcc32 -WCR (with rtl)

For CL: cl -ML (no rtl)
cl -MD (with rtl)

Here my directory:

02/08/2006 12:57 <DIR>.
02/08/2006 12:57 <DIR>..
02/08/2006 12:48 75 hello.c
02/08/2006 12:52 55.296 hello_bc.exe
02/08/2006 12:52 6.656 hello_bc_rtl.exe
02/08/2006 12:49 36.864 hello_vc.exe
02/08/2006 12:51 3.584 hello_vc_rtl.exe

So... without RTL MSVC creates 36864 bytes executable.... BCC 55296 with
RTL: MSVC 3584, BCC 6656

Why the discrepancy? Of course if you compile and link bigger projects the
size of initialization/finalization code will be pratically hidden from
the rest (2~3k). But this don't explain why BCC creates images almost
twice the size of MSVC!!! In this simple app I'm not linking VCL or any
other library than the standard C library!!

Even if I compile with -c switch and link by hand (ignoring default
libraries), the result are the same (In my tests)....

In theory, BCC code should be smaller than VC code 'cause VC tends to use
table driven optimization for switch() statements (for instance!), and
BCC32 tends to create code (if...then..else)... something like this:

VC Code:
---------------------------------------------------
and eax,3
mov ecx,offset table
jmp [ecx+eax]
@1:
call dosomething
jmp @exit
@2:
call dosomethingelse
jmp @exit
@3:
call dosomethingdifferent
jmp @exit
@4:
call dosomethingcrazy
@exit:
ret
table dd offset @1
dd offset @2
dd offset @3
dd offset @4


BCC Code
---------------------------
or eax,eax
jz @1
dec eax
jz @2
dec eax
jz @3
call somethingcrazy
jmp @exit
@1:
call dosomething
jmp @exit
@2:
call dosomethingelse
jmp @exit
@3:
call dosomethingdifferent
@exit:
ret

BCC code is smaller and probably a few cycles less eficient, but it's
smaller!!!

>...
Ok.... a more complex example then:

---------%<--------------%<------------
#include <iostream>
#include <vector>

int main()
{
vector<int>v;
vector<int>::iterator i;

v.push_back(1);
v.push_back(2);
v.push_back(3);

for (i = v.begin(); i != v.end(); i++)
cout << *i << endl;
}
---------%<--------------%<------------
Without RTL: BCC32 ->277504 bytes
CL ->98304 bytes

With RTL BCC32 ->11776 bytes
CL ->9216 bytes

Is VC++ a better compiler than BCC32?
Is MS LINK better than ILINK32 used by Borland?

In my tests CL creates smaller and FASTER (a few cycloes faster) code than
BCC32!
 

Re:EXE image size

On Wed, 02 Aug 2006 14:42:07 -0300, Darko Miletic < XXXX@XXXXX.COM >
wrote:
Quote
Frederico pissarra wrote:
>Is VC++ a better compiler than BCC32?

Yes it is. It produces, in general, better code and it is much more
standard compliant.

>Is MS LINK better than ILINK32 used by Borland?

You can compare compilers but not the linkers. Linkers work or not.

Not completely true. Some optimizations (the so-called "global"
optimizations) are done by the linker. So linkers may bve compared by
the effectiveness of the global optimizations.
Zara
 

Re:EXE image size

"Ed Mulroy" < XXXX@XXXXX.COM >escreveu na mensagem
Quote
Ok, so your code demos built with VC report as smaller and you interpret
that as indicating one is "better" than the other. You are entitled to
your opinions.
Not only smaller, but FASTER code.... and my tests are not stricted to small
demos (unfortunately I cannot post bigger projects here or in the
attachments newsgrooup - those are corporate products!)... Every single test
I made using both compilers leads to the conclusion that MSVC creates better
code.
Don't get me wrong... I love Borland... But I think, instead of improving
the IDE so much, Borland should improve it's compilers. Take Delphi as an
example: The code created by Delphi is far from optimum (sometimes I got
instructions, in sequence, like this: mov eax,ebx; mov ebx,eax!!!).
It's sad 'cause I've benn using borland compilers since Turbo Pascal 1.0
(and Turbo C 2.0)... But I think Microsoft is winning now...
Quote

As for the jump table vs if-else, which the Borland compiler uses depends
upon the source code and a little bit on the options settings. I assume
the other compiler is similar in that regard.

I didn't see BCC32 creating table driven routines at compile time.... MSVC
do it all the time....
[]s
Fred
 

Re:EXE image size

Quote
I didn't see BCC32 creating table driven routines at compile time
In compiling a switch BCC32 can create either of a if-else set or a jump
table depending upon complexity and options settings.
Quote
...Take Delphi as an example ...
No. Delphi is a different language with different constraints, different
concepts and different code generation.
. Ed
Quote
Frederico pissarra wrote in message
news: XXXX@XXXXX.COM ...

Not only smaller, but FASTER code.... and my tests are not stricted to
small demos (unfortunately I cannot post bigger projects here or in the
attachments newsgrooup - those are corporate products!)... Every single
test I made using both compilers leads to the conclusion that MSVC creates
better code.

Don't get me wrong... I love Borland... But I think, instead of improving
the IDE so much, Borland should improve it's compilers. Take Delphi as an
example: The code created by Delphi is far from optimum (sometimes I got
instructions, in sequence, like this: mov eax,ebx; mov ebx,eax!!!).

It's sad 'cause I've benn using borland compilers since Turbo Pascal 1.0
(and Turbo C 2.0)... But I think Microsoft is winning now...

I didn't see BCC32 creating table driven routines at compile time.... MSVC
do it all the time....
 

Re:EXE image size

"Ed Mulroy" < XXXX@XXXXX.COM >escreveu na mensagem
Quote
>I didn't see BCC32 creating table driven routines at compile time

In compiling a switch BCC32 can create either of a if-else set or a jump
table depending upon complexity and options settings.

>...Take Delphi as an example ...

No. Delphi is a different language with different constraints, different
concepts and different code generation.

But the generated code isn't optimum.... There is no "common subexpression
elimination", no "loop unrolling", no "intrinsic funcions" (except for those
defined in the compiler), and a lot of automatic optimizations available in
every good C/C++ compiler.... Even GNU Pascal is better then Delphi Compiler
in this aspect!
[]s
Fred
Quote
. Ed

>Frederico pissarra wrote in message
>news: XXXX@XXXXX.COM ...
>
>Not only smaller, but FASTER code.... and my tests are not stricted to
>small demos (unfortunately I cannot post bigger projects here or in the
>attachments newsgrooup - those are corporate products!)... Every single
>test I made using both compilers leads to the conclusion that MSVC
>creates better code.
>
>Don't get me wrong... I love Borland... But I think, instead of improving
>the IDE so much, Borland should improve it's compilers. Take Delphi as an
>example: The code created by Delphi is far from optimum (sometimes I got
>instructions, in sequence, like this: mov eax,ebx; mov ebx,eax!!!).
>
>It's sad 'cause I've benn using borland compilers since Turbo Pascal 1.0
>(and Turbo C 2.0)... But I think Microsoft is winning now...
>
>I didn't see BCC32 creating table driven routines at compile time....
>MSVC do it all the time....


 

Re:EXE image size

I don't know what GNU Pascal does but what it does not do is handle the
Delphi language.
I also do not know much about the internals of Delphi. You might want to
discuss that product in the Delphi newsgroups where people more familiar
with it are found, newsgroups with the word 'delphi' in their name.
. Ed
Quote
Frederico pissarra wrote in message
news:44d220dc$ XXXX@XXXXX.COM ...

But the generated code isn't optimum.... There is no "common subexpression
elimination", no "loop unrolling", no "intrinsic funcions" (except for
those defined in the compiler), and a lot of automatic optimizations
available in every good C/C++ compiler
.... Even GNU Pascal is better then Delphi Compiler in this aspect!
 

Re:EXE image size

Ed Mulroy wrote:
Quote
Ok, so your code demos built with VC report as smaller and you
interpret that as indicating one is "better" than the other. You are
entitled to your opinions.

I guess you to have heard of Less is More and KISS (Keep It Simple
Stupid ;)
I would second the OP that this is indeed valid concerns in compiler
evaluation.
--
frode
 

Re:EXE image size

The "Ed Mulroy Logic" which is abundantly spouted and demonstrated in this
newsgroup by, none other than, Ed Mulroy is seldom understood... (many
suspect Ed must be related to Frank Borland :)
Warmest regards,
John
"Frode Nilsen" < XXXX@XXXXX.COM >wrote in message
Quote
Ed Mulroy wrote:

>Ok, so your code demos built with VC report as smaller and you
>interpret that as indicating one is "better" than the other. You are
>entitled to your opinions.
>

I guess you to have heard of Less is More and KISS (Keep It Simple
Stupid ;)

I would second the OP that this is indeed valid concerns in compiler
evaluation.


--
frode
 

Re:EXE image size

Quote
...(many suspect Ed must be related to Frank Borland :)
I take that as a complement - Frank, wandering near the Mexican border with
his mule came up with the basis for a great company. His influence
continued on. For example people used to post on Borland's forums asking
for free copies of the products citing statements from Frank that they could
have them. :-)
The main disk drives in computers are no longer 160K. You will find
difficulty locating a PC with one even as small as 2,000 Meg these days.
Program size has taken a back seat to functionality and development time.
Excessive concern about program size seems to remain only with those such as
me who mostly do embedded work. With such tasks you are most likely using
customized startup and libraries anyway so the issues the man expressed are
not likely to apply.
Quote
... Ed Mulroy is seldom understood ...
Have you been talking to my wife?
. Ed
Quote
John Smith wrote in message
news: XXXX@XXXXX.COM ...

The "Ed Mulroy Logic" which is abundantly spouted and demonstrated in this
newsgroup by, none other than, Ed Mulroy is seldom understood... (many
suspect Ed must be related to Frank Borland :)