Parallel solving Ax=b? 
Cross posted on StackOverflow.

I have some extremely large sparse matrices created using spMatrix function from the matrix package.
Using the solve() function works for my Ax=b issue, but it takes a very long time. Several days.
I noticed that http://cran.r-project.org/web/packages/RScaLAPACK/RScaLAPACK.pdf appears to have a function that can parallelize the solve function, however, it can take several weeks to get new packages installed on this particular server.
The server already has the snow package installed it.
So


*

*Is there a way of using snow to parallelize this operation? 

*If not, are there other ways to speed up this type of operation?

*Are there other packages like RScaLAPACK? My search on RScaLAPACK
seemed to suggest people had a lot of issues with it.


Thanks.
Additional details


*

*The matrices are about 370,000 x 370,000. I'm using it to solve for
alpha centrality, http://en.wikipedia.org/wiki/Alpha_centrality. 

*I was originally using the alpha centrality function in the igraph
package, but it would crash R.

*This is on a single machine with 12 cores and 96 gigs of memory (I believe)    

*It's a directed graph along the lines of paper citation
relationships.

*Calculating condition number and density will take awhile. Will post
as it comes available.

 A: Have you tried QR decomposition?  See Theorem 3 here for solving $Ax=b$.
Finding the inverse of a matrix (even a small one) is a slow process.  Methods such as QR or Cholesky decomposition are used in practice when 'inverting' is needed (at least in my experience in statistical programming).
A: You can decompose this operation into a set of smaller operations that are easy to parallelize.
Suppose you wish to solve $\mathbf{m}\mathbf{v}=\mathbf{u}$ for an $N$ by $N$ matrix $\mathbf{m}$ and $N$-vector $\mathbf{u}$.  Writing $N=n+m$ (intending $n\approx m$), decompose $\mathbf{m}$ into four blocks $\mathbf{a}_{n \times n}$, $\mathbf{b}_{n \times m}$, $\mathbf{c}_{m\times n}$, and $\mathbf{d}_{m \times m}$, and also decompose $\mathbf{u}$ into its first $n$ components $\mathbf{e}_n$ and its last $m$ components $\mathbf{f}_m$ while similarly expressing $\mathbf{v}$ as the concatenation of the $n$-vector $\mathbf{x}$ and the $m$-vector $\mathbf{y}$.  The original system is readily seen to be equivalent to the sequence
$$\eqalign{
\mathbf{a} \mathbf{z} &= \mathbf{e} \\
\mathbf{a} \mathbf{w} &= \mathbf{b} \\
\left(\mathbf{d}-\mathbf{c}\mathbf{w}\right)\mathbf{y}& = \mathbf{f} - \mathbf{c}\mathbf{z} \\
\mathbf{a}\mathbf{x} &= \mathbf{e} - \mathbf{b}\mathbf{y}
}$$
The first two form $m+1$ systems of $n$ equations (having a common matrix); the third is a single system of $m$ equations (depending on the solutions to the first two); and the last is a single system of $n$ equations (depending on the solution to the third).  By choosing $m \approx n \approx N/2$, you have reduced the sizes of the matrices involved and you have created an opportunity to run the first $m+1$ systems in parallel.  If this is not enough, the technique can be applied recursively.
This approach works no matter what algorithm for solving a linear system you may favor.
