Path: ...!weretis.net!feeder8.news.weretis.net!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: Mon, 24 Jun 2024 18:10:06 +0300
Organization: A noiseless patient Spider
Lines: 211
Message-ID: <20240624181006.00003b94@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Injection-Date: Mon, 24 Jun 2024 17:09:49 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="a033234f5eaff00d281aad432da64e4a";
	logging-data="1051166"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/CGEKInEcD72OfIXMO56I/PeEjGUEZcFE="
Cancel-Lock: sha1:uVOs8WxFhUmowbHd8fHk676+M68=
X-Newsreader: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-w64-mingw32)
Bytes: 10562

On Mon, 24 Jun 2024 15:00:26 +0100
bart <bc@freeuk.com> wrote:

> On 24/06/2024 14:09, Michael S wrote:
> > 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.=C2=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.=C2=A0 But I said it was not noticeable - it does not make
> >>> enough difference in speed for it to be worth choosing.
> >>>     =20
> >>>>    =20
> >>>>  =C2=A0=C2=A0C:\c>tm gcc bignum.c -shared -s -obignum.dll=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 # from
> >>>> 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
> >>>>  =C2=A0=C2=A0C:\c>tm gcc bignum.c -shared -s -obignum.dll =20
> >>>>  =C2=A0=C2=A0TM: 0.31
> >>>>    =20
> >>>>  =C2=A0=C2=A0C:\c>tm gcc bignum.c -shared -s -obignum.dll -O2 =20
> >>>>  =C2=A0=C2=A0TM: 0.83
> >>>>    =20
> >>>>  =C2=A0=C2=A0C:\c>tm gcc bignum.c -shared -s -obignum.dll -O3 =20
> >>>>  =C2=A0=C2=A0TM: 0.93
> >>>>    =20
> >>>>  =C2=A0=C2=A0C:\c>dir bignum.dll =20
> >>>>  =C2=A0=C2=A021/06/2024=C2=A0 11:14=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=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.=C2=A0 It has 158 C fil=
es
> >>> and about 220 header files.=C2=A0 And I ran it on my old PC, without
> >>> any "tricks" that you dislike so much, doing full clean
> >>> re-builds.=C2=A0 The files are actually all compiled twice, building
> >>> two variants of the binary.
> >>>
> >>> With -O2, it took 34.3 seconds to build.=C2=A0 With -O1, it took 33.4
> >>> seconds.=C2=A0 With -O0, it took 30.8 seconds.
> >>>
> >>> So that is a 15% difference for full builds.=C2=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.
>

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.


> However, is there any way of isolating the compilation time (turning
> .c files into either or .o files) from 'make' the linker? Failing
> that, can you compile just one module in isolation (.c to .o) with
> -O0 and -O2, or is that not possible?
>

Of course, there is a way. But it's more work and gives an answer I am
not interested to know. Here are fully agree with what David said few
posts below.

> Those throughputs don't look that impressive for a parallel build on=20
> what sounds like a high-spec machine.
>

Yes, not that impressive.
However I wouldn't call the machine high-spec. More precisely, when
originally bought almost decade ago it was high-spec (but not top-spec)
machine for FPGA development. FPGA development tools even today are not
so good at parallelization of their jobs. 10 years ago parallelization
gain above 2 cores was non-existing. Also, data access patterns of this
tools tend to have poor locality of reference. It means that big L3
cache has limited usefulness. On the other hand, low-latency main
memory is very useful. This specific machine is bought with this
constraints in mind - high [for 2014] single-thread performance,
relatively small 8MB L3 cache, small [for multi-user server] 32 GB
low-latency main memory built of unbuffered DIMMs rather than of more
typical for server registered DIMMs.
People that care about parallel software builds buy quit different sort
of servers - dual-socket, lots of cores, big last level cache, big main
memory with high throughput and high latency. Back in the second half of
2014 those of them that had bigger budgets bought Xeon E5-2697 v2; those
with smaller budgets preferred Xeon E5-2697 v2. Those with good
contacts were getting Xeon E5 v3 that was already lounched but not
available for everyone.

> Your processor has a CPU-mark double that of mine, which has only two=20
> cores, and is using one.
>=20
> Building a 34-module project with .text size of 300KB, with either
> gcc 10 or 14, using -O0, takes about 8 seconds, or 37KB/second.
>

But my project has much more than 34 modules. 164 modules compiled
during build + several dozens in libraries.

> Your figures show about 50KB/second.
========== REMAINDER OF ARTICLE TRUNCATED ==========