help-gsl
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-gsl] ode version and compilers


From: Alan Fung
Subject: Re: [Help-gsl] ode version and compilers
Date: Wed, 6 Nov 2013 09:52:16 +0800

Hi,

I would like to share my investigation last night.

For simplicity, I would like to call the following segment an iteration.

while (t < t1)
  {
    int status = gsl_odeiv2_evolve_apply (e, c, s, &sys, &t, t1, &h, y);

    if (status != GSL_SUCCESS)
      break;
  }

I found that, if I modify something outside each iteration and the function
func, e.g. change some parameters in params, results by 1.16 and 1.15 are
different.  It is because, in 1.16, the dydt_out's are old values before
modifications in params.  1.15 will not suffer from these `unpredictable'
changes, as it re-calculate dydt_in every times.  The performance
regression should be due to this difference, because, in 1.16, the dydt_out
doesn't agree with those `updated' parameters.  I accept that memcpy is
faster than recalculating dydt_in, if the routine can really anticipate
dydt_in in the next iteration.

Honestly, I started to worry whether modifying things in params outside
iterations is a misuse of GSL.

Alan


2013/11/6 Tuomo Keskitalo <address@hidden>

> Hi,
>
> Thanks for the code example, I'll try to have a look at it this week.
>
> On 11/05/2013 03:46 PM, Rhys Ulerich wrote:
> > Tuomo,
> >
> > Alan and Gideon have experienced some significant slowdowns in ODE
> > integration going from 1.15 to 1.16.  Alan's tracked down the problem
> > to a single revision...
> >
> >> For the source code I have attached, I have done some tests on different
> >> versions.
> >> 1.15:
> >> Running time: 0m0.759s
> >> Output result: -0.378978 (center of mass of dynamical variables)
> >>
> >> 1.16
> >> Running time: 0m10.670s
> >> Output result: -0.378996
> >>
> >> 1.16 (without revision 4771):
> >> Running time: 0m0.754s
> >> Output result: -0.378978
> >>
> >> In revision 4771, the programmer intended to use e->dydt_out to update
> >> e->dydt_in, rather than calculating a new e->dydt_in.  Based on my
> >> understanding on the source code, he thought that memcpy is better than
> a
> >> new calculation.  But, in my case, it makes a big performance
> regression.
> >> Also, in my experiment, without 4771, results by 1.15 and 1.16 agree
> with
> >> each other.  So, I would like to question which version is not reliable.
> >> For the reliability concern, I have sent an email to bug-gsl to question
> >> about this.
> >>
> >> ==============================
> >>
> >> The source code:
> >> http://www.filedropper.com/cannstdsubdelay
> >
> > Any thoughts?
> http://bzr.savannah.gnu.org/lh/gsl/trunk/revision/4771#ode-initval2/evolve.c
> > seems incredibly benign at a glance.
> >
> > - Rhys
> > .
> >
>
>
> --
> address@hidden
> http://iki.fi/tuomo.keskitalo
>


reply via email to

[Prev in Thread] Current Thread [Next in Thread]