Re: octave dev slow down

[John W. Eaton]

On 06/19/2017 01:24 PM, Michael D Godfrey wrote:
> On 06/19/2017 04:32 PM, Rik wrote:
> > On 06/19/2017 07:37 AM, Michael D Godfrey wrote:

> > > I have done some comparisons between 4.0.3 and the current dev
> > > be69ea3de7a3 tip @ (also some previous devs)
> > > and typically I see:
> > >
> > > 4.3.0+
> > > test 2: cputime used: 9.2e-01 seconds
> > >
> > > 4.0.3   /usr/bin/octave --no-gui
> > > test 2: cputime used: 6.4e-01 seconds
> > >
> > > Initially, I was checking Rik's conversion of the elementary
> > > functions to C++ std (which seem to be all
> > > alright) but I noticed the large timing difference.  The code that I
> > > used spends most of its time transforming
> > > complex-valued arrays using exp(), atanh(), etc. Since I ran some
> > > tests prior to Rik's new code, it appears
> > > that the cause is not the new std functions.

Can you share the code you use for testing?

My intent is not to make Octave slower.  However, I can tolerate a 
little (hopefully temporary) decrease in performance in exchange for 
code that is clearer and easier to maintain or that is less likely to 
lead to memory leaks.  That's my primary goal right now.

> > Thanks for noticing this.  If the issue is a slow down in
> > complex-valued arrays then maybe you can re-test in about a week?  At
> > the moment I am converting many of the basic mapper functions which
> > used to dispatch to gnulib, Fortran, or even our own hand-rolled C++
> > code, to instead dispatch to the C++ standard library.  Besides making
> > the code simpler, and reducing our external dependencies during
> > configure, Octave will now sit squarely atop the standard library
> > which is a well-debugged and well-coded piece of software.
> >
> > My next task, after the basic functions, is to look at how the mapper
> > functions are implemented for complex values.  Currently, we often
> > hand code our own functions for complex values.  However, std::complex
> > already includes templates for some of the basic math functions.  I
> > would like to switch over to using the standard templates whenever
> > possible which might improve performance.

Could it also improve performance to use templates differently so that 
we can avoid passing function pointers?  I'm thinking that using 
functions as template parameters allows inlining where passing function 
pointers as parameters to a mapping function does not.  But I'm not sure 
whether that's correct.  We currently have a mixture of these styles.  I 
guess it would be good to figure out which is better and be consistent 
if possible.

jwe