Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: BGB <cr88192@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: C23 thoughts and opinions
Date: Sun, 9 Jun 2024 21:12:04 -0500
Organization: A noiseless patient Spider
Lines: 137
Message-ID: <v45nfu$2k71$1@dont-email.me>
References: <v2l828$18v7f$1@dont-email.me> <v38of2$1gsj2$1@dont-email.me>
 <v39v87$1n7bk$1@dont-email.me> <20240530170836.00005fa0@yahoo.com>
 <v3a3k5$1ntrn$1@dont-email.me> <20240530180345.00003d9f@yahoo.com>
 <v3chc4$27uij$1@dont-email.me> <20240531161937.000063af@yahoo.com>
 <20240531162811.00006719@yahoo.com> <20240531164835.00007128@yahoo.com>
 <v3cldt$28n91$2@dont-email.me> <20240531173437.00003bee@yahoo.com>
 <v3d3ct$2b5sl$1@dont-email.me> <v3d97c$2c6ea$1@dont-email.me>
 <22r6O.5934$xPJ1.2590@fx09.iad> <v3t6nu$1liet$1@dont-email.me>
 <v3tlmo$1o860$7@dont-email.me> <v427sv$2no3h$1@dont-email.me>
 <v42cs4$2pjrh$1@dont-email.me> <20240609124032.00004eb1@yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 10 Jun 2024 04:13:19 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="669cd30644677940012aa21dcb7c2b9c";
	logging-data="86241"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19h9QUCFA2ZWm8RVMYt/8YXHyXWec+8Dew="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:wfpMQxMHXBGBwwIcXT1j83CAIG0=
In-Reply-To: <20240609124032.00004eb1@yahoo.com>
Content-Language: en-US
Bytes: 6940

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.
>>
>