Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
Newsgroups: comp.lang.c
Subject: Re: Baby X is bor nagain
Date: Fri, 28 Jun 2024 19:39:00 +0300
Organization: A noiseless patient Spider
Lines: 140
Message-ID: <20240628193900.00005eb9@yahoo.com>
References: <v494f9$von8$1@dont-email.me>
	<v49seg$14cva$1@raubtier-asyl.eternal-september.org>
	<v49t6f$14i1o$1@dont-email.me>
	<v4bcbj$1gqlo$1@raubtier-asyl.eternal-september.org>
	<v4bh56$1hibd$1@dont-email.me>
	<v4c0mg$1kjmk$1@dont-email.me>
	<v4c8s4$1lki1$4@dont-email.me>
	<20240613002933.000075c5@yahoo.com>
	<v4emki$28d1b$1@dont-email.me>
	<20240613174354.00005498@yahoo.com>
	<v4okn9$flpo$2@dont-email.me>
	<v4p37r$k32n$1@dont-email.me>
	<v4pei3$m5th$2@dont-email.me>
	<v4plsk$nn9o$2@dont-email.me>
	<v4pnq6$o4fs$1@dont-email.me>
	<v4q245$si2n$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>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Injection-Date: Fri, 28 Jun 2024 18:39:07 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="d6825ee2551f7bb84af33e960827b374";
	logging-data="3538577"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18Yu7d1d4iTkwR0r868xm7TXRxz3iCZ2Uw="
Cancel-Lock: sha1:rpLPvWRRETwS55hiZFMGtYTSnRY=
X-Newsreader: Claws Mail 4.1.1 (GTK 3.24.34; x86_64-w64-mingw32)
Bytes: 7876

On Mon, 24 Jun 2024 18:10:06 +0300
Michael S <already5chosen@yahoo.com> wrote:

> On Mon, 24 Jun 2024 15:00:26 +0100
> bart <bc@freeuk.com> wrote:
>=20
> > On 24/06/2024 14:09, Michael S wrote: =20
> > > On Fri, 21 Jun 2024 22:47:46 +0100
> > > bart <bc@freeuk.com> wrote:
> > >    =20
> > >> On 21/06/2024 14:34, David Brown wrote:   =20
> > >>> On 21/06/2024 12:42, bart wrote:   =20
> > >>>> On 21/06/2024 10:46, David Brown wrote:   =20
> > >>>>>
> > >>>>>
> > >>>>> I understand your viewpoint and motivation.=A0 But my own
> > >>>>> experience is mostly different.
> > >>>>>
> > >>>>> First, to get it out of the way, there's the speed of
> > >>>>> compilation. While heavy optimisation (-O3) can take
> > >>>>> noticeably longer, I never see -O0 as being in any noticeable
> > >>>>> way faster for compilation than -O1 or even -O2.   =20
> > >>>>
> > >>>> Absolute time or relative?   =20
> > >>>
> > >>> Both.
> > >>>       =20
> > >>>> For me, optimised options with gcc always take longer:   =20
> > >>>
> > >>> Of course.=A0 But I said it was not noticeable - it does not make
> > >>> enough difference in speed for it to be worth choosing.
> > >>>       =20
> > >>>>      =20
> > >>>>  =A0=A0C:\c>tm gcc bignum.c -shared -s -obignum.dll=A0=A0=A0=A0=A0=
=A0=A0 # from =20
> > >>>> cold TM: 3.85   =20
> > >>>
> > >>> Cold build times are irrelevant to development - when you are
> > >>> working on a project, all the source files and all your compiler
> > >>> files are in the PC's cache.
> > >>>
> > >>>       =20
> > >>>>      =20
> > >>>>  =A0=A0C:\c>tm gcc bignum.c -shared -s -obignum.dll   =20
> > >>>>  =A0=A0TM: 0.31
> > >>>>      =20
> > >>>>  =A0=A0C:\c>tm gcc bignum.c -shared -s -obignum.dll -O2   =20
> > >>>>  =A0=A0TM: 0.83
> > >>>>      =20
> > >>>>  =A0=A0C:\c>tm gcc bignum.c -shared -s -obignum.dll -O3   =20
> > >>>>  =A0=A0TM: 0.93
> > >>>>      =20
> > >>>>  =A0=A0C:\c>dir bignum.dll   =20
> > >>>>  =A0=A021/06/2024=A0 11:14=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 35,840=
 bignum.dll   =20
> > >>>
> > >>> Any build time under a second is as good as instant.
> > >>>
> > >>> I tested on a real project, not a single file.=A0 It has 158 C
> > >>> files and about 220 header files.=A0 And I ran it on my old PC,
> > >>> without any "tricks" that you dislike so much, doing full clean
> > >>> re-builds.=A0 The files are actually all compiled twice, building
> > >>> two variants of the binary.
> > >>>
> > >>> With -O2, it took 34.3 seconds to build.=A0 With -O1, it took 33.4
> > >>> seconds.=A0 With -O0, it took 30.8 seconds.
> > >>>
> > >>> So that is a 15% difference for full builds.=A0 In practice, of
> > >>> course, full rebuilds are rarely needed, and most builds after
> > >>> changes to the source are within a second or so.   =20
> > >>
> > >> Then there's something very peculiar about your codebase.
> > >>   =20
> > >=20
> > >=20
> > > To me it looks more likely that your codebase is very unusual
> > > rather than David's
> > >=20
> > > In order to get meaningful measurements I took embedded project
> > > that is significantly bigger than average by my standards. Here
> > > are times of full parallel rebuild (make -j5) on relatively old
> > > computer (4-core Xeon E3-1271 v3).
> > >=20
> > > Option time(s) -g time text size
> > > -O0    13.1      13.3   631648
> > > -Os    13.6      14.1   424016
> > > -O1    13.5      13.7   455728
> > > -O2    14.0      14.1   450056
> > > -O3    14.0      14.6   525380
> > >=20
> > > The difference in time between different -O settings in my
> > > measurements is even smaller than reported by David Brown. That
> > > can be attributed to older compiler (gcc 4.1.2). Another
> > > difference is that this compiler works under cygwin, which is
> > > significantly slower both than native Linux and than native
> > > Windows. That causes relatively higher make overhead and longer
> > > link.   =20
> >=20
> > I don't know why Cygwin would make much difference; the native code
> > is still running on the same processor.
> > =20
>=20
> I don't know specific reasons. Bird's eye perspective is that cygwin
> tries to emulate Posix semantics on platform that is not Posix and
> achieves that by using few low-granularity semaphores in user space,
> which seriously limits parallelism. Besides, there are problems with
> emulation of Posix I/O semantics that cause cygwin file I/O to be 2-3
> times slower that native Windows I/O. The later applies mostly to
> relatively small files, but, then again, software build mostly
> accesses small files.
> As a matter of fact, a parallel speed up I see on this project on this
> quad-core machine is barely 2x. I expect 3x or a little more for the
> same project with native Windows tools.
>
>

Further investigation proved that cygwin is not at fault.
The slowness and poor scalability of the build process on this computer
was caused by computer virus that our IT department mistakenly calls
antivirus.
When I run more then 1 compilation job in parallel, the virus, which
appears to be strictly single-threaded, become a main bottleneck. When
I run more than 2 compilation job in parallel, it become a sole
bottleneck.
The impact is not specific to gcc - virus hates all compilers in
existence, both cross and native indiscriminately. However gcc is
impacted much worse tha, for example, MSVC. I'd guess that the main
difference between the two is that gcc compilation is two-stage -
generation of asm and assembling, while MSVC compilation is a single
stage.
Of course, with virus in action, the difference between gcc -O0 and
-O2 is lost in noise.

However, when I repeated an experiment on virus-free computer (my own
old home PC) the difference between -O0 and -O2 was still smaller than
your reports - approximately 1.8x on average when link time excluded.
But in this case the code base was less of representative of "real"
project. The truth is - I have no "real" projects in C that are not
embedded.