This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: How big (and fast) is going to be GCC 8?
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: Martin Liška <mliska at suse dot cz>, GCC Development <gcc at gcc dot gnu dot org>, Michael Matz <matz at suse dot de>
- Date: Tue, 6 Mar 2018 15:59:12 +0100
- Subject: Re: How big (and fast) is going to be GCC 8?
- Authentication-results: sourceware.org; auth=none
- References: <5ec1f1c1-e0f6-5681-b6c6-cf8b076bc02a@suse.cz> <CAFiYyc3HhFO41Ew+BycYAp2b5TBcWgJsPfLVsvqjV_0qsv_Eyg@mail.gmail.com>
> On Tue, Mar 6, 2018 at 11:12 AM, Martin Liška <mliska@suse.cz> wrote:
> > Hello.
> >
> > Many significant changes has landed in mainline and will be released as GCC 8.1.
> > I decided to use various GCC configs we have and test how there configuration differ
> > in size and also binary size.
> >
> > This is first part where I measured binary size, speed comparison will follow.
> > Configuration names should be self-explaining, the 'system-*' is built done
> > without bootstrap with my system compiler (GCC 7.3.0). All builds are done
> > on my Intel Haswell machine.
>
> So from the numbers I see that bootstrap causes a 8% bigger binary compared
> to non-bootstrap using GCC 7.3 at -O2 when including debug info and 1.2%
> larger stripped. That means trunk generates larger code.
It is bit odd indeed because size stats from specs seems to imply otherwise.
It would be nice to work that out. Also I am surprised that LTO increases text
size even for non-plugin build. I should not happen.
These issues are generally hard to debug though. I will try to take a look.
I will send similar stats for my firefox experiments. If you have scripts to collect
them, they would be welcome.
Thanks for looking into this!
Honza
>
> What is missing is a speed comparison of the various binaries -- you could
> try measuring this by doing a make all-gcc for a non-bootstrap config
> (so it uses -O2 -g and doesn't build target libs with the built compiler).
>
> Richard.
>
> > Feel free to reply if you need any explanation.
> > Martin