slow execution of built executables on a Mac

[Richard Eisenberg]

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.

Here's the first bit:

Call graph:
880 Thread_2569398 DispatchQueue_1: com.apple.main-thread (serial)
+ 868 _pthread_cond_wait (in libsystem_pthread.dylib) + 732 [0x7fff51e2e589]
+ ! 868 __psynch_cvwait (in libsystem_kernel.dylib) + 10 [0x7fff51c65a16]
+ 11 exitTicker (in ghc-stage1) + 80 [0x106ad2c30]
+ ! 11 _pthread_join (in libsystem_pthread.dylib) + 626 [0x7fff51e31824]
+ ! 11 __semwait_signal (in libsystem_kernel.dylib) + 10 [0x7fff51c65d82]
+ 1 osDecommitMemory (in ghc-stage1) + 20 [0x106ad2fc4]
+ 1 madvise (in libsystem_kernel.dylib) + 10 [0x7fff51c66d0a]
880 Thread_2569402
+ 880 thread_start (in libsystem_pthread.dylib) + 13 [0x7fff51e2cbf9]
+ 880 _pthread_start (in libsystem_pthread.dylib) + 377 [0x7fff51e2d50d]

I also sampled gcc. Full output at https://gist.github.com/goldfirere/7316920ad37d776c25c15dbb0ed5996f <https://gist.github.com/goldfirere/7316920ad37d776c25c15dbb0ed5996f>

I'm utterly lost here, but the results suggest that the scheduler is at fault, somehow.

Does anyone have a next step to suggest?

Thanks,
Richard

> On Nov 7, 2018, at 6:23 PM, George Colpitts <george.colpitts at gmail.com> wrote:
> 
> Ben, yeah, good point, probabilistically speaking, a few stack traces are often all you need to pinpoint an egregious performance problem, at least that's been my experience. 
> 
> Richard, as you probably know, you can get stack traces by using the Activity Monitor, select a ghc process and choose sample process from the drop down of the gear icon on the left hand side of the top of the activity monitor. It also shows cpu times which may be helpful.
> 
> On Wed, Nov 7, 2018 at 7:10 PM Ben Gamari <ben at well-typed.com <mailto:ben at well-typed.com>> wrote:
> Richard Eisenberg <rae at cs.brynmawr.edu <mailto:rae at cs.brynmawr.edu>> writes:
> 
> > Sadly, none of the suggestions on this thread worked.
> >
> > But here is some more detail:
> >
> > - During stage-1, my machine's CPU is maxed out (or nearly so) in user mode.
> > - After stage-1 (most obviously during rts_dist_HC), my machine spends roughly 80% of its CPU in *system* mode.
> > - Testing on my other machine (which is slower, but much faster at building GHC), I never see high *system* percentages.
> > - Both machines use APFS, which was one candidate for the slowdown.
> > - The slow machine uses XCode 10.1; the fast one uses XCode 9.4.1
> > - The slow machine uses clang 10.0.0; the fast one uses clang 9.1.0
> > - `brew install gmp` on the slow machine tells me that gmp is already installed.
> > - As a reminder: the slow machine is macOS 10.13.6; the fast one is macOS 10.13.5. I don't wish to try upgrading the fast one... lest that slow it down!
> >
> > Does anyone have any insight?
> >
> Were you able to collect a few stacks from the slow processes? It sounds
> like the author of the original post was somehow able to do this. Under
> Linux I would just fire up perf and grab a system-wide profile. Knowing
> precisely what slow path you are hitting would help localize any
> possible problem in GHC.
> 
> Cheers,
> 
> - Ben
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs <http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20181109/6f27f277/attachment.html>