[ET Trac] #2626: Multipole is not OpenMP parallelized

[Ian Hinder]

#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-openmp-parallelized
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.einsteintoolkit.org/pipermail/trac/attachments/20220805/2461e8b7/attachment.html