Re: C23 thoughts and opinions

On 6/9/2024 4:40 AM, 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?

Windows + WSL, which produces ELF64.
The "gcc -v" from the main version of WSL I am using:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.8.4-2ubuntu1~14.04.4' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.4)
I have another (newer) version of WSL installed, but it doesn't have Verilator and similar set up on it (nor is configured for the X11 server I am running).

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
 MSVC compilation flags: -O1 -MD
gcc compilation flags: -Oz -s
 

I guess one option could be to compare against a newer version of Cygwin or MinGW, but I haven't really used these for much in years.
General program I was comparing with here was a port of the original Doom engine (but saw similar results across various programs). Something like a "hello world" is likely too small for accurate size comparison (and will likely be dominated by overheads).
Testing small program (not much more complicated than a "hello world") generates a roughly 31K EXE with my compiler and a static-linked C library (on my ISA).
The compiler in this case strips out most things not directly needed for for "printf()" (but does seem to still include the memory-manager and filesystem interface code, likely because these are reachable from "printf()").
Building the same program as RV64 with the same static-linked C library, is 326K with a little over half of the binary being ELF/PIE metadata:
    ~ 133k .text
    ~   5K .rodata
    ~   2K .data
    The .dynsym / .dynstr / .rela.* / etc  sections eating the rest.
(It also seems like GCC isn't pruning as much for some reason; this is with "-ffunction-sections" and similar).
With dynamic linked glibc (x86-64), PIE, 9K.
With MSVC, static-linked C lib: 121K
With MSVC, dynamic-linked C lib: 10K

Contrast, VS2008 can build programs with binary sizes closer to those
of GCC.
>