This is the mail archive of the
gsl-discuss@sources.redhat.com
mailing list for the GSL project.
Re: design of functions in miltimin
- From: "Andrey V. Panov" <panov at canopus dot iacp dot dvo dot ru>
- To: gsl-discuss at sources dot redhat dot com
- Date: Wed, 2 Jul 2003 13:40:20 +1100
- Subject: Re: design of functions in miltimin
- Organization: Institute for Automation and Control Processes
- References: <200307011542.32075.panov@canopus.iacp.dvo.ru> <3F012ED9.8070405@ufrmd.dauphine.fr>
- Reply-to: panov at canopus dot iacp dot dvo dot ru
Hi.
I disagree. Each call to a cblas function leads to additional for cycle.
There is no much difference when unique call is used (only cost of a function
call). But in the case of serial 4 calls this leads to 4 for cycles instead
of one.
On Tuesday 01 July 2003 17:48, Fabrice Rossi wrote:
> Hi.
>
> My understanding of vector calculation optimization is that one should
> rely on BLAS as much as possible. I'm not sure that your code is really
> more efficient than the BLAS code if you use an optimized implementation
> of BLAS such as ATLAS, but of course, I might be wrong. Did you make
> some timing with GSL+ATLAS to compare both solutions?
>
> Fabrice
>
> Andrey V. Panov wrote:
> > I think that the body of take_step() function in
> > multimin/directional_minimize.c :
> >
> > {
> > gsl_vector_set_zero (dx);
> > gsl_blas_daxpy (-step * lambda, p, dx);
> >
> > gsl_vector_memcpy (x1, x);
> > gsl_blas_daxpy (1.0, dx, x1);
> > }
> >
> > can be replaced by more efficient code:
> >
> > {
> > int i;
> > double dx_temp;
> > for(i = 0; i < dx->size; i++)
> > {
> > dx_temp = -step * lambda * gsl_vector_get(p, i);
> > gsl_vector_set(dx, i, dx_temp);
> > gsl_vector_set(x1, i, gsl_vector_get(x, i) + dx_temp);
> > }
> > }
> >
> > There are also similar parts of code inside miltimin routines which
> > may be
> > replaced.
--
Andrey V. Panov
panov /@/ canopus.iacp.dvo.ru