Re: atomic references

[John W. Eaton]

On 8/14/19 12:46 PM, Rik wrote:
> I want to write down what we know, as I understand it, so that we don't get
> ahead of our skis.
>
> First, it does objectively appear that atomic reference counting has
> resulted in a performance hit.
>
> Indirect evidence #1 is the ~2X step change in runtime from 3.8.X to 4.0.X
> series which featured the introduction of classdef and the Qt GUI.
>
> Indirect evidence #2 is this changeset which is associated with the 3.8.X
> to 4.0.X transition.
>
> changeset:   18584:89b7bd7d0b83
> branch:      gui-release
> parent:      18577:56209bab4213
> user:        Rik <address@hidden>
> date:        Sat Mar 22 13:39:55 2014 -0700
> summary:     configure.ac: Use atomic reference counting by default for Qt
> toolkit.
>
> Direct evidence #1 is the ~18% performance increase when Octave is
> configured with --disable-atomic-refcount.
>
> Given that, the next step is working out a solution.  I don't want to jump
> to conclusions here either.
>
> Question #1 : Is there a way to divide accesses between those which will be
> cross-thread and those which won't?

It seems complicated to me, but it might be possible.  I'd rather avoid 
it unless we can come up with simple rules for how it works.  Otherwise 
I imagine a never ending list of bugs due to misunderstanding what 
objects can be passed across threads and how it is supposed to be done.

> If the answer is yes, then we might be able to save CPU cycles if there is
> a limited number of objects which need to be passed across threads.
>
> As an example, the Octave worker thread creates many temporary octave_value
> objects when it is processing an expression.  None of these ever need to be
> seen by the GUI, only the final result assigned to either 'ans' or a
> variable name needs to potentially be a cross-thread object.
>
> Could the subset of octave_values to be exported be reduced to just the
> ones necessary for Qt plotting?  Or does the GUI require all variables in
> the symbol table to also be exported?

For the workspace browser, we currently pass an object that is a summary 
of the current workspace.  But it does contain info from the current 
stack frame, including variable values.

> Question #2 : If objects must be passed cross-thread, is there a more
> efficient way to do it?
>
> jwe stated that mutexes are less efficient then what we have today with
> atomic reference counting.  Is there something else we could use from the
> C++ standard library?  For example, do we need to implement our own
> reference counted objects, or could we just build atop the standard
> libraries shared_ptr, weak_ptr objects?  I recognize that those didn't
> exist when Octave started, but we should take advantage of what is out
> there now, rather than rebuilding the wheel.  Similarly, the C++ libraries
> have quite a few functions for threaded applications such as the <atomic>,
> <mutex>, <future> headers.  Is there something to grab from them?
> Underlying all this is my sense that we shouldn't need to roll our own code
> here and that the libraries will be high performance.

I agree that we should use standard library features where possible.

jwe