How to reduce the filesize of a compiled file?

[fxm]

The oldest fbc version that compiles the above code is fbc 0.17, but still 6 KB.
(the most recent fbc version that provides 6 KB is fbc 0.20.0)

[dodicat]

The above code in C

Code: Select all

#include <stdio.h>
#include <stdlib.h>
void main(void)
{

printf("Hello World!\n");
system("pause");
} 

With tinyc (tcc.exe) the exe is 2 kb
With Dev C (uses gcc) the .exe is 102 kb.
With mingw gcc the .exe is 89 kb

And in Basic
With QB64 the .exe is 1.38 mb
With RapidQ the exe is 154 kb.
(I am out of compilers)

[jj2007]

44032 with VC
29696 with Pelles C (but I am sure there is a trick to reduce it)
27930 with GCC32
26112 with MasmBasic
3072 with C# (exe)
1536 with Masm32
170 with C# (.cs)
...

There is a tradeoff between size and a minimum functionality. If the overhead exceeds, say, 32k or so, you know that coders never heard the slogan "power without the bloat" ;-)

One important aspect is whether the exe runs on the average user's machine, without the need to download and install additional packages.

[St_W]

There is a tradeoff between size and a minimum functionality. If the overhead exceeds, say, 32k or so, you know that coders never heard the slogan "power without the bloat" ;-)

Setting the limit as low as 32k is definitely no longer valid nowadays. IMHO everything < 1MB is fine nowadays and no bloat for a simple "Hello world" program. Anyway, FreeBasic should be a programming language that is easy to use and fast. You probably won't get that when optimizing for executable size. I wouldn't use FB for creating 8k demos because there are other languages more suitable for that. And I don't think that creating such small executables is a goal for FB, especially when it conflicts with easy usage or speed. Of course you are free to use old versions, but remember that a lot of bugs have been fixed since then, that are naturally still present in those old versions.

[srvaldez]

27930 with GCC32
you know that coders never heard the slogan "power without the bloat" ;-)

try using strip on the exe, on my system with gcc 7.1 the exe was 359k and after strip only 11k
PowerBasic 11k

[dodicat]

srvaldez
strip hello.exe just does a copy.
strip -o hellostripped.exe -s hello.exe just produces an exact copy of hello.exe but renamed hellostripped.exe.
What command flags do you use?

my strip.exe is in the mingw / bin folder (on path)
Win 10

[srvaldez]

dodicat, if you are talking about FB exe's they are already stripped, at least when using gen gcc, I used no options, simply strip hello.exe, it strips and replaces the exe.
if you are referring to an exe produced by gcc then I don't know why strip has no effect, unless it's automatically stripped in the compilation process.

[dodicat]

Thanks srvaldez
I was using freebasic exe files.
Works OK with C++ exe files.

[jj2007]

IMHO everything < 1MB is fine nowadays and no bloat for a simple "Hello world" program. Anyway, FreeBasic should be a programming language that is easy to use and fast. You probably won't get that when optimizing for executable size.

That is hearsay. Truth is that dense assembler code beats C any time (there is a small code cache, for example). As my list above shows, several languages CAN produce a hello world in less than 32k. You need 1MB? Explain to me what your additional 992 kBytes are doing. Hell, that is 1,015,808 bytes more, roughly 250,000 lines. I bet that language can brew cappuccinos, too.

[marcov]

One important aspect is whether the exe runs on the average user's machine, without the need to download and install additional packages.

If that is so, cancel C#, since Windows8+ comes with 4.0+ and Windows 7 comes with 2-3.5.

And binary size is more library minimalization, and much less code size. "hello world" can be implemented with one call to a library, a few tens of bytes tops. The rest is the library implementation and mandatory parts of RTS initialization/finalization.

[St_W]

Truth is that dense assembler code beats C any time (there is a small code cache, for example). As my list above shows, several languages CAN produce a hello world in less than 32k. You need 1MB? Explain to me what your additional 992 kBytes are doing. Hell, that is 1,015,808 bytes more, roughly 250,000 lines.

While that may be true at a very small scale it often is not at a larger scale. For example even dynamically compiled languages like C# or Java are faster than C sometimes due to optimizations at runtime (like partial evaluation), which is not really possible in C or, even worse, assembly. The larger code size is not caused by the "hello world" implementation being that big, but because of the runtime libraries providing a lot of convenience functions. Those are - of course - not needed for a "Hello world" implementation, but in real applications, for which a language is usually designed (rather than for small examples). Typical features implemented in a runtime library would be e.g. common data structure implementations or a garbage collector.

[jj2007]

While that may be true at a very small scale it often is not at a larger scale. For example even dynamically compiled languages like C# or Java are faster than C sometimes due to optimizations at runtime (like partial evaluation), which is not really possible in C or, even worse, assembly.

I love benchmarking! Can you produce an example where Java is faster than C, or, even worse, assembly?

The larger code size is not caused by the "hello world" implementation being that big, but because of the runtime libraries providing a lot of convenience functions. Those are - of course - not needed for a "Hello world" implementation, but in real applications, for which a language is usually designed (rather than for small examples). Typical features implemented in a runtime library would be e.g. common data structure implementations or a garbage collector.

So the 1,015,808 bytes more are for "a lot of convenience functions"? That sounds nice, but I am always flabbergasted how deep C coders have to dig in order to perform elementary "convenience functions", such as reading a text file into a string array. One line in Basic, a hundred lines plus endless forum threads where desperate C coders argue about the best way to read a text file. Wow.

Btw what is a "real application"? My editor at 20k lines, 120k exe, that takes half a second to open its own source? Or real real applications like Visual Studio Community, that takes several minutes to open itself and a hello world proggie?

[St_W]

I love benchmarking! Can you produce an example where Java is faster than C, or, even worse, assembly?

e.g. see http://blog.cfelde.com/2010/06/c-vs-java-performance/ or https://www.ibm.com/developerworks/java ... index.html for some examples.

So the 1,015,808 bytes more are for "a lot of convenience functions"? That sounds nice, but I am always flabbergasted how deep C coders have to dig in order to perform elementary "convenience functions", such as reading a text file into a string array. One line in Basic, a hundred lines plus endless forum threads where desperate C coders argue about the best way to read a text file.

C does provide only a very small runtime library. Thus it can generate very small binaries, however (as you mentioned) some tasks are more difficult to implement. FreeBasic is basically an leightweight extension of C, with a runtime library written in C and thus generates slightly bigger executables than plain C in general (due to the additional runtime library). However, things get easier. If you even add a lot more functions to a runtime library (like e.g. in C#) you get lots of convenience functions (for example, there's a File.ReadAllLines method - not kidding) but the runtime library is quite big. However, in the case of C# it's shared among the applications and not shipped with every application.

Btw what is a "real application"? My editor at 20k lines, 120k exe, that takes half a second to open its own source? Or real real applications like Visual Studio Community, that takes several minutes to open itself and a hello world proggie?

Good question. That's hard to define but I meant something with at least 1k LOC, although LOC is not a good measure:

“Measuring programming progress by lines of code is like measuring aircraft building progress by weight.”
― Bill Gates

[jj2007]

I love benchmarking! Can you produce an example where Java is faster than C, or, even worse, assembly?

e.g. see http://blog.cfelde.com/2010/06/c-vs-java-performance/ or https://www.ibm.com/developerworks/java ... index.html for some examples.

Good read, thanks. Repeating those benchmarks in FreeBasic or MasmBasic would not be so straightforward, and currently I won't have time and energy to do it. But something struck my eyes in the comments: Java still doesn’t take advantage of SSE

About 1% of the MasmBasic source lines (30k) consist of mov*ps. That is not much, but it's typically the functions that matter speedwise, such as sorting a million text strings etc.; and it does make a big difference, depending on the task at hand. I just checked: Apparently, there are no SIMD instructions in my old FreeBasic of September 14, 2014 - any idea if that has changed recently?

LOC is not a good measure:

“Measuring programming progress by lines of code is like measuring aircraft building progress by weight.”
― Bill Gates

If that guy had to pay for all the extra work that Windows bugs have caused to countless programmers, he would be the poorest man in the World, and live in a jail. But of course, the remark on LOC is right ;-)

[caseih]

Truth is that dense assembler code beats C any time (there is a small code cache, for example).

Beats it at what metric? A well-written C routine can easily best a naive assembler implementation, however dense. A well-written assembler routine would be approximately equal to a well-written C routine. Contrary to popular belief around here, hacking something out in assembler is not going to automatically make it faster in all cases, maybe not even in most cases unless your FB code is itself unoptimized and not using the right algorithms. In many cases, there are many other things you should always do first before hacking out some naive assembler code. For example, simple result caching can improve performance many times over a more naive approach. Really it's the algorithm that matters, not the language. Anyway, this doesn't necessarily relate to binary size. To get performance we need to understand big-O and what it means, and how to determine what O() our code is. O(n!) code is going to be O(n!) and unacceptable performance-wise, regardless of whether it's written in assembler or FB. Sure naive assembler might make your program run in 50% of the time of the naive FB version, but does that even matter when runtimes are either really huge (millions of years) or very short (milliseconds)? I guess I'm arguing that if the FB code is unoptimal, the assembler version will likely be unoptimal also, and though it may be faster, with the right algorithm, the pure FB implementation could be even faster.

I wonder how much SSE is found in FreeBasic, any idea?

FB code emitted through the GCC backend, with O3 optimizations enabled, could do some vectorization. But for the most part I wouldn't expect to see much SSE instructions in any code from a general-purpose language, doing general purpose procedural things. If you were doing some linear algebra, I'd expect that the match library you chose would make fairly heavy use of vectorization instructions. Likewise, unless a programmer was specifically doing some vector calculations I wouldn't expect to see much SSE in hand-coded assembly either.

It's interesting to note that the average number of LOC written per day on average by a programmer is still under a dozen. I know it's true for me. One week of coding can generate thousands of LOC, and then two weeks of debugging and tweaking.