Re: Performance hit with --enable-atomic-refcount

[Daniel J Sebald]

On 06/09/2014 11:04 AM, Michael Goffioul wrote:
> On Mon, Jun 9, 2014 at 11:38 AM, Daniel J Sebald <address@hidden
> <mailto:address@hidden>> wrote:
>
>     On 06/06/2014 12:40 PM, Rik wrote:
>
>         6/6/14
>
>         All,
>
>             >From the previous benchmarking, there was a doubling in execution 
> time from
>
>         3.8.1 to the gui-release branch for a nested for loop.  It turns
>         out that
>         this doubling is 100% correlated with using the
>         --enable-atomic-refcount
>         option to configure.  I built the gui-release branch with this
>         feature
>         disabled and the results are then equivalent to the 3.8.1
>         release.  It
>         seems like we need to explore a different solution than this
>         configure
>         option so that we can both use Qt graphics and have reasonable
>         performance.
>
>
>     The attomic reference count is, from what I understand, needed for
>     the QtHandles code, which implements script callbacks (I say "script
>     callbacks" to differentiate from source code callbacks).  Atomic
>     reference isn't needed for Qt graphics without that.
>
>
> No, atomic reference is a way to implement seamless concurrent access to
> octave_value objects (and other ref-counted objects), between the UI
> event loop and the octave thread.

Sure.  The question is, Why should the GUI have free access to 
octave_value objects in the worker process?  Why do we want that model? 
 I know there are some who feel the GUI and octave core should be 
indistinguishable, but that, to me, is the wrong way to go.  The bigger 
risks are a lot of management of when memory is accessed between the 
worker and GUI.  I understand the advantages of reference counting which 
is safe across threads, but are those advantages appropriate for the 
GUI/worker model.  If there were some multitasking going on, spreading 
computations across multiple cores, or something like that I could see 
the need for it.  But the GUI is more a reflection of what is happening 
inside the worker and possible adding some graphical features.  It's not 
taking on any of the workload.

There are thousands of hours of development in a parser and memory 
management, why not use it?  If the GUI wants to set x(1,2) to 24, send 
command "x(1,2) = 24;".  If the GUI wants to know x(1,2), issue command 
"x(1,2)" and get the result.  The latter, i.e., returning the result to 
the GUI, is the missing piece at this point, but I believe it is pretty 
straightforward to add.  There's a lot of versatility and power in the 
language that can be utilized already.  Want to know the breakpoints? 
Issue "dbstatus()" and the GUI interprets the result.

Dan