[mesa-users] pgstar slowdown

[Robert Farmer]

Hi

Thanks for the inlists, can confirm the cpu load of xorg is proportional to
the model number. I'll look into adding some new options to control the
number of points plotted and number of points saved to pgstar file.

Rob

On Mon, Nov 28, 2016 at 1:24 PM, Matthew Clayton <
matthew.clayton at exeter.ox.ac.uk> wrote:

> Hi there,
>
> Thanks for the quick replies.
> I've set up a minimum working example, for which inlists are attached.
>
> If I run this simulation to somewhere around 10,000 models, then after
> that point I can get of order x10 speed changes from turning the history
> summary window on and off when I have pgstar_cnt set to 1. Turning on a
> window with lots of profile plots does lead to a small slowdown, but only
> of about x1.3. (These performance changes are in terms of manually measured
> "time to calculate x number of models" metric)
>
> When I have the history summary window up giving a large slowdown, my Xorg
> process uses pretty much a whole core to itself, so that makes me think
> that's the bottleneck, in which case this would be a "drawing to screen"
> issue rather than a file reading issue? Though I fully admit I'm guessing
> there.
>
> The Summary_History_max_width option is quite a cool workaround as well,
> thanks for that.
>
> Cheers,
>
> Matthew
> ------------------------------
> *From:* Robert Farmer [rjfarmer at asu.edu]
> *Sent:* 28 November 2016 19:12
> *To:* Matthew Clayton
> *Cc:* mesa-users at lists.sourceforge.net
> *Subject:* Re: [mesa-users] pgstar slowdown
>
> Hi
>
> Interesting, i've never seen this but then i don't use the history summary
> plot. Part of the issue may also be how mesa handles the history data, it
> appends the data to a file called pgstar.data which is read in and used to
> make the history plots, while profile based plots dont have this issue
> because we can read the data from the current star model.
>
> There is Summary_History_max_width option which sets the number of history
> points to show a moving window (ie we show points between current
> model-width to current model) to stop you having to manually set the xmin
> option.
>
> Some plots already have controls to reduce the number of points plotted,
> so maybe we could look at extending that to other plots with a set of
> x_interval options to show only every x_interval point, if its really the
> drawing the points that is the issue.
>
> Can you send your inlists please?
>
> Rob
>
>
> On Mon, Nov 28, 2016 at 11:39 AM, Matthew Clayton <
> matthew.clayton at exeter.ox.ac.uk> wrote:
>
>> Hi all,
>>
>> I use pgstar a lot to see live plots of simulations I run, it's great. =]
>>
>> However, when running reasonably long (10k models +) simulations using
>> pgstar, I've noticed that it starts to use a lot of processor time* and
>> cause the simulation to slow down considerably (in a "factor of 10" kind of
>> sense). By turning different plots on and off I've been able to work out
>> that this is due to drawing plots like the summary history plot, which show
>> the past behaviour of the model (as opposed to, say a plot that shows a
>> profile through the current model). I think what's going on is that every
>> time the plot is updated, pgstar is drawing a point (or line segment) for
>> every model in the star's history, which eventually gets quite slow and can
>> lead runs to grind to a halt.
>>
>> I've been able to circumvent this problem by having the plots updated
>> less often (pgstar_interval = large number) or (in the case of the summary
>> history) manually truncating the plot to only show recent models (Summary_History_xmin
>> = slightly less than current model number), neither of which is very
>> satisfactory.
>>
>> I'm wondering whether anyone else is having this problem, or whether it
>> suggests that my X Window environment is set up in some inefficient way or
>> some such. If this is a general problem, is there a general workaround?
>> Perhaps pgstar could be made to only draw a certain maximum number of
>> points on any plot, and start missing out intermediate values if it's asked
>> to draw more than this number. Or maybe it does that already and my problem
>> is coming from something else. Either way, I'd welcome some input from
>> anyone who's experienced this issue or has ideas about how to fix it.
>>
>> Cheers,
>>
>> Matthew
>>
>> (obligatory data, in case it's relevant: I'm using version 7624 on an
>> Ubuntu machine)
>>
>> *Well, specifically it's Xorg using processor time
>>
>> ------------------------------------------------------------
>> ------------------
>>
>> _______________________________________________
>> mesa-users mailing list
>> mesa-users at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mesa-users
>>
>>
>
> ------------------------------------------------------------
> ------------------
>
> _______________________________________________
> mesa-users mailing list
> mesa-users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mesa-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20161128/d40dba28/attachment.html>