[mesa-users] pgstar slowdown

Thu Dec 1 11:30:48 EST 2016

Hi
I'm planning to dig into this today.

Rob

On Thu, Dec 1, 2016 at 9:28 AM, Bill Paxton <paxton at kitp.ucsb.edu> wrote:

> Hi Frank,
>
> Thanks for adding the data.   Now I'll ask for more.  If not from you,
> then from someone.
>
> It would be very easy to separate the effects of file size vs graphics
> time.
> 1) leaving the file size fixed, only draw points for every nth step.  how
> much does that reduce the pgstar overhead?
> 2) now only write every nth step to the file.  how much does that change
> things after 10,000+ steps?
>
> As you know, it is amazing how much it helps to have some measurements of
> what you are trying to fix. ;)
>
> So how much of the problem is from file I/O and how much from graphics
> overhead?
>
> Another simple test would be to create a pgstar driver that plots lines
> with a variable number of points as a profile.
> That takes away the history I/O and gives a clean way to test the graphics
> overhead.
>
> I know you are familiar with all these tricks of the trade -- just wanted
> to put them out in an email to mesa-users.
>
> -B
>
>
> On Dec 1, 2016, at 5:51 AM, Frank Timmes wrote:
>
> > i'll add a data point to this thread.
> >
> > 25 msun, 79 isotopes from pre-main seqience to core-collapse in 14,415
> steps
> > on 12 cores (2.7 ghz xeon e5) under macos sierra with OMP_NUM_THREADS=12.
> > 9 plots on a grid, including two history style plots, kipp and TRho.
> >
> > no pgstar: 7 hr 14 min
> >
> > pgstar with png file output only: 8 hr 25 min
> >
> > pstar with png file and xquartz screen output: 8 hr 54 min
> >
> > for this run, the  ~100 min difference between
> > no pgstar and pgstar with everything is ~20%.
> >
> > fxt
> >
> >
> >
> >
> >
> >> On Nov 29, 2016, at 3:06 PM, Bill Wolf <wmwolf at physics.ucsb.edu> wrote:
> >>
> >> For what it’s worth, I’ve had similar situations with my home
> workstation, and it seems to stem from drawing to the screen and the
> particularities of AMD graphics cards.
> >>
> >> My machine has an 8-core AMD processor and an AMD R9 270 graphics card.
> Normally I wouldn’t think those details matter, but I noticed MESA star
> wasn’t quite as blazing fast as I had hoped. Running the standard star/work
> case takes roughly twice as long with pgstar on vs off. (!)
> >>
> >> After much frustration, I found that upgrading to the closed source
> “catalyst” graphics card driver solved the problem, but introduced many
> not-so-nice aspects to the system as a whole like having to downgrade xorg.
> This eventually led to the bricking of my xorg installation, prompting me
> to return to the open source radeon driver and slower pgstar performance.
> >>
> >> Leaving one core free (export OMP_NUM_THREADS=7) helped a little, but
> still pgstar was hogging a lot of resources or making some sort of bottle
> neck. I’m hoping the new open source AMDGPU driver will fix this when I can
> use it in linux 4.9, but I’m not holding my breath.
> >>
> >> ________________________
> >> William Wolf
> >> wmwolf at physics.ucsb.edu
> >>
> >> UCSB Department of Physics
> >>
> >> On November 28, 2016 at 1:14:50 PM, Robert Farmer (rjfarmer at asu.edu)
> wrote:
> >>
> >>> 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
> >>>
> >>>
> >>> ------------------------------------------------------------
> ------------------
> >>> _______________________________________________
> >>> 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
> >
> >
> > ------------------------------------------------------------
> ------------------
> > _______________________________________________
> > 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/20161201/d5dcf92f/attachment.html>