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

[Daniel J Sebald]

On 06/09/2014 01:33 PM, Michael Goffioul wrote:
> On Mon, Jun 9, 2014 at 1:34 PM, Daniel J Sebald <address@hidden
> <mailto:address@hidden>> wrote:
>
>     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>
>         <mailto: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?
>
>
> To plot them.

Plotting is good, but the alternative is to request of the core (say 
day, temperature, and rainfall exist in memory):

put "day" into interpreter queue
(copy result local to GUI memory)
put "temperature" into interpreter queue
(copy result local to GUI memory)
put "rainfall" into interpreter queue
(copy result local to GUI memory)

or there is the alternative of using the plot command:

put "plot(day,temperature,'g',day,rainfall,'b')" into the interpreter queue

Of course, the drawback is that these variables cannot be accessed when 
the worker is busy processing some other possibly lengthy command. 
That's bad from the standpoint that it hurts interactivity a bit.  Is 
the requirement that data be accessible while Octave is processing? 
(Question for everyone.)

Dan