octave-maintainers
[Top][All Lists]
Advanced

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

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


From: Rik
Subject: Re: Performance hit with --enable-atomic-refcount
Date: Fri, 06 Jun 2014 14:37:48 -0700

On 06/06/2014 01:16 PM, John W. Eaton wrote:
> On 06/06/2014 01: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.
>
> Here are the results I see.  I used default configure options in both
> cases except for specifying --prefix and --disable-atomic-refcount in one
> build.  I also used cputime instead of tic/toc, but that shouldn't be too
> important if your system is mostly idle when you run the tests.
>
>   with atomic refcount:     ~ 1.60 CPU seconds
>   without atomic refcount:  ~ 1.25 CPU seconds
>
> So I see a performance hit, but it is not a factor of 2.  I remember that
> we had some significant differences between our results the last time we
> looked at this, but the test then was running the test suite, not just a
> single nested for loop with an addition expression.
>
> I'm using gcc version 4.8.2 (Debian 4.8.2-1) on an amd64 system.  I
> didn't try to fix the CPU frequency as I'm not sure how to do that.
jwe,

I just re-compiled and re-checked the gui-release branch and I get the same
doubling in execution time.  My gcc version is 4.6.3 so perhaps they have
improved things.  The architecture is x86_64 which is another difference.

To set the cpu frequency I change the dynamic scaling governor to powersave
(usually meant for battery operation with lowest possible CPU frequency and
no dynamic scaling).  I'm attaching a script I wrote.  You will need to run
it as root.

cpufreq                    # with no arguments, print out the current
frequency and governor
cpufreq powersave # with an argument, set the governor or fix the frequency
to the number specified

--Rik

Attachment: cpufreq
Description: Text document


reply via email to

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