octave-maintainers
[Top][All Lists]
Advanced

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

Re: Thread-safety issues in QtHandles


From: Michael Goffioul
Subject: Re: Thread-safety issues in QtHandles
Date: Sat, 3 Dec 2011 15:25:14 +0000

On Sat, Dec 3, 2011 at 10:47 AM, John W. Eaton <address@hidden> wrote:
> On 28-Nov-2011, Michael Goffioul wrote:
>
> | On Mon, Nov 14, 2011 at 7:48 PM, Michael Goffioul
> | <address@hidden> wrote:
> | > On Wed, Nov 9, 2011 at 1:13 PM, Michael Goffioul
> | > <address@hidden> wrote:
> | >> Here's a complete patch for octave, implementing this new approach.
> | >> It's obviously less intrusive than the previous one; I made it
> | >> configurable and disabled it by default. I tested it on Linux and
> | >> although it's probably not as bullet-proof as using shared_ptr, it
> | >> seems to provide a level of safety that is satisfying for QtHandles: I
> | >> tried to launch mirone a couple of times and didn't get any crash. I
> | >> also timed it on Linux (compiled with "-g -O2"): without the patch,
> | >> the test suite runs in 94.53s, with the patch, it runs in 111.93s
> | >> (that is ~17% increase).
> | >
> | > Any update on this one?
> | >
> | > Did anybody give it a try, for instance on amd64 or Mac OS X?
> | >
> | > Michael.
> |
> | Ping?
> |
> | Is it deemed to be left in limbo?
>
> Sorry for the delay.
>
> On my system with the current sources from the mercurial archive, I
> see the following time for running the tests (default -g -O2 compiler
> options):
>
>  62.17user 13.01system 1:21.17elapsed 92%CPU
>
> With your thread_safe_refcount2 patch applied and using the
> --enable-atomic-refcount configure option, I see:
>
>  71.35user 13.07system 1:29.95elapsed 93%CPU
>
> That gives total CPU times of 75.18 (without) vs. 84.42 (with), or
> about 13% longer to run the tests with the atomic refcount code
> enabled.
>
> That still seems like a large penalty, but I agree with Michael
> Godfrey that it is OK to apply now, but should perhaps be left
> disabled by default for the 3.6 release.

I've submitted it and it's disabled by default:
http://hg.savannah.gnu.org/hgweb/octave/rev/43cc49c7abd1

Just for the record, it wouldn't be the only slowdown with recent
changes if you compare the timing given by Soren in those 2
references:
https://mailman.cae.wisc.edu/pipermail/octave-maintainers/2011-November/025667.html
https://mailman.cae.wisc.edu/pipermail/octave-maintainers/2011-November/025675.html
Though that 10% (edge case) slowdown went unnoticed.

Michael.


reply via email to

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