Re: C23 thoughts and opinions

On Sun, 9 Jun 2024 11:20:11 +0100
bart <bc@freeuk.com> wrote:

On 09/06/2024 10:40, Michael S wrote:

On Sat, 8 Jun 2024 14:52:26 -0500
BGB <cr88192@gmail.com> wrote:
 

On 6/8/2024 1:28 PM, Malcolm McLean wrote: 

On 07/06/2024 01:53, Lawrence D'Oliveiro wrote: 

On Thu, 6 Jun 2024 15:38:21 -0500, BGB-Alt wrote:
   

*2: Seemingly the main way I am aware of to get small binaries
is to use an older version of MSVC (such as 6.0 to 9.0), as the
binary-bloat started to get much more obvious around Visual
Studio 2010, but is less of an issue with VS2005 or VS2008. 

>
Newer version of proprietary compiler generates worse code than
older version?!? 

If the code is calling extern gunctions that do IO, we woul expect
these to be massively more sophisticated on a modern ststem Witha
little comouter, pribtf just wtites acharacter raster and
utimalthe he Os picks the up and flushes it out to a pixel
raster. And that' aal it's doing. Whilst on a modrern syste,
stdout can do whole lot of intricate things. 

>
That is a whole lot of typos...
>
>
But, even if it is built calling MSVCRT as a DLL (rather than
static linked), modern MSVC is still the worst of the bunch in
this area.
>
A build as RISC-V + PIE with a static-linked C library still
manages to be smaller than an x64 build via MSVC with entirely
dynamic-linked libraries.
>
And, around 72% bigger than the same program built as a
dynamic-linked binary with "GCC -O3" (while also often still being
around 40% slower).
 

 
GCC on Windows or on Linux?
In my experience, gcc on Windows (ucrt64 variant, other gcc variants
are worse) very consistently produces bigger (stripped) exe than
even latest MSVCs which, as you correctly stated, are not as good
as older versions at producing small code.
 
The size of 'Hello, world' program (x86-64, dynamically linked C
RTL) vs2013 - 6,144 bytes
vs2019 - 9,216 bytes
gcc (Debian Linux, -no-pie) - 14,400 bytes
gcc (Debian Linux) - 14,472 bytes
gcc (ucrt64 DLL) - 18,432 bytes
gcc (old DLL) - 42,496 bytes 

 
I get a lot worse than that:
 
    C:\c>gcc hello.c 
 
    C:\c>dir a.exe 
    09/06/2024  11:04           367,349 a.exe
 
    C:\c>gcc hello.c -s -Os 
 
    C:\c>dir a.exe 
    09/06/2024  11:04            88,064 a.exe
 
(It didn't like -Oz; did you mean something other than -Os?)
 

No, I meant -Oz.
It was invented by clang, but newer gcc understand it.
I don't know what is a difference exactly, but -Oz tends to be a little
smaller.
In program as trivial as this, there should be no difference.

Both import msvcrt.dll. gcc is version 10.3.0.
>

My gcc variants are from msys2.
Where did you get yours?

tcc gives 2KB, and mcc gives 2.5KB.
 

x86-64 or i386?
I think, on i386 VC5 can come close, but can not match it.
I don't have VC5 right now. Last time I tried to find it it was
surprisingly hard.
Well, probably I still has it on one very old PC that I didn't power up
for many years. I don't know if it is still alive.

(With the latter, I know it is because it uses a comprises 5 blocks
of data each of which is at least 512 bytes: 2 for header stuff, plus
always 3 segments. The mininum hello.exe size I think is 700 bytes if
a few corners are cut.)
 
367KB sounds astonishing, but the first time I tried Dart, it gave me
a 5MB executable for 'hello.dart'.

golang tend to start at >1.5MB, but then it grows very slowly. It
appears to generate *very* self-contained executives. At least I
personally never encountered case where simple copy of exe to new
computer was insufficient.
Considering that go needs much more of run-time support than dart, I
can't find any reason for 5MB except "they don't care".