Re: slow execution of built executables on a Mac

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 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 mailto:ben@well-typed.com> wrote: Richard Eisenberg mailto:rae@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@haskell.org mailto:ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs