OK. I've posted a bug: https://ghc.haskell.org/trac/ghc/ticket/15891 <https://ghc.haskell.org/trac/ghc/ticket/15891>
Thanks much for the attempts thus far! Richard > On Nov 11, 2018, at 8:13 AM, George Colpitts <george.colpi...@gmail.com> > wrote: > > I couldn't duplicate this, when system times were high they were usually > between 20-40% which seems high but not 80%. I am on Xcode 10.1, macOS > 10.13.6 , a 4 core imac with 12 gb RAM and a hard drive not SSDs. I can't go > to Mojave as it is an old iMac. I did make -j5 using ghc 8.6.2. > > The Mac doesn't have truss or strace. It does have dtrace which I believe is > the equivalent. > > It might be good to open a ticket for this. As the description of how to > reproduce are a bit vague and the steps are manual, it would be ideal if > there were modified make file(s) to capture statistics using sample and maybe > dtrace or even time. > > Cheers > George > > > > On Sat, Nov 10, 2018 at 11:10 PM Ben Gamari <b...@well-typed.com > <mailto:b...@well-typed.com>> wrote: > Richard Eisenberg <r...@cs.brynmawr.edu <mailto:r...@cs.brynmawr.edu>> writes: > > > OK. Well, I couldn't sample from Activity Monitor, because the > > processes came and went too quickly. But the terminal command `sample` > > takes a *name* as an argument, and so passing ghc-stage1 worked > > nicely. Samples were taken during rts_dist_HC calls. > > > Hmmm, it looks to me like all of these are from GHC waiting on various > things (e.g. _pthread_cond_wait, nanosleep, and pthread_join). It's > quite surprising that these operations are chewing through cycles in > kernel mode. I wonder how rapidly we are context switching. Perhaps we > are quickly jumping between kernel and user mode? Perhaps strace (or I > think the OS X equivalent is truss?) will shed some light? > > Cheers, > > - Ben
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
