With the refinements to the scenario there are further possibilities. First let me address parallelization in the general case. There are ways in which a Groebner basis routine (GB) can benefit. Some are in a sense speculative (try a few things, run with whatever returns first) and some have more to do with deep-down internals e.g. if linear algebra is being used under the hood. Given that GroebnerBasis
will use exact arithmetic in the setting described, even if the Groebner walk gets used, the linear algebra will not likely use parallelization (and if it does, I doubt it will help much).
Next, in the case where some or all equations are linear, I believe Solve
and NSolve
will in effect use substitution to reduce the number of equations and variables. I do not know offhand if this requires an equation be linear in all variables though. If the entire set is linear, Solve
will recognize this and use linear algebra exclusively, so no GB computation.
If the system is exactly determined, that is, finitely many solutions, and numeric solutions suffice, then NSolve
or FindRoot
become viable alternatives to Solve
. The former can be directed to use a sparse homotopy method (I forget the option setting that enforces this). This method uses path tracking for each solution. A benefit is that this step is parallelized across CPUs. That stated, if your system is massive, methods that attempt to find all solutions might fail to complete in reasonable time. If you can live with individual solutions, FindRoot
is a good bet.