From: Mike Frysinger <vapier@gentoo.org>
To: "R. Diez" <rdiezmail-newlib@yahoo.de>,
joel@rtems.org, Newlib <newlib@sourceware.org>,
Matthew Joyce <matthew.joyce@embedded-brains.de>
Subject: Re: Question about autoreconf to regenerate configuration files
Date: Thu, 17 Feb 2022 00:18:30 -0500 [thread overview]
Message-ID: <Yg3apoTMTMojanx/@vapier> (raw)
In-Reply-To: <YfEcPccYyuXIO+zF@vapier>
[-- Attachment #1: Type: text/plain, Size: 2961 bytes --]
On 26 Jan 2022 05:02, Mike Frysinger wrote:
> On 21 Jan 2022 17:09, Mike Frysinger wrote:
> > On 21 Jan 2022 17:09, R. Diez via Newlib wrote:
> > > > [...]
> > > > The bootstrap time was large enough to
> > > > negatively impact our ability to do automated regression testing.
> > >
> > > A very long bootstrap time could be an issue.
> > >
> > > However, compilation time normally outweighs by far the Autotools regeneration step. Is that a problem in Newlib at the moment?
> >
> > autotools (autoreconf really) doesn't run in parallel, so every subdir
> > with a configure script needs a separate serialized run of all the tools.
> > newlib has many many of these (arguably, too many).
> >
> > on my quad core 4.2GHz AMD that is otherwise idle ...
> >
> > $ time (cd newlib && autoreconf)
> > real 5m22.170s
> > user 3m13.709s
> > sys 0m12.332s
> >
> > $ time (cd libgloss && autoreconf)
> > real 1m41.754s
> > user 0m43.505s
> > sys 0m3.618s
> > <this errored out, not sure why, so it might normally take even longer :p>
> >
> > # Blackfin builds 8 copies (multilib) of newlib+libgloss by default.
> > $ time (cd build; ../configure --host=bfin-elf; make -j4)
> > real 1m40.950s
> > user 0m58.032s
> > sys 0m30.968s
>
> updated timings on my system after recent work to delete many configure scripts
> $ time (cd newlib && autoreconf)
> real 1m0.619s
> user 0m45.249s
> sys 0m1.535s
>
> $ time (cd libgloss && autoreconf -I$PWD -I$PWD/.. -I$PWD/../config)
> real 0m32.662s
> user 0m15.858s
> sys 0m1.205s
>
> $ time (cd build; ../configure --host=bfin-elf; make -j4)
> real 1m2.337s
> user 0m44.987s
> sys 0m26.708s
>
> so it's def better, but autotool generation still takes longer than actually
> compiling newlib+libgloss 8 times :).
things are looking up. with all my pending changes, we have 1 configure script
in newlib and no recursive makes.
$ time (cd newlib && autoreconf)
real 0m8.740s
user 0m7.524s
sys 0m0.193s
i'm not sure if i'll "finish" libgloss. there's still a lot of subdirs not
even using automake, so while i can kill most configure scripts, i prob won't
do them all, and i prob won't convert more to automake or non-recursive make.
the libgloss arches have a lot harrier logic in them that i don't care to try
to unpack, especially since i converted the dirs i most care about.
$ time (cd libgloss && autoreconf -I$PWD -I$PWD/.. -I$PWD/../config)
real 0m8.313s
user 0m5.015s
sys 0m0.259s
we can see that killing excessive configure scripts & recursive makes helps
with compilation times too.
$ time (cd build; ../configure --host=bfin-elf; make -j4)
real 0m28.831s
user 0m34.828s
sys 0m23.093s
generating autotools is now slightly faster that compiling 8 copies of
newlib+libgloss :). not that i'm advocating for changing anything :P.
-mike
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2022-02-17 5:18 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-21 12:32 Matthew Joyce
2022-01-21 13:44 ` Corinna Vinschen
2022-01-21 15:02 ` R. Diez
2022-01-21 15:37 ` Joel Sherrill
2022-01-21 16:09 ` R. Diez
2022-01-21 22:09 ` Mike Frysinger
2022-01-21 23:08 ` Joel Sherrill
2022-01-22 21:20 ` R. Diez
2022-01-23 0:17 ` Joel Sherrill
2022-01-23 16:57 ` R. Diez
2022-01-26 10:19 ` Mike Frysinger
2022-01-30 22:22 ` R. Diez
2022-01-23 7:29 ` Mike Frysinger
2022-01-26 10:02 ` Mike Frysinger
2022-02-17 5:18 ` Mike Frysinger [this message]
2022-02-17 6:56 ` Sebastian Huber
2022-02-20 9:51 ` R. Diez
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Yg3apoTMTMojanx/@vapier \
--to=vapier@gentoo.org \
--cc=joel@rtems.org \
--cc=matthew.joyce@embedded-brains.de \
--cc=newlib@sourceware.org \
--cc=rdiezmail-newlib@yahoo.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).