boyd_m@intertel.UUCP (Mark Boyd) (03/14/91)
The company I work at has a large Windows program. We just got Borland C++
and made the necessary conversions and compiled it. The size differences are
quite surprising.
Microsoft C 5.1 .EXE: 720672 bytes
Borland C++ .EXE: 842848 bytes
The optimization for Microsoft is -Os for space. The optimization for Borland
is all but -Z (aliasing). I'm interested in knowing what everyone else is
seeing.
Mark Boyd
Inter-Tel, Inc.kevin@msa3b.UUCP (Kevin P. Kleinfelter) (03/15/91)
boyd_m@intertel.UUCP (Mark Boyd) writes: >The company I work at has a large Windows program. We just got Borland C++ >and made the necessary conversions and compiled it. The size differences are >quite surprising. > Microsoft C 5.1 .EXE: 720672 bytes > Borland C++ .EXE: 842848 bytes >The optimization for Microsoft is -Os for space. The optimization for Borland >is all but -Z (aliasing). I'm interested in knowing what everyone else is >seeing. On a typical program I get Microsoft C 6.0 .EXE: 142000 bytes Borland C++ .EXE: 000000 bytes My code needs to be linked to a vendors object library, compiled with MSC. Borland C++ supports MS WINDOWS but not MS libraries. :-( -- Kevin Kleinfelter @ Dun and Bradstreet Software, Inc (404) 239-2347 ...gatech!nanovx!msa3b!kevin Warning: There seem to be multiple 'msa3b' nodes on Usenet, and it is nanoVX, not nanovAx.
cadsi@ccad.uiowa.edu (CADSI) (03/17/91)
From article <1573@msa3b.UUCP>, by kevin@msa3b.UUCP (Kevin P. Kleinfelter): > boyd_m@intertel.UUCP (Mark Boyd) writes: > > On a typical program I get > Microsoft C 6.0 .EXE: 142000 bytes > Borland C++ .EXE: 000000 bytes ^^^^^^ Whew!!! Not bad optimization :-) |----------------------------------------------------------------------------| |Tom Hite | The views expressed by me | |Manager, Product development | are mine, not necessarily | |CADSI (Computer Aided Design Software Inc.) | the views of CADSI. | |----------------------------------------------------------------------------|
mg@phoenix.Princeton.EDU (Michael Golan) (03/20/91)
boyd_m@intertel.UUCP (Mark Boyd) writes: >The company I work at has a large Windows program. We just got Borland C++ >and made the necessary conversions and compiled it. The size differences are >quite surprising. > Microsoft C 5.1 .EXE: 720672 bytes > Borland C++ .EXE: 842848 bytes >The optimization for Microsoft is -Os for space. The optimization for Borland >is all but -Z (aliasing). I'm interested in knowing what everyone else is >seeing. Ok guys, anyone care to comment? I always felt that MSC produced shorter code for any *REAL* program. The above test is not even fair to MS, as MSC6 produces a little shorter code (3-6% in my large programs). Also, -Os is not optimal for code size (Despite what the manual say, you can reduce the code a little more by playing with the options). Brand new borland.com, are you listening? Prove us wrong or give us a (slow version) compiler that produces shorter code! Michael Golan mg@princeton.edu
sidney@borland.com (Sidney Markowitz) (03/20/91)
mg@phoenix.Princeton.EDU (Michael Golan) writes: >boyd_m@intertel.UUCP (Mark Boyd) writes: >> Microsoft C 5.1 .EXE: 720672 bytes >> Borland C++ .EXE: 842848 bytes > >Ok guys, anyone care to comment? Um, I may have a vested interest in the results coming out one way rather than the other, but aside from that I would like to point out that the size of the EXE file is not a good measure of the compiler optimization. Is there any debugging info in there? Are the two linkers making the same decisions as to when not to take up space in the exe file for uninitialized data? The Microsoft linker does fixup threading and the Borland linker does not, and the two linkers make different assumptions about segment alignment, both of which affect the exe size without affecting the executable image. Also, how much of the executable is a result of the run time library, and how much is output of the compiler? If you really want to compare the outputs of the compiler by size (and not speed) you should get detailed link maps and compare those. By the way, from what I've seen, any fair comparison will show that Microsoft C has much better code optimization, especially for loop optimization and integer arithmetic, and Borland C++ has a much faster and tighter RTL and floating point processing. So if execution speed is your main consideration, you can choose one or the other depending on how much of your program time is spent in your code or in library routines. -- sidney markowitz <sidney@borland.com> Borland International (Languages - R&D)
mckulka@andunie.endor.cs.psu.edu (Christopher Mc Kulka) (03/20/91)
In article <7320@idunno.Princeton.EDU> mg@phoenix.Princeton.EDU (Michael Golan) writes: >boyd_m@intertel.UUCP (Mark Boyd) writes: > >>The company I work at has a large Windows program. We just got Borland C++ >>and made the necessary conversions and compiled it. The size differences are >>quite surprising. >> Microsoft C 5.1 .EXE: 720672 bytes >> Borland C++ .EXE: 842848 bytes >>The optimization for Microsoft is -Os for space. The optimization for Borland >>is all but -Z (aliasing). I'm interested in knowing what everyone else is >>seeing. > >Ok guys, anyone care to comment? I always felt that MSC produced shorter code >for any *REAL* program. The above test is not even fair to MS, as MSC6 >produces a little shorter code (3-6% in my large programs). Also, -Os is >not optimal for code size (Despite what the manual say, you can reduce the >code a little more by playing with the options). > >Brand new borland.com, are you listening? Prove us wrong or >give us a (slow version) compiler that produces shorter code! Hey, ease up on Borland. Their compiler has to translate a much more complicated language. The difference is not even that large to begin with. When you consider that programming with C++ will probably allow you to finish a better program sooner I think the the small size sacrifice is quite acceptable. Not to mention the fact that this is still very early in the developement of C++ compilers. Borland managed to produce an excellent C++ compiler before MicroSloth could even get one out the door (or even close). MS has years of experience with C -- Borland just started (relatively) with C++. While we are on the subject of Borland vs. MS let's talk about technical support. Borland's is free and truly excellent. I have called three times and found intelligent, helpful people on the other end. When they could not answer one of my questions they promised to call me back. An hour later I received a call from Borland tech support with an answer. I will not even mention price or the fact that Borland's package includes the world's best debugger (sorry, but Codeview is not even in the same league) and a profiler and an assembler and innovative overlay support and ... Enough said. -- Just say *NO* to software patents & look-and-feel lawsuits. Try comptetion instead. Sex isn't the answer . . . it's the question. "Yes" is the answer.
sdawalt@cs.wright.edu (Shane Dawalt) (03/21/91)
From article <7320@idunno.Princeton.EDU>, by mg@phoenix.Princeton.EDU (Michael Golan): > > Brand new borland.com, are you listening? Prove us wrong or > give us a (slow version) compiler that produces shorter code! > Is there a reason to care how large the file is? If it's an application (which it is) and if it runs under windows (which it does) then let Windows worry about memory space. Your machine should have a good amount of space if you are running Windows. Disk space isn't a problem since hard drives are relatively inexpensive. Loading speed isn't a problem since only part of the program is loaded by Windows. Execution speed is the major consideration nowadays. A database program can be 50K in size, but if it takes 1 hour to search through 50 records then the program is absolutely useless. If your concern is distribution then you can use archivers that compress an .EXE up to 50% (depending upon the .EXE itself). What would anyone want a SLOW compiler??? Everyone hollars for faster compilers and code. What is this, two steps forward and three steps back? Shane(); -- -------------------------------------------------------------------------- From the keyboard of: email: sdawalt@cs.wright.edu Shane A. Dawalt --------------------------------------------------------------------------
jack@cscdec.cs.com (Jack Hudler) (03/21/91)
In article <pc8G0.&31@cs.psu.edu> mckulka@andunie.endor.cs.psu.edu (Christopher Mc Kulka) writes: > >Hey, ease up on Borland. Their compiler has to translate a much more complicated language. The difference is not even that large to begin with. When you >consider that programming with C++ will probably allow you to finish a better >program sooner I think the the small size sacrifice is quite acceptable. Did you ever stop to think that it might cause us ship an extra diskette to our customers, multiply that cost times the number product we ship and it becomes a large number! Many times more than the benefit of C++. -- Jack Computer Support Corporation Dallas,Texas Hudler Internet: jack@cscdec.cs.com
kwong@polyslo.CalPoly.EDU (Ka Chin Wong) (03/21/91)
>boyd_m@intertel.UUCP (Mark Boyd) writes: >> Microsoft C 5.1 .EXE: 720672 bytes >> Borland C++ .EXE: 842848 bytes > >Ok guys, anyone care to comment? I am glad that you mentioned Microsoft C (not Microsoft C++) vs. Borland C++ (not Turbo C). You know, in C, all variables are static bound (early bounding), but C++ allows dynamic bounding (late bounding) by means of virtual functions. Would the additional bytes be the overhead to handle late bounding at runtime? Let's wait for the Microsoft C++ and do the comparison. Rick
flint@gistdev.gist.com (Flint Pellett) (03/22/91)
mg@phoenix.Princeton.EDU (Michael Golan) writes: >boyd_m@intertel.UUCP (Mark Boyd) writes: >>The company I work at has a large Windows program. We just got Borland C++ >>and made the necessary conversions and compiled it. The size differences are >>quite surprising. >> Microsoft C 5.1 .EXE: 720672 bytes >> Borland C++ .EXE: 842848 bytes >>The optimization for Microsoft is -Os for space. The optimization for Borland >>is all but -Z (aliasing). I'm interested in knowing what everyone else is >>seeing. Are those numbers the size of the .exe file, or the actual code size? (You can find out the size of the code with MSC's "exemod" program.) I know the .exe size and the code size don't always have much to do with one another, and compiler options can affect it a lot. For example, I recently built a program with MSC 5.1, and Watcom C 7.0: The .exe sizes were both 115K. exemod showed better what was going on: the minimum load size was 131K for MSC, 115K for Watcom. (If you really want good code, get Watcom C: it tends to be 10% better.) I think Borland tends to leave a lot of things in the .exe to aid debugging that don't actually increase the amount of memory the program needs to execute, so things may not be as bad as you think. I'll try my program under TC++ and see what the results are there. -- Flint Pellett, Global Information Systems Technology, Inc. 1800 Woodfield Drive, Savoy, IL 61874 (217) 352-1165 uunet!gistdev!flint or flint@gistdev.gist.com
yeates@motcid.UUCP (Tony J Yeates) (03/23/91)
Doesn't compiler optimization usually optimise for speed rather than size? Obviously speed improvements will sometimes be at the cost of increased size.
s872625@minyos.xx.rmit.oz.au (Chris Cogdon [Brataccas]) (03/25/91)
kwong@polyslo.CalPoly.EDU (Ka Chin Wong) writes: >You know, in C, all variables are static bound (early bounding), >but C++ allows dynamic bounding (late bounding) by means of >virtual functions. Would the additional bytes be the overhead >to handle late bounding at runtime? >Let's wait for the Microsoft C++ and do the comparison. I would say that the dynamic binding facilities will only be used if you actually write virtual functions -ie use the ++ part of C++. Considering that a comparison is being made with MSC5.1, i'd say that the test program is a STANDARD C program (no K&R vs ANSI here please) and that the BC++ compiler is defaulting to standard C compiler (was this specified?? I don't think it'll make a difference anyway!) ------------------------------------------------------------------------------- Chris Cogdon [Brataccas] s872625@minyos.xx.rmit.oz All spelling and gramatical errors are the fault of a malicious filter. Semantic errors are the fault of a warped mind.
alexande@borland.com (Mark Alexander) (03/26/91)
In article <7320@idunno.Princeton.EDU> mg@phoenix.Princeton.EDU (Michael Golan) writes: >boyd_m@intertel.UUCP (Mark Boyd) writes: > >>The company I work at has a large Windows program. We just got Borland C++ >>and made the necessary conversions and compiled it. The size differences are >>quite surprising. >> Microsoft C 5.1 .EXE: 720672 bytes >> Borland C++ .EXE: 842848 bytes >>The optimization for Microsoft is -Os for space. The optimization for Borland >>is all but -Z (aliasing). I'm interested in knowing what everyone else is >>seeing. > >Ok guys, anyone care to comment? I always felt that MSC produced shorter code >for any *REAL* program. The above test is not even fair to MS, as MSC6 >produces a little shorter code (3-6% in my large programs). Also, -Os is >not optimal for code size (Despite what the manual say, you can reduce the >code a little more by playing with the options). It would be interesting to see how much of the EXE file is actually code. Possibly you're seeing the result of TLINK putting "far" uninitialized data in the EXE file, instead of letting the loader zero the data (the MSC approach). Once the programs are loaded, the difference may not be nearly as large as the EXE file sizes would indicate. Admittedly, it would be nice to not waste the extra disk space.