[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: For loop benchmarks between Octave versions
From: |
Rik |
Subject: |
Re: For loop benchmarks between Octave versions |
Date: |
Mon, 16 Jun 2014 17:39:37 -0700 |
On 06/15/2014 02:46 AM, PrasannaKumar Muralidharan wrote:
> The same test case took 2.35s in 3.6.4 while it took around 3.9s in
> 3.7.5. So bisected Octave code between release 3.6.4 and 3.8.1.
>
> CPU details:
> Intel Core i5. Clock speed set to 1.2GHz.
>
> The time taken to run the test case:
> ********************************************************************************
> 3.7.5 (did not note hg revision) -> 3.9s
> 16650:18d3c1b981e7 (3.7.3+) -> 4.13013s
> 16412:61989cde13ae (3.7.2+) -> 3.5439s
> 16295:4a1300ed5d3c (3.7.2+) -> 3.96383s
> 16216:70c47da7e02b (3.7.2+) -> 3.99449s
> 16183:359d56094efa (3.7.2+) -> 4.15015s
> 16168:8650eec57e9f (3.7.2+) -> 3.86547s
> 16161:b672afbb7c3c (3.7.2+) -> 4.06835s
> 16157:335041cc657a (3.7.2+) -> 4.06872s
> 16089:8a8e04aa3c98 (3.6.4) -> 2.34667s
> 16156:236be6179785 (3.7.2+) -> 3.85227s
> ********************************************************************************
>
> Hg bisect result:
> ********************************************************************************
> The first bad revision is:
> changeset: 16156:236be6179785
> parent: 16154:aa5e1e8dce66
> parent: 16089:8a8e04aa3c98
> user: John W. Eaton <address@hidden>
> date: Thu Feb 28 02:25:44 2013 -0500
> summary: maint: periodic merge of stable to default
>
> Not all ancestors of this changeset have been checked.
> Use bisect --extend to continue the bisection from
> the common ancestor, 6a44bb3c9593.
> ********************************************************************************
>
> This result can be used to do further analysis.
>
> Note:
> I am continuing with the bisect further to find the change that causes
> the regression.
>
> Hope this helps,
> PrasannaKumar
>
I find that this changeset:
12920:5d18231eee00 Extend profiling support to operators.
produces a 50% slow down when using the for loop benchmark. Unless we can
figure out a lower footprint way to do profiling we might be stuck with
this part of the slowdown. There is still another 50% which seems to be
due to other accumulated cruft, i.e., I didn't find a smoking gun changeset.
--Rik
- For loop benchmarks between Octave versions, Rik, 2014/06/06
- Re: For loop benchmarks between Octave versions,
Rik <=
- Re: For loop benchmarks between Octave versions, ijourneaux, 2014/06/17
- Re: For loop benchmarks between Octave versions, Julien Bect, 2014/06/17
- Re: For loop benchmarks between Octave versions, John W. Eaton, 2014/06/17
- Re: For loop benchmarks between Octave versions, Julien Bect, 2014/06/17
- Re: For loop benchmarks between Octave versions, John W. Eaton, 2014/06/17
- Re: For loop benchmarks between Octave versions, Jordi GutiƩrrez Hermoso, 2014/06/17
- Re: For loop benchmarks between Octave versions, Julien Bect, 2014/06/17
- Re: For loop benchmarks between Octave versions, Daniel J Sebald, 2014/06/17
- Re: For loop benchmarks between Octave versions, Julien Bect, 2014/06/22
- Re: For loop benchmarks between Octave versions, PrasannaKumar Muralidharan, 2014/06/23