On 11/13/2017 04:36 PM, Richard Sandiford wrote: > Jeff Law <l...@redhat.com> writes: >> On 11/09/2017 04:06 AM, Richard Sandiford wrote: >> >>>> Let me say at the outset that I struggle to comprehend that a few >>>> instructions is even a consideration when not optimizing, especially >>>> in light of the bug the macro caused that would have been prevented >>>> by using a function instead. But... >>> >>> Many people still build at -O0 though. One of the things I was asked >>> for was the time it takes to build stage 2 with an -O0 stage 1 >>> (where stage 1 would usually be built by the host compiler). >> I suspect folks are concerned about this because it potentially affects >> their daily development cycle times. So they're looking to see if the >> introduction of the poly types has a significant impact. It's a >> legitimate question, particularly for the introduction of low level >> infrastructure that potentially gets hit a lot. >> >> Richard, what were the results of that test (if it's elsewhere in the >> thread I'll eventually find it... > > On an x86_64 box I got: > > real: +7% > user: +8.6% > > for building stage2 with an -O0 -g stage1. For aarch64 with the > NUM_POLY_INT_COEFFS==2 change it was: > > real: +17% > user: +20% > > That's obviously not ideal, but C++11 would get rid of some of the > inefficiencies, once we can switch to that. Ouch. But I guess to some extent it has to be expected given what you've got to do under the hood.
> > You've probably already seen this, but it's compile-time neutral on > x86_64 in terms of running a gcc built with --enable-checking=release, > within a margin of about [-0.1%, 0.1%]. Good. Presumably that's because it all just falls out and turns into wi:: stuff on targets that don't need the poly stuff. > > For aarch64 with NUM_POLY_INT_COEFFS==2, a gcc built with > --enable-checking=release is ~1% slower when using -g and ~2% > slower with -O2 -g. That's not terrible given what's going on here. I'm still pondering the whole construction/initialization and temporary objects issue. I may try to work through some of the actual patches, then come back to those issues. > >> I'm just starting to try and make some headway on this kit). > > Thanks :-) I guess it's going to be a real slog going through them, > sorry, even despite the attempt to split them up. No worries. It's what we sign up for :-) Your deep testing and long history with the project really help in that if something goes wrong I know you're going to be around to fix it. Jeff
