#2626: Multipole is not OpenMP parallelized
Reporter: Gabriele Bozzola Status: new Milestone: Version: Type: enhancement Priority: trivial Component:
Comment (by Ian Hinder):
When you say that Multipole is taking 1-2% of the execution time in your BBH simulation, I would say:
1. That’s not very much :slight_smile: 2. It is possible that what the timer is measuring is the time spent on one process waiting for the other processes to catch up. If you want to know, you can set `Carpet::schedule_barriers` = yes and `Carpet::`sync_barriers` = yes` and then look at the timer output for the barriers.
In general, I would only invest time in optimising if you have profiled first. So if you have measured that the integration loops are taking a significant amount of time, then by all means parallelise them. They don’t scale with the grid resolution (unless you manually scale the angular resolution parameters), and I would expect interpolation to be by far the dominant cost here.
Having said that, since it’s just adding one pragma, maybe it’s not worth investigating too much :slight_smile:
-- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2626/multipole-is-not-o...