octave-maintainers
[Top][All Lists]
Advanced

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

Re: mapper functions for 3.1


From: David Bateman
Subject: Re: mapper functions for 3.1
Date: Sun, 17 Feb 2008 18:28:18 +0100
User-agent: Thunderbird 2.0.0.6 (X11/20070914)

John W. Eaton wrote:
> On 16-Feb-2008, John W. Eaton wrote:
> 
> | There might be a slick way to combine the functor
> | and functor_with_conversion classes using default template parameters
> | but I don't see it at the moment.
> 
> OK, here is one way.  Define the functor class like this:


Not sure I'll have time to look at this in the next few days, so feel
free to do this change if I don't get there. In any case as a
motivation, there are three interesting cases to consider, and how they
perform in 3.0.0 and in the current CVS with my patch are

1) A function that calls neither F77_XFCN and that returns double type
for all double inputs (eg sin)
2) A function that calls F77_XFCN but returns double for all types (eg
gamma)
3) A function that can return complex for double inputs (eg sqrt)

In 3.0.0 I see the following

octave:41  n = 2048; a = randn(n, n); t0 = cputime(); b = sin(a);
cputime() - t0
ans =  0.25396
octave:2>  n = 2048; a = randn(n, n); t0 = cputime(); b = gamma(a);
cputime() - t0
ans =  1.1248
octave:3>  n = 2048; a = randn(n, n); t0 = cputime(); b = sqrt(a);
cputime() - t0
ans =  0.33895

In the current CVS with my patch I see

octave:1>  n = 2048; a = randn(n, n); t0 = cputime(); b = sin(a);
cputime() - t0
ans =  0.20897
octave:2>
octave:2>  n = 2048; a = randn(n, n); t0 = cputime(); b = gamma(a);
cputime() - t0
ans =  1.0358
octave:3>  n = 2048; a = randn(n, n); t0 = cputime(); b = sqrt(a);
cputime() - t0
ans =  0.23696

This is partly due to the c++ exception handler patch, but equally due
to the removal of the check on error_state in the mapper functions and
the manner in which functions that can return complex for double inputs
are implemented in the patch. So there are quite respectable speed
improvements after these changes. It would be interesting to see what
happens on a cygwin build and whether the SJLJ issues in the cygwin
exception handling is fixed.. Perhaps the recently exception handler
change is a bad idea for cygwin, but as we have mingw and msvc builds
now do we care in any case..

D.






reply via email to

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