| Title: | Digital Extended Math Library |
| Notice: | Kit locations: 9.last (UNIX), 10.last (VMS) |
| Moderator: | RTL::CHAO FGREN |
| Created: | Mon Apr 30 1990 |
| Last Modified: | Tue Jun 03 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 324 |
| Total number of notes: | 1402 |
I'm using the routines dgetrf and dgetri to invert a nxn matrix where nmax is ~ 300; as compared to the original code, which looks like a numerical-recipe one, DXML gives a 2 to 3 X improvement. However when using the parallel version of dxml there is no speed-up at all for 2 to 4 cpu's (Rawhide @ 400 MHZ, Unix 4.0b, dxml 3.3 ). Are there any known facts on these routines ? I have used a KMP_STACKSIZE of 10m If this is known not to work an alternative might be to seek coarser grain parallelism using KAI KPTS and calling the SERIAL version of dgetrf any comments are welcome /Joseph
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 317.1 | HPCGRP::MANLEY | Tue Mar 25 1997 16:27 | 10 | ||
DGETRF has been parallelized, DGETRI has not, and probably never will be. DGETRI overwrites the matrix factored by DGETRF, making a straight forward parallelization - very very tricky at best. If you really need a matrix inverse (and many applications using them do not), you can use DGETRF to factor the matrix and DGETRS to solve a linear system with an identity matrix as its right hand side. Although DGETRS has not itself been parallelized, it uses the parallel DGEMM and so shows some speedup. | |||||