Path: ...!weretis.net!feeder8.news.weretis.net!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: Sat, 8 Jun 2024 14:52:26 -0500
Organization: A noiseless patient Spider
Lines: 117
Message-ID: <v42cs4$2pjrh$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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 08 Jun 2024 21:53:41 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="51e60a99c6f849f26f298e0d84d4cfe3";
	logging-data="2936689"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/ZhTIAZvfrYSM30rv7wPgF9c0xCJ0uPxw="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:RbxsubBLNjNm+uMZpcIIVuiv/4Y=
Content-Language: en-US
In-Reply-To: <v427sv$2no3h$1@dont-email.me>
Bytes: 6322

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

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

....


I have noted that there is often a curious level of similarity between 
code generation in MSVC and what I have managed to pull off in BGBCC, 
implying that they may be "similar" in terms of optimization and 
register allocation. Can't say whether or not it is the same algorithms, 
but GCC seems to work differently.

For example:
BGBCC assigns registers either on per-function basis, or allocated 
within a basic block;
Any registers that are allocated within a basic block, are spilled to 
the stack at the end of a basic block;
Those that are static assigned to registers, will always use this 
register within the function in question.

GCC appears to locally assign registers within basic blocks and across 
the edges between basic blocks, without either global assignment or 
needing to spill them to the stack.
Seemingly in contrast to both BGBCC and (seemingly) also MSVC.


Though, that said, compiling code with my compiler and ISA still seems 
to be beating RISC-V in terms of performance (despite GCC's valiant 
efforts with "-O3").

I suspect though this is mostly due to limitations of RISC-V, and GCC 
can only work with what it is given:
   Only has a [Reg+Disp] addressing mode;
   No way to express immediate values larger than 12 bits;
   ...


And, for PIE, performing function calls and accessing global variables 
via the GOT doesn't exactly help matters.

Say, for example:
For a non-PIE build, BJX2-XG2 and RV64G were roughly break-even in terms 
of code-size, with around a 10-20% performance delta;
For a PIE build (currently needed to load RV64 binaries in my kernel), 
there is around a 60% code-size delta, and around a 20-35% performance 
delta.


Can note that I am using an ABI design that still allows for dynamic 
linking and (also) for NOMMU operation similar to FDPIC, but doesn't 
hurt performance quite as badly.

Function calls still use PC relative displacements, except for dllimport 
(which would involve a trampoline).

Global variables are accessed as a load/store relative to the Global 
Pointer. The global pointer may be saved/restored in prolog's/epilogs 
and there is an ABI-defined ritual to get the global pointer reloaded to 
the correct value for the current image (note that loading a PC-relative 
address into the global pointer is not be valid in this ABI; as there 
may be multiple instances of a program running in the same address space 
each with their own unique global pointers).

However, saving/restoring and reloading the global pointer once in a 
function, is cheaper than accessing global variables indirectly via the GOT.

....


Granted:
There is a drawback that with my ABI, in that it can't implicitly share 
functions or variables across DLL boundaries.


Can also note that on x86-64, despite MSVC having similar behavior. and 
GCC using PIE on x86-64 in WSL that works in a similar way to PIE on 
RV64, the programs built as PIE on x86-64 are faster than those built 
via MSVC.

Granted, it is possible that x86-64 can hide a lot of the penalties from 
PIE via modern x86-64 CPUs almost universally being OoO (only real 
exceptions I am aware of being the early Atom cores, and early versions 
of the Xeon Phi).

....