Path: ...!news.nobody.at!2.eu.feeder.erje.net!feeder.erje.net!newsfeed.bofh.team!paganini.bofh.team!not-for-mail
From: antispam@fricas.org (Waldek Hebisch)
Newsgroups: comp.lang.c
Subject: Re: else ladders practice
Date: Sun, 24 Nov 2024 15:00:17 -0000 (UTC)
Organization: To protect and to server
Message-ID: <vhvf1v$9k2m$1@paganini.bofh.team>
References: <3deb64c5b0ee344acd9fbaea1002baf7302c1e8f@i2pn2.org>   <vhins8$1vuvp$1@dont-email.me> <vhj7nc$2svjh$1@paganini.bofh.team> <vhje8l$2412p$1@dont-email.me> <WGl%O.42744$LlWc.33050@fx42.iad> <vhkr9e$4bje$1@dont-email.me> <vhptmn$3mlgf$1@paganini.bofh.team> <vhq6b4$17hkq$1@dont-email.me> <vhqm3l$3ntp7$1@paganini.bofh.team> <vhso61$1o2of$1@dont-email.me> <vhtrns$71ic$1@paganini.bofh.team> <vhtvvc$1ukc7$1@dont-email.me> <vhuc2j$7s5i$1@paganini.bofh.team> <vhv5m4$27sco$1@dont-email.me>
Injection-Date: Sun, 24 Nov 2024 15:00:17 -0000 (UTC)
Injection-Info: paganini.bofh.team; logging-data="315478"; posting-host="WwiNTD3IIceGeoS5hCc4+A.user.paganini.bofh.team"; mail-complaints-to="usenet@bofh.team"; posting-account="9dIQLXBM7WM9KzA+yjdR4A";
User-Agent: tin/2.6.2-20221225 ("Pittyvaich") (Linux/6.1.0-9-amd64 (x86_64))
X-Notice: Filtered by postfilter v. 0.9.3
Bytes: 5561
Lines: 98

Bart <bc@freeuk.com> wrote:
> On 24/11/2024 05:03, Waldek Hebisch wrote:
>> Bart <bc@freeuk.com> wrote:
> 
>>> As for sizes:
>>>
>>>    c:\c>dir hello.exe
>>>    24/11/2024  00:44             2,048 hello.exe
>>>
>>>    c:\c>dir a.exe
>>>    24/11/2024  00:44            91,635 a.exe         (48K with -s)
>>>
>>> (At least that's one good thing of gcc writing out that weird a.exe each
>>> time; I can compare both exes!)
>> 
>> AFAICS this is one-time Windows overhead + default layout rules for
>> the linker.  On Linux I get 15952 bytes by defauls, 14472 after
>> striping.  However, the actual code + data size is 1904 and even
>> in this most is crap needed to support extra features of C library.
>> 
>> In other words, this is mostly irrelevant, as people who want to
>> get size down can link it with different options to get smaller
>> size down.  Actual hello world code size is 99 bytes when compiled
>> by gcc (default options) and 64 bytes by tcc.
> 
> I get a size of 3KB for tcc compiling hello.c under WSL.

That more or less agrees with file size that I reported.  I
prefer to look at what 'size' reports and at looking at .o
files, as this is more relevant when scaling to larger
programs.  Simply, 10000 programs with 16kB overhead each
is 160MB overhead.  When it matters, then I am likely to
have much less than 10000 executables.  100 executables
each 10MB are more likely.  Note that there is old Unix
trick of puting multiple programs into a single file
(executable).  The executable appears in filesystem under
say 100 names and performs different things depending on
the name.  There is dispatching code, something like 40
bytes per name, so there is overhead, but much lower than
having independent executables.  So, per program
overhead can be quite small.

Larger size (16kB) is due to page alignment of program parts
which have some benefits.  So there are tradofs, and when
size matters there are ways to save disc space.  OTOH if
actual code takes a lot of space, then there is no easy
solution.

> On Windows, my cc compiler has the option of generating my private 
> binary format called 'MX':
> 
>   c:\c>cc -mx hello
>   Compiling hello.c to hello.mx
> 
>   c:\c>dir hello.mx
>   24/11/2024  11:58               194 hello.mx
> 
> Then the size is 194 bytes (most of that is a big header and list of 
> default DLL files to import). However that requires a one-off launcher 
> (12KB compiled as C) to run it:
> 
>   c:\c>runmx hello
>   Hello, World!
> 
> (In practice, MX files are bigger than equivalent EXEs since they 
> contain more reloc info. I developed the format before I had options for 
> PIC/relocatable code, which is necessary for OBJ/DLL formats.)

In Linux typically filesystem block size is 4kB, so anything bigger
than 0 takes at least 4kB.  So super-small executables (I think
record is below 200 bytes) do not really save space.  And they
actually need more RAM, as system first loads program file into
buffers.  If program is properly organized, it could be executed
directly from file buffer.  But super-small executable needs extra
copy, to put parts in separate pages.  So there is a compromise
between memory use and disc space, and usually moderate increase
in disc use is considered worth lower memory use.  
 
>> If I do not have good reasons to write program in C, then likely I
>> will write it in some higher-level language.  One good reason
>> to use C is to code performance-critical routines.
> 
> It can also do manipulations that are harder in a 'softer', safer HLL. 
> (My scripting language however can still do most of those underhand things.)

Anything computational can be done in a HLL.  You may wish to
play tricks to save time.  Or possible some packing tricks to
save memory.  But packing tricks can be done in HLL (say by
treating whole memory as a big array of u64), so this really
boils down to speed.

You may wish to write an OS or to interact with hardware, but
here I usuallt want optimization.  Maybe not as aggressive
as modern gcc, but at least of order of gcc-1 (which probably
would probably have compile times tens times lower than modern
gcc).

-- 
                              Waldek Hebisch