octave-maintainers
[Top][All Lists]
Advanced

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

Re: octave dev slow down


From: Michael D Godfrey
Subject: Re: octave dev slow down
Date: Mon, 19 Jun 2017 23:41:25 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0



On 06/19/2017 11:18 PM, John W. Eaton wrote:
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
John,

I understand, and of course strongly support, the work that you and Rik are doing right now. This will surely
make Octave better and more easily maintained. I just felt that I should remind you of the performance issue
which has been mentioned here a while ago already. Currently the code that I have been using is a segment
of a fairly large program. I have just planted cputime() calls at convenient points. I will look at extracting a block
of code as a standalone if that looks like it is really be needed. Right now it appears that any code that
applies operators like exp() or tanh() to fairly long and mostly complex vectors will show the slow down that
I have observed. But, I may be doing something that is inefficient for some specific reason.

Michael

reply via email to

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