Opened 13 years ago

Closed 13 years ago

#243 closed bug (wontfix)

Multithread keyword slows down USANS simulation

Reported by: srkline Owned by: ajj
Priority: minor Milestone: USANS Reduction 2.3 Release
Component: USANS Reduction Keywords:
Cc: Blocking:


Using the MultiThread? keyword instantly threads all of the AAO function calculations. I've added this to everything that uses any integration. Even for a 100 data points, it produces a speedup near 0.9xN,as expected. Functions with no integration suffer a speed penalty, so the keyword is not used here.

The issue of the ticket is that the USANS Simulation is necessarily a point-by-point calculation, and uses qtrap() for the integration. So here it is trying to thread a single point, and the penalty is severe.

Moving the simulation to use the matrix is unlikely (can't extrapolate, different count times per point, etc.). What's the workaround?

Change History (1)

comment:1 Changed 13 years ago by srkline

  • Resolution set to wontfix
  • Status changed from new to closed

Upon some further testing - it really depends on the model parameters that go into the simulation. So I suspect that it's just the old, slow adaptive integration that is most of the slowdown. Wasted time in threading isn't helping, but doesn't seem to be major. Cylinder and Cyl_PolyRadius simulations were 5s - 20s depending on the parameters. These are both multithreaded. Even Fractal (which is not multi-threaded) still took about 5s for the simulation depending on the parameters.

So I say shelve this for now. The MutliThread? benefit far outweighs the few seconds lost in the USANS Simulation.

Note: See TracTickets for help on using tickets.