Re: For loop benchmarks between Octave versions

[Daniel J Sebald]

On 06/17/2014 10:11 AM, Julien Bect wrote:
> Le 17/06/2014 16:49, John W. Eaton a écrit :
> > On 06/17/2014 09:29 AM, Julien Bect wrote:
> > > Le 17/06/2014 02:39, Rik a écrit :
> > > > I find that this changeset:
> > > >
> > > > 12920:5d18231eee00 Extend profiling support to operators.
> > > >
> > > > produces a 50% slow down when using the for loop benchmark. Unless we
> > > > can figure out a lower footprint way to do profiling we might be stuck
> > > > with this part of the slowdown.
> > >
> > > The attached patch significantly improves the situation for me.
> > >
> > > On the gui-release branch, the runtime goes from 2.75 seconds to 2.16
> > > seconds.
> > >
> > > Not a 50% improvement, though...
> >
> > Does declaring is_active "inline" really make a difference? I'd be
> > surprised if that is not always inlined when the compiler is
> > performing inlining optimizations.
>
> Yes, I have tried both, and it does make a (small) difference.
>
> The main difference was obtained by calling profiler.is_active directly
> (2.75 -> 2.26, roughly).
>
> The runtime dropped to 2.16 when I added inline.

I'm surprised that made a difference.  I believe that functions defined 
within the class declaration are implicitly inline.  "inline" must have 
additional meaning to the compiler.  For example, keeping the return 
variable in a register.  Odd.


> > I don't much like having to manually match up new/delete, so I'd
> > rather see that go inside a constructor/destructor pair. Done properly
> > and with inlining, I don't see why it would be inefficient and perhaps
> > we could eliminate the BEGIN/END macros?
>
> I try that right now.

Also try this construct please:

#define END_PROFILER_BLOCK \
    if (pe) {delete (pe);} \
   }

Yes, I realize that "delete" will check that the pointer is non-null, 
but I'm curious if perhaps delete is a function call rather than an 
inline, and if so does an unnecessary jump.

Thanks,

Dan