Path: ...!2.eu.feeder.erje.net!feeder.erje.net!news.swapon.de!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: bart <bc@freeuk.com>
Newsgroups: comp.lang.c
Subject: Re: Baby X is bor nagain
Date: Tue, 25 Jun 2024 15:56:22 +0100
Organization: A noiseless patient Spider
Lines: 55
Message-ID: <v5elql$1jmii$1@dont-email.me>
References: <v494f9$von8$1@dont-email.me> <v4q2rl$sqk3$1@dont-email.me>
 <v52308$2nli8$3@dont-email.me> <v53i4s$33k73$2@dont-email.me>
 <v53lf7$34huc$1@dont-email.me> <v53vh6$368vf$1@dont-email.me>
 <v54se1$3bqsk$1@dont-email.me> <20240624160941.0000646a@yahoo.com>
 <v5bu5r$va3a$1@dont-email.me> <20240624181006.00003b94@yahoo.com>
 <v5c86d$11ac7$1@dont-email.me> <JEheO.108086$ED9b.74955@fx11.iad>
 <v5cblg$11q0j$1@dont-email.me> <gEieO.108089$ED9b.25598@fx11.iad>
 <20240625113616.000075e0@yahoo.com> <mUzeO.141609$Cqra.55051@fx10.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 25 Jun 2024 16:56:22 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="1ed6e99a33e78a2b7dfe692945895dda";
	logging-data="1694290"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18UDzjigKMyEhvhvKjyuhz0"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:kTKoHuaqNsf5f8XDU2MtEn7ee0U=
In-Reply-To: <mUzeO.141609$Cqra.55051@fx10.iad>
Content-Language: en-GB
Bytes: 3811

On 25/06/2024 14:48, Scott Lurndal wrote:
> Michael S <already5chosen@yahoo.com> writes:
>> On Mon, 24 Jun 2024 18:10:20 GMT
>> scott@slp53.sl.home (Scott Lurndal) wrote:
>>
> 
>>>> Well, what metric IS interesting?
>>>>
>>>> You seem to not care whether an executable is 10KB, 10MB, or 10GB.
>>>> You really don't think there's correspondence with build-time?
>>>
>>> No.  The ELF file contains a lot of stuff that never gets
>>> loaded into memory (symbol tables, DWARF section data, etc);
>>> writing to the object files by the compiler is an insignificant
>>> component of the overall compile time.
>>>
>>> Build time is not related in any way to the size of the
>>> ELF.
>>>
>>
>> That's why in my original post in this sub-thread, in order to give
>> a feeling of the size of compiler's job I gave the size of text
>> segment rather than size of the elf.
>> The size of text segment is, of course, not a good measure of
>> compiler's job, esp. when we are trying to compare compile jobs for
>> different target architectures, but it is less bad than any alternative
>> measure [that is not too hard to gather] that I can think of.
>> If you can think about anything better, please tell us.
> 
> Does the compiled code meet functional and performance  specifications?
> 
> That's the only criteria that matters.  Size of the executable
> and compilation speed are basically irrelevent metrics in my
> experience.

If apparently anything goes, and you don't care how slow a tool is or 
how big its output, how do you detect unnecessary bloat?

How do you detect gratuitous use of machine resources?

BTW since you and DB are both keen on products like Python, I'm curious 
as to how you reconcile the fast, streamlined bytecode compilers within 
such languages, which do no analysis and no optimising, with the 
heavyweight, 'professional' compilers used for translating C code.

Why is fast, TCC-like translation a terrible idea for C code and makes 
it a 'toy' compiler, but perfectly fine for Python code? Bear in mind 
that the worst TCC code will be a magnitude faster than any Python code, 
if it is the speed of the output that you are concerned with.

(It's lucky that the people behind gcc didn't write CPython's bytecode 
compiler!)