Path: ...!feeds.phibee-telecom.net!3.eu.feeder.erje.net!feeder.erje.net!newsfeed.bofh.team!paganini.bofh.team!not-for-mail
From: antispam@fricas.org (Waldek Hebisch)
Newsgroups: comp.lang.c
Subject: Re: Suggested method for returning a string from a C program?
Date: Thu, 27 Mar 2025 00:22:44 -0000 (UTC)
Organization: To protect and to server
Message-ID: <vs25oi$2pqb$1@paganini.bofh.team>
References: <vrd77d$3nvtf$2@dont-email.me>   <vrrs20$14vob$1@dont-email.me> <vrrvnh$176lu$1@dont-email.me> <vrs0j5$191gt$1@dont-email.me> <vrs2eu$176lu$2@dont-email.me> <vrs2r3$1b0ov$1@dont-email.me> <vrs7oi$1e2j7$1@dont-email.me> <vrtq62$2unrb$1@dont-email.me> <vru2t0$35frt$2@dont-email.me> <vrufju$3i02s$1@dont-email.me> <vrugmo$3ij4s$2@dont-email.me> <vrugut$3j3ah$1@dont-email.me> <vruma5$3mvbj$2@dont-email.me> <vs0gsh$1en04$1@dont-email.me> <20250326110011.634@kylheku.com>
Injection-Date: Thu, 27 Mar 2025 00:22:44 -0000 (UTC)
Injection-Info: paganini.bofh.team; logging-data="91979"; posting-host="WwiNTD3IIceGeoS5hCc4+A.user.paganini.bofh.team"; mail-complaints-to="usenet@bofh.team"; posting-account="9dIQLXBM7WM9KzA+yjdR4A";
User-Agent: tin/2.6.2-20221225 ("Pittyvaich") (Linux/6.1.0-9-amd64 (x86_64))
X-Notice: Filtered by postfilter v. 0.9.3
Bytes: 3706
Lines: 49

Kaz Kylheku <643-408-1753@kylheku.com> wrote:
> On 2025-03-26, Muttley@DastardlyHQ.org <Muttley@DastardlyHQ.org> wrote:
>> Whats this? You mean your amazing zippy fast compiler can't optimise for shit?
>> Maybe gcc isn't so bad after all eh?
> 
> Ah, but:
> 
> 
> - gcc doesn't produce better code than it did 25 years go, when it
>   was at least an order of magnitude smaller and two orders faster.
>   At least not for tightly written programs where the C programmer
>   has done optimizing at the source level, so that the compiler has
>   little more to think about beyond good instruction selection and
>   cleaning up the pessimizations it has itself introduced.

No, gcc produces better code.  Both 25 years ago and now one
can find situations where gcc output could be improved by
rather simple transformations, but it is less frequent now.
Concerning "optimizing at the source level", modern machines
have instructions that can not be directly expressed at
source level, but which can speed up resulting programs.
In particular vector instructions.  Modern gcc is smart enough
to realize that code using separate scalar variables perform
some (not all!) operations in parallel and use vector
instructions.

How much improvement?  Probably in 5-15% range on average
programs for hand-optimized programs.

Concerning size, you are right, there is significant increase in
size.  Concerning speed, that is debatable.  On the same machine
the same somewhat silly file containing just declarations needs
9.894s using gcc-12.2 and 10.668s using gcc-3.4.6.  Different
silly example containg trivial code needs 27.947s using gcc-12.2
and 12.627s using gcc-3.4.6.  Both were at default setting
(no optimization).   As you see, depending on content of the
file gcc-12.2 can be slightly faster or few times slower than
gcc-3.4.6 when doing non-optimizing compilation.

Modern gcc can do whole-program optimization, which can take
a lot more time than function-by-function optimization done
by gcc-3.4.6.  But IME on realistic programs (in particular
split into moderately sized files) optimization increases
time, but that is few times, both for gcc-12.2 and for
older versions.  In other words, typically optimization
does not lead to catastrophic increase in compile time,
both for modern and old gcc.

-- 
                              Waldek Hebisch