Deutsch   English   Français   Italiano  
<vj9ph3$114ip$2@dont-email.me>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: question about linker
Date: Tue, 10 Dec 2024 17:16:35 +0100
Organization: A noiseless patient Spider
Lines: 69
Message-ID: <vj9ph3$114ip$2@dont-email.me>
References: <vi54e9$3ie0o$1@dont-email.me> <viifv8$2opi7$1@dont-email.me>
 <vik28b$390eg$1@dont-email.me> <vik8tc$3ang9$1@dont-email.me>
 <vikjff$3dgvc$1@dont-email.me> <viku00$3gamg$1@dont-email.me>
 <vil0qc$3fqqa$3@dont-email.me> <vil82t$3ie9o$2@dont-email.me>
 <vila9j$3j4dg$1@dont-email.me> <vin4su$49a6$1@dont-email.me>
 <vin95m$5da6$1@dont-email.me> <vinh3h$7ppb$1@dont-email.me>
 <vinjf8$8jur$1@dont-email.me> <vip5rf$p44n$1@dont-email.me>
 <viprao$umjj$1@dont-email.me> <viqfk9$13esp$1@dont-email.me>
 <vir5kp$3hjd9$1@paganini.bofh.team> <vishtd$1mnq1$1@dont-email.me>
 <visola$1ohbl$1@dont-email.me> <vivdb8$2foo6$1@dont-email.me>
 <viviqe$2gvqj$1@dont-email.me> <vj1rq0$35lal$2@dont-email.me>
 <vj9hag$vq6e$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 10 Dec 2024 17:16:36 +0100 (CET)
Injection-Info: dont-email.me; posting-host="11f1296d37219c7057c9275bccb41284";
	logging-data="1086041"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/Zo6fAgeEKkAl9lJMUxHGk1fE+nb0GseE="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:rLQuFBJrACU2MPSG2r2qGB/+sn4=
In-Reply-To: <vj9hag$vq6e$1@dont-email.me>
Content-Language: en-GB
Bytes: 4583

On 10/12/2024 14:56, bart wrote:
> On 07/12/2024 16:06, David Brown wrote:
>> On 06/12/2024 20:20, Bart wrote:
> 
>>> If your task to get from A to B was split into two, you'd be happy to 
>>> do the first part by a fast car, then complete the rest of it on a 
>>> horse and cart, for no reason at all?
>>>
>>
>> The comparison was between C to object code (with a real compiler) and 
>> from X to C and then to the object code (using a real compiler).  If 
>> your beliefs were true that gcc (and other proper C compilers) are 
>> incredibly slow, why would it make any difference if someone is 
>> starting from X or starting from C?  In both cases, compilation would 
>> take a long time - C compilation speed is neither more nor less 
>> important whether you are programming in X or C.
> 
> You don't appear to get it.

No, /you/ don't get it.  I did not say that people using language X 
don't care about the speed of C compilation.  I said it doesn't matter 
any more or any less than for people writing C.

> If you are writing C by hand, then people 
> like you would want to use a more powerful, and therefore slower, 
> compiler, that will analyse that C. It can also take care of the many 
> shortcomings in the language.
> 
> But if the C has been machine-generated, that analysis is no longer 
> relevant. Then you may just want the fastest and simplest conversion.
> 

As I said before, the analysis is needed for good optimisation - 
generating static error checking takes very little extra time when you 
are optimising.  And often people using C as an intermediary language 
want optimisation of the C code.

But maybe sometimes they don't, and maybe they want to prioritise the 
fastest practical compilation speed.  Then if a smaller tool is faster 
while still being good enough, then it's a benefit to be smaller and/or 
faster.

The key issue, however, is "good enough".  No one would want to use a C 
compiler that is small and fast if they are not confident that it 
generates correct results, or if it does not target their processor or 
OS, or does not cope with the third-party libraries and code that they 
want to include.


> This was the basis of my use-case for a fast and possibly compact compiler.
> 
> 
>> And you are the only one so far who finds gcc to be inconveniently slow.
> 

Okay, to be more accurate, you are the only one /here/ who has said they 
find compilation of /C/ (not C++) to be /problematically/ slow using gcc 
or clang.

Is that better?


No one has ever denied that they'd be happier if their compiler ran 
faster - what people don't, for the most part, want to do is swap their 
top-shelf compiler with an inferior one simply because it runs faster. 
(And they even more rarely care about the size on the disk.)