... and time report
Execution times (seconds)
garbage collection: 12.48 ( 2%) usr 0.00 ( 0%) sys 12.50 ( 2%) wall
0 kB ( 0%) ggc
callgraph optimization: 0.21 ( 0%) usr 0.00 ( 0%) sys 0.21 ( 0%) wall
2743 kB ( 0%) ggc
varpool construction : 0.97 ( 0%) usr 0.02 ( 0%)
> > On 06/30/2010 02:26 PM, Basile Starynkevitch wrote:
> >> On Wed, 2010-06-30 at 14:23 -0700, Taras Glek wrote:
> >>
> >>> I tried 4.5 -O2 and it's actually faster than 4.3 -Os.
> >>>
> >>> I am happy that -O2 performance is actually pretty good, but -Os
> >>> regression is going to hurt on m
>> When you compile with -Os, the inlining happens only when code size reduces.
>> Thus we pretty much care about the code size metrics only. I suspect the
>> problem here might be that normal C++ code needs some inlining to make
>> abstraction penalty go away. GCC -Os implementation is generally
> On 06/30/2010 02:26 PM, Basile Starynkevitch wrote:
>> On Wed, 2010-06-30 at 14:23 -0700, Taras Glek wrote:
>>
>>> I tried 4.5 -O2 and it's actually faster than 4.3 -Os.
>>>
>>> I am happy that -O2 performance is actually pretty good, but -Os
>>> regression is going to hurt on mobile.
>>>
On 06/30/2010 02:26 PM, Basile Starynkevitch wrote:
On Wed, 2010-06-30 at 14:23 -0700, Taras Glek wrote:
I tried 4.5 -O2 and it's actually faster than 4.3 -Os.
I am happy that -O2 performance is actually pretty good, but -Os
regression is going to hurt on mobile.
Did you try gcc-4.5
On Wed, 2010-06-30 at 14:23 -0700, Taras Glek wrote:
>
> I tried 4.5 -O2 and it's actually faster than 4.3 -Os.
>
> I am happy that -O2 performance is actually pretty good, but -Os
> regression is going to hurt on mobile.
Did you try gcc-4.5 -flto -Os or gcc-4.5 -flto -O2?
It would be interest
On 06/24/2010 12:06 PM, Andrew Pinski wrote:
On Jun 24, 2010, at 11:50 AM, Taras Glek wrote:
Hi,
Just wanted to give a heads up on what might be the biggest
compiler-upgrade-related performance difference we've seen at Mozilla.
We switched gcc4.3 for gcc4.5 and our automated benchmarking
Jan Hubicka wrote:
GiNaC indeed shows interesting behaviour. Just the first test on 4.3 is:
timing commutative expansion and substitution
size: 100 200 400 800
time/s: 0.064 0.301.4 6.2
for 4.5
timing commutative expansion and substitution
>
> (it is regression at 4.5 branch, forgot to mention)
PR44694
GiNaC indeed shows interesting behaviour. Just the first test on 4.3 is:
timing commutative expansion and substitution
size: 100 200 400 800
time/s: 0.064 0.301.4 6.2
for 4.5
timing commu
> > > Jan Hubicka wrote:
> > >>> On Fri, 25 Jun 2010, it was written:
> > >>> There sure is something in 4.5. I've seen a 1-10% slowdown at the GiNaC
> > >>> (a computer algebra library) benchmark suite after switching from 4.4 to
> > >>> 4.5 on x86_64 when compiling with -O2. And there hasn't been
> > Jan Hubicka wrote:
> >>> On Fri, 25 Jun 2010, it was written:
> >>> There sure is something in 4.5. I've seen a 1-10% slowdown at the GiNaC
> >>> (a computer algebra library) benchmark suite after switching from 4.4 to
> >>> 4.5 on x86_64 when compiling with -O2. And there hasn't been a measura
> Jan Hubicka wrote:
>>> On Fri, 25 Jun 2010, it was written:
>>> There sure is something in 4.5. I've seen a 1-10% slowdown at the GiNaC
>>> (a computer algebra library) benchmark suite after switching from 4.4 to
>>> 4.5 on x86_64 when compiling with -O2. And there hasn't been a measurable
>>> pe
Jan Hubicka wrote:
On Fri, 25 Jun 2010, it was written:
There sure is something in 4.5. I've seen a 1-10% slowdown at the GiNaC
(a computer algebra library) benchmark suite after switching from 4.4 to
4.5 on x86_64 when compiling with -O2. And there hasn't been a measurable
performance difference
> On Fri, 25 Jun 2010, it was written:
> > On Thu, Jun 24, 2010 at 11:50:52AM -0700, Taras Glek wrote:
> > > We switched gcc4.3 for gcc4.5 and our automated benchmarking
> > > infrastructure reported 4-19% slowdown on most of our performance
> > > metrics on 32 and 64bit Linux.
> >
> > Could you p
> On Fri, Jun 25, 2010 at 06:10:56AM -0700, Jan Hubicka wrote:
> > When you compile with -Os, the inlining happens only when code size reduces.
> > Thus we pretty much care about the code size metrics only. I suspect the
> > problem here might be that normal C++ code needs some inlining to make
>
On Fri, 25 Jun 2010, it was written:
> On Thu, Jun 24, 2010 at 11:50:52AM -0700, Taras Glek wrote:
> > We switched gcc4.3 for gcc4.5 and our automated benchmarking
> > infrastructure reported 4-19% slowdown on most of our performance
> > metrics on 32 and 64bit Linux.
>
> Could you please also try
> Hi,
>
> On Fri, 25 Jun 2010, Jan Hubicka wrote:
>
> > I would be also very interested to know how profile feedback works in this
> > case
> > (and why it does not work in previous releases).
>
> Profiling multi-threading programs needs -fprofile-correction that appeared
> only in 4.4 (but I h
On Fri, Jun 25, 2010 at 06:10:56AM -0700, Jan Hubicka wrote:
> When you compile with -Os, the inlining happens only when code size reduces.
> Thus we pretty much care about the code size metrics only. I suspect the
> problem here might be that normal C++ code needs some inlining to make
> abstract
Hi,
On Fri, 25 Jun 2010, Jan Hubicka wrote:
> I would be also very interested to know how profile feedback works in this
> case
> (and why it does not work in previous releases).
Profiling multi-threading programs needs -fprofile-correction that appeared
only in 4.4 (but I have no idea whether
On Fri, Jun 25, 2010 at 1:02 PM, Richard Guenther
wrote:
> On Fri, Jun 25, 2010 at 12:45 PM, Eric Botcazou wrote:
>>> I do think so.
>>
>> Huh? What do your version and mine return for the following assignment?
>>
>> void foo (int i)
>> {
>> struct S s;
>> s.a = i;
>> }
>>
>>> Which in the fol
On Thu, Jun 24, 2010 at 11:50:52AM -0700, Taras Glek wrote:
> Just wanted to give a heads up on what might be the biggest
> compiler-upgrade-related performance difference we've seen at Mozilla.
>
> We switched gcc4.3 for gcc4.5 and our automated benchmarking
> infrastructure reported 4-19% sl
> On Fri, Jun 25, 2010 at 8:15 AM, Jonathan Adamczewski
> wrote:
> > On 25/06/10 06:39, Richard Guenther wrote:
> >> There are btw. some bugs wrt accounting of functions called once
> >> being inlined in 4.5 which were fixed on trunk which allow extra
> >> inlining.
> >>
> >
> > Are these changes
On Fri, Jun 25, 2010 at 12:45 PM, Eric Botcazou wrote:
>> I do think so.
>
> Huh? What do your version and mine return for the following assignment?
>
> void foo (int i)
> {
> struct S s;
> s.a = i;
> }
>
>> Which in the following example makes i = *p not likely eliminated
>> but makes j = *q l
> I do think so.
Huh? What do your version and mine return for the following assignment?
void foo (int i)
{
struct S s;
s.a = i;
}
> Which in the following example makes i = *p not likely eliminated
> but makes j = *q likely eliminated.
>
> void foo (int *p, struct X *q)
> {
> int i;
>
On Fri, Jun 25, 2010 at 8:15 AM, Jonathan Adamczewski
wrote:
> On 25/06/10 06:39, Richard Guenther wrote:
>> There are btw. some bugs wrt accounting of functions called once
>> being inlined in 4.5 which were fixed on trunk which allow extra
>> inlining.
>>
>
> Are these changes likely to make it
On Fri, Jun 25, 2010 at 8:34 AM, Eric Botcazou wrote:
>> Minus whitespace changes it seems to be
>>
>> ! if (lhs_free && (is_gimple_reg (rhs) ||
>> is_gimple_min_invariant (rhs)))
>> rhs_free = true;
>>
>> vs.
>>
>> ! if (lhs_free
>> ! && (is_gimple_
> Minus whitespace changes it seems to be
>
> ! if (lhs_free && (is_gimple_reg (rhs) ||
> is_gimple_min_invariant (rhs)))
> rhs_free = true;
>
> vs.
>
> ! if (lhs_free
> ! && (is_gimple_reg (rhs)
> ! || !is_gimple_reg_type (TREE_TYPE
On 25/06/10 06:39, Richard Guenther wrote:
> There are btw. some bugs wrt accounting of functions called once
> being inlined in 4.5 which were fixed on trunk which allow extra
> inlining.
>
Are these changes likely to make it onto the 4.5 branch and into (say)
4.5.1?
j.
On Thu, Jun 24, 2010 at 10:24 PM, Eric Botcazou wrote:
>> In addition, it appears at first glance that GCC is either no longer
>> inlining at -Os, even when it would be a size advantage to do so, or is
>> making some very poor inlining choices.
>>
>> e.g. +72 nsTArray::nsTArray(nsTArray const
> In addition, it appears at first glance that GCC is either no longer
> inlining at -Os, even when it would be a size advantage to do so, or is
> making some very poor inlining choices.
>
> e.g. +72 nsTArray::nsTArray(nsTArray const&)
>
> We can turn some of these observations into bug report
On 6/24/10 3:06 PM, Andrew Pinski wrote:
Most of the code is compiled with -fPIC -fno-rtti -fno-exceptions -Os
Stop right there. You are compiling at -Os, that is tuned for size and
not speed. So the question is did the size go down? Not the speed
decreased. Try at -O2 and report back. I doubt
On Jun 24, 2010, at 11:50 AM, Taras Glek wrote:
Hi,
Just wanted to give a heads up on what might be the biggest compiler-
upgrade-related performance difference we've seen at Mozilla.
We switched gcc4.3 for gcc4.5 and our automated benchmarking
infrastructure reported 4-19% slowdown on
32 matches
Mail list logo
