Scalablity for 1D tri-diagonal solver about hypre HOT 3 CLOSED

Hi Fei,

The main reason you are seeing this performance is that the problem size is already quite small. When you go from 1 process to multiple, you introduce communication, which is huge relative to the cost of computation. Things don't get much better from there because the problem size per processor gets smaller still as you increase the number of processors.

There are some things we could do in the implementation to improve performance at these small scales (such as implement a block version of cyclic reduction), but we don't have any plans to do that right now and I'm not sure the improvements would be that great anyway.

Try increasing the problem size and you should see better scaling. That may not be a helpful option for you, though.

-Rob

from hypre.

Thanks Rob! If the method I'm using right now is not a good choice, could you recommend other solvers in HYPRE that may suit for my small scale problem? I appreciate any suggestion and information.

from hypre.

No other suggestions in hypre. There may be some other software libraries out there that are more tuned for small scale parallelism that you could use. I know that some colleagues at LANL have implemented line smoothers that are more like the block approach I mentioned above. I don't know if that code is readily available though.

Part of what I am also trying to tell you is that the problem and hardware characteristics are largely to blame for your less-than-impressive speedups. This is independent of the solver used. Hardware today (and for many years actually) is much slower at communication than with computation. If communication latency was zero, then the cyclic reduction algorithm in hypre would give you beautiful speedup numbers.

from hypre.