How big (and fast) is going to be GCC 8?

How big (and fast) is going to be GCC 8?

[Martin Liška]

[-- Attachment #1: Type: text/plain, Size: 520 bytes --]

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.

Feel free to reply if you need any explanation.
Martin

[-- Attachment #2: gcc-8-build-stats.ods --]
[-- Type: application/vnd.oasis.opendocument.spreadsheet, Size: 24473 bytes --]

[-- Attachment #3: gcc-8-build-stats.pdf.bz2 --]
[-- Type: application/x-bzip, Size: 21081 bytes --]

Re: How big (and fast) is going to be GCC 8?

[David Malcolm]

On Tue, 2018-03-06 at 11:14 +0100, Martin Liška 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.
> 
> Feel free to reply if you need any explanation.
> Martin

Some possibly silly questions:

(a) was this done with:
  --enable-checking=release ?

(b) is this measuring cc1 ?

(c) are the units bytes?  (so ~183MB for the unstripped system-O2-
native cc1, ~25MB after stripping?)

(d) do you have comparable data for gcc 7?

Thanks
Dave

Re: How big (and fast) is going to be GCC 8?

[Martin Liška]

On 03/06/2018 04:13 PM, David Malcolm wrote:
> On Tue, 2018-03-06 at 11:14 +0100, Martin Liška 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.
>>
>> Feel free to reply if you need any explanation.
>> Martin
> 
> Some possibly silly questions:

Hi David.

All of them are qualified!

> 
> (a) was this done with:
>    --enable-checking=release ?

Yes.

> 
> (b) is this measuring cc1 ?

cc1plus. Let me also add cc1 when I'll have run-time numbers.

> 
> (c) are the units bytes?  (so ~183MB for the unstripped system-O2-
> native cc1, ~25MB after stripping?)

Yes, in bytes. Would be nicer to have it in MB ;) It would be easily
readable. I'll fix that.

> 
> (d) do you have comparable data for gcc 7?

Will build corresponding builds for GCC 7 tonight.

Martin

> 
> Thanks
> Dave
> 

Re: How big (and fast) is going to be GCC 8?

[Martin Liška]

[-- Attachment #1: Type: text/plain, Size: 285 bytes --]

On 03/06/2018 05:18 PM, Martin Liška wrote:
> Yes, in bytes. Would be nicer to have it in MB ;) It would be easily
> readable. I'll fix that.

Hi.

I'm sending updated binary size statistics for both cc1 and cc1plus
in MB.

Martin

[-- Attachment #2: gcc-8-build-stats-v2.pdf.bz2 --]
[-- Type: application/x-bzip, Size: 27525 bytes --]

[-- Attachment #3: gcc-8-build-stats-v2.ods --]
[-- Type: application/vnd.oasis.opendocument.spreadsheet, Size: 25633 bytes --]

Re: How big (and fast) is going to be GCC 8? [part 2]

[Martin Liška]

[-- Attachment #1: Type: text/plain, Size: 326 bytes --]

Hi.

This is speed comparison of GCC 8 builds compared to my system GCC 7.3.0
which is built with PGO bootstrap.

I run empty C and C++ source file, tramp3d and the rest are some big beasts
from GCC source file. Feel free to suggest another test candidates? Note
that first column defines how many times was test run.

Martin

[-- Attachment #2: gcc-8-perf-stats.pdf.bz2 --]
[-- Type: application/x-bzip, Size: 24793 bytes --]

[-- Attachment #3: gcc-8-perf-stats.ods --]
[-- Type: application/vnd.oasis.opendocument.spreadsheet, Size: 24141 bytes --]

Re: How big (and fast) is going to be GCC 8? [part 2]

[Bin.Cheng]

On Tue, Mar 6, 2018 at 5:50 PM, Martin Liška <mliska@suse.cz> wrote:
> Hi.
>
> This is speed comparison of GCC 8 builds compared to my system GCC 7.3.0
> which is built with PGO bootstrap.
>
> I run empty C and C++ source file, tramp3d and the rest are some big beasts
> from GCC source file. Feel free to suggest another test candidates? Note
> that first column defines how many times was test run.
First thanks very much for collecting the data.
Since we enabled several loop passes at O3 and above levels, some data
for Ofast might be interesting?

Thanks,
bin
>
> Martin

Re: How big (and fast) is going to be GCC 8? [part 2]

[Martin Liška]

On 03/06/2018 07:16 PM, Bin.Cheng wrote:
> On Tue, Mar 6, 2018 at 5:50 PM, Martin Liška <mliska@suse.cz> wrote:
>> Hi.
>>
>> This is speed comparison of GCC 8 builds compared to my system GCC 7.3.0
>> which is built with PGO bootstrap.
>>
>> I run empty C and C++ source file, tramp3d and the rest are some big beasts
>> from GCC source file. Feel free to suggest another test candidates? Note
>> that first column defines how many times was test run.
> First thanks very much for collecting the data.
> Since we enabled several loop passes at O3 and above levels, some data
> for Ofast might be interesting?

Do you have a nice source file full of loop nests that would test that
properly?

Martin

> 
> Thanks,
> bin
>>
>> Martin

Re: Size and speed comparison of GCC 7 & 8

[Martin Liška]

[-- Attachment #1: Type: text/plain, Size: 172 bytes --]

Hi.

Now I have also numbers for GCC 7, so the attached PDF and Calc file contain
all numbers I have. Looks we've got both speed and size limits compared to GCC 7.

Martin

[-- Attachment #2: gcc-build-stats-all-in-one.ods --]
[-- Type: application/vnd.oasis.opendocument.spreadsheet, Size: 53989 bytes --]

[-- Attachment #3: gcc-build-stats-all-in-one.pdf.bz2 --]
[-- Type: application/x-bzip, Size: 80048 bytes --]

Re: Size and speed comparison of GCC 7 & 8

[Martin Liška]

[-- Attachment #1: Type: text/plain, Size: 56 bytes --]

V2: fixed headers in the last table of the PDF.

Martin

[-- Attachment #2: gcc-build-stats-all-in-one.pdf.bz2 --]
[-- Type: application/x-bzip, Size: 80057 bytes --]

[-- Attachment #3: gcc-build-stats-all-in-one.ods --]
[-- Type: application/vnd.oasis.opendocument.spreadsheet, Size: 54043 bytes --]

Re: Size and speed comparison of GCC 7 & 8

[Martin Liška]

On 03/07/2018 11:13 AM, Martin Liška wrote:
> V2: fixed headers in the last table of the PDF.
> 
> Martin
> 

About the i386.ii -O2 -g, there's perf diff in between GCC 7 (base) and GCC 8:

# Baseline  Delta Abs  Shared Object         Symbol                                                                                                                                                                                                                        
# ........  .........  ....................  ..............................................................................................................................................................................................................................
#
               +0.65%  cc1plus               [.] hash_table<hash_map<int_hash<int, 0, -1>, ipa_call_summary*, simple_hashmap_traits<default_hash_traits<int_hash<int, 0, -1> >, ipa_call_summary*> >::hash_entry, xcallocator>::find_slot_with_hash
     0.18%     +0.43%  cc1plus               [.] sreal::operator*
               +0.41%  cc1plus               [.] hash_table<hash_map<int_hash<int, 0, -1>, ipa_fn_summary*, simple_hashmap_traits<default_hash_traits<int_hash<int, 0, -1> >, ipa_fn_summary*> >::hash_entry, xcallocator>::find_slot_with_hash
     0.07%     +0.35%  cc1plus               [.] cgraph_node::find_replacement
               +0.33%  cc1plus               [.] profile_count::to_sreal_scale
               +0.33%  cc1plus               [.] predicate::probability
               +0.27%  cc1plus               [.] call_summary<ipa_call_summary*>::get
     0.04%     +0.25%  cc1plus               [.] sreal::operator/
               +0.24%  cc1plus               [.] sreal::normalize
     0.70%     -0.23%  [kernel]              [.] 0xffffffff9c80019f
               +0.23%  cc1plus               [.] wide_int_to_tree_1
     0.09%     +0.22%  cc1plus               [.] sreal::operator+
               +0.21%  cc1plus               [.] analyze_function_body
     0.04%     +0.19%  cc1plus               [.] dwarf2out_var_location
     0.19%     -0.19%  cc1plus               [.] compute_inlined_call_time
               +0.19%  cc1plus               [.] function_summary<ipa_fn_summary*>::get
     0.30%     -0.18%  cc1plus               [.] can_inline_edge_p
     1.91%     -0.16%  cc1plus               [.] bitmap_set_bit
     0.74%     -0.15%  cc1plus               [.] pre_and_rev_post_order_compute_fn
     0.80%     +0.15%  [unknown]             [.] 0xffffffff9c80019f
               +0.14%  cc1plus               [.] cleanup_control_flow_pre
     0.81%     -0.14%  cc1plus               [.] ggc_set_mark
     0.13%     +0.13%  cc1plus               [.] variably_modified_type_p
     0.81%     -0.13%  cc1plus               [.] et_splay
     0.17%     -0.13%  cc1plus               [.] curr_insn_transform
               +0.12%  cc1plus               [.] profile_count::from_gcov_type
               +0.12%  cc1plus               [.] process_alt_operands
               +0.12%  cc1plus               [.] can_inline_edge_by_limits_p
     0.60%     -0.11%  cc1plus               [.] estimate_calls_size_and_time
     1.36%     -0.11%  libc-2.26.so          [.] _int_malloc
     0.27%     +0.11%  cc1plus               [.] constrain_operands
               +0.11%  cc1plus               [.] bitmap_alloc
     0.60%     +0.11%  cc1plus               [.] hash_table<variable_hasher, xcallocator>::find_slot_with_hash
               +0.11%  cc1plus               [.] predicate::evaluate
               +0.10%  cc1plus               [.] vr_values::get_value_range
     0.22%     -0.10%  cc1plus               [.] nonzero_bits1
     0.24%     +0.10%  cc1plus               [.] big_speedup_p
               +0.09%  cc1plus               [.] get_class_binding_direct
               +0.09%  cc1plus               [.] maybe_hot_count_p
     0.58%     -0.09%  cc1plus               [.] walk_tree_1
     0.06%     +0.09%  cc1plus               [.] estimate_size_after_inlining
               +0.09%  cc1plus               [.] mark_use
               +0.09%  cc1plus               [.] ix86_hard_regno_call_part_clobbered
     0.59%     -0.09%  cc1plus               [.] bitmap_bit_p
     0.23%     -0.09%  cc1plus               [.] delete_trivially_dead_insns
     0.41%     -0.09%  cc1plus               [.] cse_insn
     0.47%     -0.09%  cc1plus               [.] (anonymous namespace)::dom_info::calc_idoms
               +0.08%  cc1plus               [.] hash_table<named_decl_hash, xcallocator>::find_slot_with_hash
               +0.08%  cc1plus               [.] profile_count::to_frequency
     0.28%     -0.08%  libc-2.26.so          [.] msort_with_tmp.part.0
     0.90%     -0.08%  libc-2.26.so          [.] _int_free
               +0.08%  cc1plus               [.] substitute_and_fold_engine::replace_uses_in
     0.20%     -0.08%  cc1plus               [.] rtx_equal_for_memref_p
               +0.08%  cc1plus               [.] predicate::add_clause
     0.18%     -0.07%  cc1plus               [.] update_callee_keys
     0.67%     -0.07%  cc1plus               [.] gt_ggc_mx_lang_tree_node

Martin

Re: Size and speed comparison of GCC 7 & 8

[Martin Liška]

[-- Attachment #1: Type: text/plain, Size: 190 bytes --]

On 03/07/2018 11:13 AM, Martin Liška wrote:
> V2: fixed headers in the last table of the PDF.
> 
> Martin
> 

Hi.

V3: added kdecore library source file provided by Michael Matz.

Martin

[-- Attachment #2: gcc-build-stats-all-in-one.ods --]
[-- Type: application/vnd.oasis.opendocument.spreadsheet, Size: 57583 bytes --]

[-- Attachment #3: gcc-build-stats-all-in-one.pdf.bz2 --]
[-- Type: application/x-bzip, Size: 81619 bytes --]

How can compiler speed-up postgresql database?

[Martin Liška]

[-- Attachment #1: Type: text/plain, Size: 130 bytes --]

Hi.

I did similar stats for postgresql server, more precisely for pgbench:
pgbench -s100 & 10 runs of pgbench -t10000 -v

Martin

[-- Attachment #2: pgbench-gcc-test.pdf.bz2 --]
[-- Type: application/x-bzip, Size: 17078 bytes --]

[-- Attachment #3: pgbench-gcc-test.ods --]
[-- Type: application/vnd.oasis.opendocument.spreadsheet, Size: 14161 bytes --]

Re: How can compiler speed-up postgresql database?

[Richard Biener]

On Tue, Mar 20, 2018 at 8:57 PM, Martin Liška <mliska@suse.cz> wrote:
> Hi.
>
> I did similar stats for postgresql server, more precisely for pgbench:
> pgbench -s100 & 10 runs of pgbench -t10000 -v

Without looking at the benchmark probably only because it is flawed
(aka not I/O or memory bandwidth limited).  It might have some
actual operations on data (regex code?) that we can speed up though.

Richard.

> Martin

Re: How can compiler speed-up postgresql database?

[Martin Liška]

On 03/21/2018 10:26 AM, Richard Biener wrote:
> On Tue, Mar 20, 2018 at 8:57 PM, Martin Liška <mliska@suse.cz> wrote:
>> Hi.
>>
>> I did similar stats for postgresql server, more precisely for pgbench:
>> pgbench -s100 & 10 runs of pgbench -t10000 -v
> 
> Without looking at the benchmark probably only because it is flawed
> (aka not I/O or memory bandwidth limited).  It might have some
> actual operations on data (regex code?) that we can speed up though.

Well, it's not ideal as it tests quite simple DB with just couple of tables:
```
By default, pgbench tests a scenario that is loosely based on TPC-B, involving five SELECT, UPDATE, and INSERT commands per transaction.
```

Note that I had pg_data in /dev/shm and I verified that CPU utilization was 100% on a single core.
That said, it should not be so misleading ;)

Martin

> 
> Richard.
> 
>> Martin

Re: How can compiler speed-up postgresql database?

[Jan Hubicka]

> On 03/21/2018 10:26 AM, Richard Biener wrote:
> >On Tue, Mar 20, 2018 at 8:57 PM, Martin Liška <mliska@suse.cz> wrote:
> >>Hi.
> >>
> >>I did similar stats for postgresql server, more precisely for pgbench:
> >>pgbench -s100 & 10 runs of pgbench -t10000 -v
> >
> >Without looking at the benchmark probably only because it is flawed
> >(aka not I/O or memory bandwidth limited).  It might have some
> >actual operations on data (regex code?) that we can speed up though.
> 
> Well, it's not ideal as it tests quite simple DB with just couple of tables:
> ```
> By default, pgbench tests a scenario that is loosely based on TPC-B, involving five SELECT, UPDATE, and INSERT commands per transaction.
> ```
> 
> Note that I had pg_data in /dev/shm and I verified that CPU utilization was 100% on a single core.
> That said, it should not be so misleading ;)

Well, it is usually easy to do perf and look how hot spots looks like.
I see similar speedups for common page lading at firefox and similar benchmarks
that are quite good.  Not everything needs to be designed to be memory bound
like spec.

Honza
> 
> Martin
> 
> >
> >Richard.
> >
> >>Martin
> 

GCC 8 vs. GCC 9 speed and size comparison

[Martin Liška]

[-- Attachment #1: Type: text/plain, Size: 305 bytes --]

Hi.

There's a similar comparison that I did for the official openSUSE gcc packages.
gcc8 is built with PGO, while the gcc9 package is built in 2 different configurations:
PGO, LTO, PGO+LTO (LTO used for FE in stage4, for generators in stage3 as well).

Please take a look at attached statistics.

Martin

[-- Attachment #2: gcc8-gcc9-comparison.ods --]
[-- Type: application/vnd.oasis.opendocument.spreadsheet, Size: 17320 bytes --]

Re: GCC 8 vs. GCC 9 speed and size comparison

[Michael Matz]

[-- Attachment #1: Type: text/plain, Size: 682 bytes --]

Hi,

On Mon, 15 Apr 2019, Martin Liška wrote:

> There's a similar comparison that I did for the official openSUSE gcc 
> packages. gcc8 is built with PGO, while the gcc9 package is built in 2 
> different configurations: PGO, LTO, PGO+LTO (LTO used for FE in stage4, 
> for generators in stage3 as well).
> 
> Please take a look at attached statistics.

It seems the C++ parser got quite a bit slower with gcc 9 :-( Most visible 
in the compile time for tramp-3d (24%) and kdecore.cc (18% slower with 
just PGO); it seems that the other .ii files are C-like enough to not 
trigger this behaviour, so it's probably something to do with templates 
and/or classes.


Ciao,
Michael.

Re: GCC 8 vs. GCC 9 speed and size comparison

[Jan Hubicka]

> Hi,
> 
> On Mon, 15 Apr 2019, Martin Liška wrote:
> 
> > There's a similar comparison that I did for the official openSUSE gcc 
> > packages. gcc8 is built with PGO, while the gcc9 package is built in 2 
> > different configurations: PGO, LTO, PGO+LTO (LTO used for FE in stage4, 
> > for generators in stage3 as well).
> > 
> > Please take a look at attached statistics.
> 
> It seems the C++ parser got quite a bit slower with gcc 9 :-( Most visible 
> in the compile time for tramp-3d (24%) and kdecore.cc (18% slower with 
> just PGO); it seems that the other .ii files are C-like enough to not 
> trigger this behaviour, so it's probably something to do with templates 
> and/or classes.

Would be possible to have -ftime-report for your tramp3d build with
the four compilers?  It may be a consequence of training changes and
i.e. template instantiation code which is excercised by tramp3d a lot
more than by GCC bootstrap.
But it still seem bit too much for simple PGO divergence. It also
may be caused by changes of inliner decisions or some other pass being
overly active.

Honza
> 
> 
> Ciao,
> Michael.

Re: GCC 8 vs. GCC 9 speed and size comparison

[Jakub Jelinek]

On Mon, Apr 15, 2019 at 12:12:13PM +0000, Michael Matz wrote:
> Hi,
> 
> On Mon, 15 Apr 2019, Martin Liška wrote:
> 
> > There's a similar comparison that I did for the official openSUSE gcc 
> > packages. gcc8 is built with PGO, while the gcc9 package is built in 2 
> > different configurations: PGO, LTO, PGO+LTO (LTO used for FE in stage4, 
> > for generators in stage3 as well).
> > 
> > Please take a look at attached statistics.
> 
> It seems the C++ parser got quite a bit slower with gcc 9 :-( Most visible 
> in the compile time for tramp-3d (24%) and kdecore.cc (18% slower with 
> just PGO); it seems that the other .ii files are C-like enough to not 

Is that with the same libstdc++ headers (i.e. identical *.ii files) or with
the corresponding libstdc++ headers?  Those do change a lot every release as
well.

	Jakub

Re: GCC 8 vs. GCC 9 speed and size comparison

[Michael Matz]

Hi,

On Mon, 15 Apr 2019, Jakub Jelinek wrote:

> > It seems the C++ parser got quite a bit slower with gcc 9 :-( Most 
> > visible in the compile time for tramp-3d (24%) and kdecore.cc (18% 
> > slower with just PGO); it seems that the other .ii files are C-like 
> > enough to not
> 
> Is that with the same libstdc++ headers (i.e. identical *.ii files) or 
> with the corresponding libstdc++ headers?  Those do change a lot every 
> release as well.

The tramp3d and kdecore testcases are preprocessed files from a 
collection of benchmark sources we use, i.e. the same 
input for all compilers.  I think the {gimple,generic}-match.ii are in the 
same league.


Ciao,
Michael.

Re: GCC 8 vs. GCC 9 speed and size comparison

[Martin Liška]

[-- Attachment #1: Type: text/plain, Size: 1153 bytes --]

On 4/15/19 5:07 PM, Michael Matz wrote:
> Hi,
> 
> On Mon, 15 Apr 2019, Jakub Jelinek wrote:
> 
>>> It seems the C++ parser got quite a bit slower with gcc 9 :-( Most 
>>> visible in the compile time for tramp-3d (24%) and kdecore.cc (18% 
>>> slower with just PGO); it seems that the other .ii files are C-like 
>>> enough to not
>>
>> Is that with the same libstdc++ headers (i.e. identical *.ii files) or 
>> with the corresponding libstdc++ headers?  Those do change a lot every 
>> release as well.
> 
> The tramp3d and kdecore testcases are preprocessed files from a 
> collection of benchmark sources we use, i.e. the same 
> input for all compilers.  I think the {gimple,generic}-match.ii are in the 
> same league.

Yes, except kdecore.cc I used in all cases .ii pre-processed files. I'm going
to start using kdecore.ii as well.

As Honza pointed out in the email that hasn't reached this mailing list
due to file size, there's a significant change in inline-unit-growth. The param
has changed from 20 to 40 for GCC 9. Using --param inline-unit-growth=20 for all
benchmarks, I see green numbres for GCC 9!

Martin

> 
> 
> Ciao,
> Michael.
> 


[-- Attachment #2: gcc8-gcc9-comparison.ods --]
[-- Type: application/vnd.oasis.opendocument.spreadsheet, Size: 17331 bytes --]

Re: GCC 8 vs. GCC 9 speed and size comparison

[Martin Liška]

[-- Attachment #1: Type: text/plain, Size: 1292 bytes --]

On 4/16/19 9:48 AM, Martin Liška wrote:
> On 4/15/19 5:07 PM, Michael Matz wrote:
>> Hi,
>>
>> On Mon, 15 Apr 2019, Jakub Jelinek wrote:
>>
>>>> It seems the C++ parser got quite a bit slower with gcc 9 :-( Most 
>>>> visible in the compile time for tramp-3d (24%) and kdecore.cc (18% 
>>>> slower with just PGO); it seems that the other .ii files are C-like 
>>>> enough to not
>>>
>>> Is that with the same libstdc++ headers (i.e. identical *.ii files) or 
>>> with the corresponding libstdc++ headers?  Those do change a lot every 
>>> release as well.
>>
>> The tramp3d and kdecore testcases are preprocessed files from a 
>> collection of benchmark sources we use, i.e. the same 
>> input for all compilers.  I think the {gimple,generic}-match.ii are in the 
>> same league.
> 
> Yes, except kdecore.cc I used in all cases .ii pre-processed files. I'm going
> to start using kdecore.ii as well.
> 
> As Honza pointed out in the email that hasn't reached this mailing list
> due to file size, there's a significant change in inline-unit-growth. The param
> has changed from 20 to 40 for GCC 9. Using --param inline-unit-growth=20 for all
> benchmarks, I see green numbres for GCC 9!
> 
> Martin
> 
>>
>>
>> Ciao,
>> Michael.
>>
> 

Sending updated cell conditional formatting.

Martin

[-- Attachment #2: gcc8-gcc9-comparison.ods --]
[-- Type: application/vnd.oasis.opendocument.spreadsheet, Size: 17471 bytes --]

Re: GCC 8 vs. GCC 9 speed and size comparison

[Michael Matz]

[-- Attachment #1: Type: text/plain, Size: 720 bytes --]

Hello Martin,

On Tue, 16 Apr 2019, Martin Liška wrote:

> Yes, except kdecore.cc I used in all cases .ii pre-processed files. I'm 
> going to start using kdecore.ii as well.

If the kdecore.cc is the one from me it's also preprocessed and doesn't 
contain any #include directives, I just edited it somewhat to be 
compilable for different architecture.


Ciao,
Michael.

> 
> As Honza pointed out in the email that hasn't reached this mailing list
> due to file size, there's a significant change in inline-unit-growth. The param
> has changed from 20 to 40 for GCC 9. Using --param inline-unit-growth=20 for all
> benchmarks, I see green numbres for GCC 9!
> 
> Martin
> 
> > 
> > 
> > Ciao,
> > Michael.
> > 
> 
> 

Re: GCC 8 vs. GCC 9 speed and size comparison

[Richard Biener]

On Tue, Apr 16, 2019 at 10:53 AM Michael Matz <matz@suse.de> wrote:
>
> Hello Martin,
>
> On Tue, 16 Apr 2019, Martin Liška wrote:
>
> > Yes, except kdecore.cc I used in all cases .ii pre-processed files. I'm
> > going to start using kdecore.ii as well.
>
> If the kdecore.cc is the one from me it's also preprocessed and doesn't
> contain any #include directives, I just edited it somewhat to be
> compilable for different architecture.

Btw, the tramp3d sources on our testers _do_ contain #include directives.

Richard.

>
> Ciao,
> Michael.
>
> >
> > As Honza pointed out in the email that hasn't reached this mailing list
> > due to file size, there's a significant change in inline-unit-growth. The param
> > has changed from 20 to 40 for GCC 9. Using --param inline-unit-growth=20 for all
> > benchmarks, I see green numbres for GCC 9!
> >
> > Martin
> >
> > >
> > >
> > > Ciao,
> > > Michael.
> > >
> >
> >

Re: GCC 8 vs. GCC 9 speed and size comparison

[Richard Biener]

On Tue, Apr 16, 2019 at 11:56 AM Richard Biener
<richard.guenther@gmail.com> wrote:
>
> On Tue, Apr 16, 2019 at 10:53 AM Michael Matz <matz@suse.de> wrote:
> >
> > Hello Martin,
> >
> > On Tue, 16 Apr 2019, Martin Liška wrote:
> >
> > > Yes, except kdecore.cc I used in all cases .ii pre-processed files. I'm
> > > going to start using kdecore.ii as well.
> >
> > If the kdecore.cc is the one from me it's also preprocessed and doesn't
> > contain any #include directives, I just edited it somewhat to be
> > compilable for different architecture.
>
> Btw, the tramp3d sources on our testers _do_ contain #include directives.

So for the parser it's small differences that accumulate, for example
a lot more comptype calls via null_ptr_cst_p (via char_type_p) via the new
conversion_null_warnings which is called even without any warning option.

Possible speedup to null_ptr_cst_p is to avoid the expensive char_type_p
(called 50000 times in GCC 9 vs. only 2000 times in GCC 8):

Index: gcc/cp/call.c
===================================================================
--- gcc/cp/call.c       (revision 270387)
+++ gcc/cp/call.c       (working copy)
@@ -541,11 +541,11 @@ null_ptr_cst_p (tree t)
       STRIP_ANY_LOCATION_WRAPPER (t);

       /* Core issue 903 says only literal 0 is a null pointer constant.  */
-      if (TREE_CODE (type) == INTEGER_TYPE
-         && !char_type_p (type)
-         && TREE_CODE (t) == INTEGER_CST
+      if (TREE_CODE (t) == INTEGER_CST
+         && !TREE_OVERFLOW (t)
+         && TREE_CODE (type) == INTEGER_TYPE
          && integer_zerop (t)
-         && !TREE_OVERFLOW (t))
+         && !char_type_p (type))
        return true;
     }
   else if (CP_INTEGRAL_TYPE_P (type))

brings down the number of char_type_p calls to ~5000.  Still null_ptr_cst_p
calls are 150000 vs. 17000, caused by the conversion_null_warnings code
doing

  /* Handle zero as null pointer warnings for cases other
     than EQ_EXPR and NE_EXPR */
  else if (null_ptr_cst_p (expr) &&
           (TYPE_PTR_OR_PTRMEM_P (totype) || NULLPTR_TYPE_P (totype)))
    {

similarly "easy" to short-cut most of them:

@@ -6882,8 +6882,8 @@ conversion_null_warnings (tree totype, t
     }
   /* Handle zero as null pointer warnings for cases other
      than EQ_EXPR and NE_EXPR */
-  else if (null_ptr_cst_p (expr) &&
-          (TYPE_PTR_OR_PTRMEM_P (totype) || NULLPTR_TYPE_P (totype)))
+  else if ((TYPE_PTR_OR_PTRMEM_P (totype) || NULLPTR_TYPE_P (totype))
+          && null_ptr_cst_p (expr))
     {
       location_t loc =
get_location_for_expr_unwinding_for_system_header (expr);
       maybe_warn_zero_as_null_pointer_constant (expr, loc);

brings them down to 25000.

All this looks like there's plenty of low-hanging micro-optimization possible in
the C++ frontend.

I'm going to test the above two hunks, the overall savings are of course
small (and possibly applicable to branches as well).

Richard.


> Richard.
>
> >
> > Ciao,
> > Michael.
> >
> > >
> > > As Honza pointed out in the email that hasn't reached this mailing list
> > > due to file size, there's a significant change in inline-unit-growth. The param
> > > has changed from 20 to 40 for GCC 9. Using --param inline-unit-growth=20 for all
> > > benchmarks, I see green numbres for GCC 9!
> > >
> > > Martin
> > >
> > > >
> > > >
> > > > Ciao,
> > > > Michael.
> > > >
> > >
> > >

Re: GCC 8 vs. GCC 9 speed and size comparison

[Jakub Jelinek]

On Tue, Apr 16, 2019 at 01:25:38PM +0200, Richard Biener wrote:
> So for the parser it's small differences that accumulate, for example
> a lot more comptype calls via null_ptr_cst_p (via char_type_p) via the new
> conversion_null_warnings which is called even without any warning option.
> 
> Possible speedup to null_ptr_cst_p is to avoid the expensive char_type_p
> (called 50000 times in GCC 9 vs. only 2000 times in GCC 8):

If we do this (looks like a good idea to me), perhaps we should do also
following (first part just doing what you've done in yet another spot,
moving the less expensive checks first, because null_node_p strips location
wrappers etc.) and the second not to call conversion_null_warnings at all
if we don't want to warn (though, admittedly while
warn_zero_as_null_pointer_constant defaults to 0, warn_conversion_null
defaults to 1).

--- gcc/cp/call.c	2019-04-12 21:47:06.301924378 +0200
+++ gcc/cp/call.c	2019-04-16 13:35:59.779977641 +0200
@@ -6844,8 +6844,9 @@ static void
 conversion_null_warnings (tree totype, tree expr, tree fn, int argnum)
 {
   /* Issue warnings about peculiar, but valid, uses of NULL.  */
-  if (null_node_p (expr) && TREE_CODE (totype) != BOOLEAN_TYPE
-      && ARITHMETIC_TYPE_P (totype))
+  if (TREE_CODE (totype) != BOOLEAN_TYPE
+      && ARITHMETIC_TYPE_P (totype)
+      && null_node_p (expr))
     {
       location_t loc = get_location_for_expr_unwinding_for_system_header (expr);
       if (fn)
@@ -7059,7 +7060,9 @@ convert_like_real (conversion *convs, tr
       return cp_convert (totype, expr, complain);
     }
 
-  if (issue_conversion_warnings && (complain & tf_warning))
+  if (issue_conversion_warnings
+      && (complain & tf_warning)
+      && (warn_conversion_null || warn_zero_as_null_pointer_constant))
     conversion_null_warnings (totype, expr, fn, argnum);
 
   switch (convs->kind)


	Jakub

Re: GCC 8 vs. GCC 9 speed and size comparison

[Richard Biener]

On Tue, Apr 16, 2019 at 1:39 PM Jakub Jelinek <jakub@redhat.com> wrote:
>
> On Tue, Apr 16, 2019 at 01:25:38PM +0200, Richard Biener wrote:
> > So for the parser it's small differences that accumulate, for example
> > a lot more comptype calls via null_ptr_cst_p (via char_type_p) via the new
> > conversion_null_warnings which is called even without any warning option.
> >
> > Possible speedup to null_ptr_cst_p is to avoid the expensive char_type_p
> > (called 50000 times in GCC 9 vs. only 2000 times in GCC 8):
>
> If we do this (looks like a good idea to me), perhaps we should do also
> following (first part just doing what you've done in yet another spot,
> moving the less expensive checks first, because null_node_p strips location
> wrappers etc.) and the second not to call conversion_null_warnings at all
> if we don't want to warn (though, admittedly while
> warn_zero_as_null_pointer_constant defaults to 0, warn_conversion_null
> defaults to 1).
>
> --- gcc/cp/call.c       2019-04-12 21:47:06.301924378 +0200
> +++ gcc/cp/call.c       2019-04-16 13:35:59.779977641 +0200
> @@ -6844,8 +6844,9 @@ static void
>  conversion_null_warnings (tree totype, tree expr, tree fn, int argnum)
>  {
>    /* Issue warnings about peculiar, but valid, uses of NULL.  */
> -  if (null_node_p (expr) && TREE_CODE (totype) != BOOLEAN_TYPE
> -      && ARITHMETIC_TYPE_P (totype))
> +  if (TREE_CODE (totype) != BOOLEAN_TYPE
> +      && ARITHMETIC_TYPE_P (totype)
> +      && null_node_p (expr))
>      {
>        location_t loc = get_location_for_expr_unwinding_for_system_header (expr);
>        if (fn)
> @@ -7059,7 +7060,9 @@ convert_like_real (conversion *convs, tr
>        return cp_convert (totype, expr, complain);
>      }
>
> -  if (issue_conversion_warnings && (complain & tf_warning))
> +  if (issue_conversion_warnings
> +      && (complain & tf_warning)
> +      && (warn_conversion_null || warn_zero_as_null_pointer_constant))
>      conversion_null_warnings (totype, expr, fn, argnum);
>
>    switch (convs->kind)

Yes, that looks good to me as well.

Btw, I noticed the C++ FE calls build_qualified_type a _lot_, in 99% picking
up an existing variant from the list and those list walks visit ~20 types
_on average_!  A simple LRU cache (just put the found variant first) manages
to improve compile-time to be even better than GCC 8 (~1% improvement).
It improves the number of types checked to ~2.5 (from those 20).  Also
-fsynax-only compile-time from 2.9s to 2.75s (consistently).

Index: gcc/tree.c
===================================================================
--- gcc/tree.c  (revision 270387)
+++ gcc/tree.c  (working copy)
@@ -6459,9 +6459,22 @@ get_qualified_type (tree type, int type_
   /* Search the chain of variants to see if there is already one there just
      like the one we need to have.  If so, use that existing one.  We must
      preserve the TYPE_NAME, since there is code that depends on this.  */
-  for (t = TYPE_MAIN_VARIANT (type); t; t = TYPE_NEXT_VARIANT (t))
-    if (check_qualified_type (t, type, type_quals))
-      return t;
+  for (tree *t = &TYPE_MAIN_VARIANT (type); *t; t = &TYPE_NEXT_VARIANT (*t))
+    {
+      if (check_qualified_type (*t, type, type_quals))
+       {
+         tree mv = TYPE_MAIN_VARAINT (type);
+         tree x = *t;
+         if (x != mv)
+           {
+             /* LRU.  */
+             *t = TYPE_NEXT_VARIANT (*t);
+             TYPE_NEXT_VARIANT (x) = TYPE_NEXT_VARIANT (mv);
+             TYPE_NEXT_VARIANT (mv) = x;
+           }
+         return x;
+       }
+    }

   return NULL_TREE;
 }

peeling the main-variant case above might make the code a little bit prettier.

Richard.

>
>         Jakub