NOTES for Overall Results :

• The results were obtained for best Numerical Factor performance. One of the varying parameters was the blocksize. The other parameter was ordering option (serial or parallel). The runs were made for each of these ordering options (serial, wherever possible) and the option which gave the best scalability was chosen for reporting the results. The serial ordering option produces less fill-ins than parallel ordering option, in general.
• Most of today's parallel computers have communication subsystems which perform better for larger data being communicated. The blocksize optimal for Factor performance is usually smaller than that for the Triangular Solve performance (depending on the nrhs value). This is so, because Factor communicates b*b numbers whereas triangular solve communicates b*nrhs numbers, where b is the blocksize. Value of b=32 or b=64 usually worked best for the Numerical Factor phase, in our runs on all the platforms.

NOTATIONS Used :

  NNZ_LowerA : Number of nonzeros in Lower triangular part of A 
               (including diagonal).
  np         : Number of Processors.
  NNZ_L      : Number of nonzeros in L.
  Imbal      : Computational Load Imbalance due to supernodal tree structure.
  FAC_OPC    : Operation count for Numerical Factor phase.
  Ntime      : Numerical Factor Time (in seconds).
  Nperf      : Numerical Factor Performance (in MFLOPS).
  Ttime      : Redistribution of B + Triangular Solve Time for nrhs = 1.

Results on Cray T3E-1200 :

Notes :

• The machine had 512 MB on each node, out of which around 450 MB was available for user processes. For some cases (for example, TRAIN), the parallel ordering produced more fill-ins than can be handled by some processors' available memory; whereas for some cases (for example, CUBE100), the serial ordering option was not feasible because of limited memory available on a single node.
• The deterioration in Ttime scalability (after np=64), is due to the unscalability observed in the phase that redistributes B from user supplied form to form required internally by PSPASES. The reason was tracked down to the bad performance of available MPI library's collective communication calls. Also, in its current form, this redistribution code is not optimized for proper utilization of memory hierarchy. As time permits, we will try to supply an optimized version.

Results on SGI Origin 2000 :

Notes :

• For CUBE35, FORT50, and BCSSTK18, the best results obtained were with N32 code. For all other matrices, the best (or in some case, only possible) results were with 64-bit code.
• ** EPM denoted entries : The machine had a total of 8GB real memory available. Those cases where total factor memory required exceeded the available real memory, are indicated as EPM (Exceeded Physical Memory). In such cases, the runs completed because of the presence of swap space (a total of 8GB was available). We are reporting these numers merely to exhibit PSPASES' ability to solve large systems within reasonable time.