Added parallelism to Algorithm=>LinearAlgebra strategy for Groebner bases

[mikestillman]

This PR adds in parallelism for gb(I, Algorithm => LinearAlgebra), for homogeneous input over finite fields.

[mikestillman]

This pull request (by @moorewf and myself) only touches code that has been experimental, at least I think so (EDIT: not exactly). It is a draft PR until we check that. I hope that it can make it into this release. On some examples it is the fastest known algorithm (to us), and on some examples, it falls short of mathicgb and msolve algorithms (but isn't too far away).

If it pasts tests, and we make sure no cruft code has been added in, then hopefully it should be good to accept this PR.

[mahrud]

Is debug output being on by default in a multi-threaded algorithm intentional?

i1 : elapsedTime gb(ideal vars(QQ[x]), Algorithm => LinearAlgebra);
 -- warning: gb algorithm requested is experimental
Quad matrix sizes
sizes of quad matrix
                     0          1
          0          A          B
          1          C          D

Quad matrix entries (no diagona on A)
                     0          1
          0          0          0
          1          0          1

mNumThreads: 8
About to do serial loop, n_newpivots = -1
 finding new spair time             = 2.805e-06
 number of spairs in queue          = 1
 insert new gb time                 = 1.438e-06
 -- .00479404s elapsed

Also, this doesn't seem to be a new problem, but neither gens not leadTerm seem to work for the resulting groebner basis:

i1 : leadTerm gb(ideal vars(QQ[x]), Algorithm => LinearAlgebra);
...
stdio:1:8:(3): error: unknown engine error

i2 : gens gb(ideal vars(QQ[x]), Algorithm => LinearAlgebra);
...
-- SIGSEGV
-* stack trace, pid: 3127853
 0# stack_trace(std::ostream&, bool) at /home/mahrud/Projects/M2/quickfix/M2/Macaulay2/bin/main.cpp:136
 1# segv_handler at /home/mahrud/Projects/M2/quickfix/M2/Macaulay2/bin/main.cpp:258
 2# 0x00007F9705A4FD00 in /lib64/libc.so.6
 3# F4toM2Interface::to_M2_vec(VectorArithmetic const*, MonomialInfo const*, GBF4Polynomial const&, FreeModule const*) at /home/mahrud/Projects/M2/quickfix/M2/Macaulay2/e/f4/f4-m2-interface.cpp:126
 4# F4Computation::get_gb() at /home/mahrud/Projects/M2/quickfix/M2/Macaulay2/e/f4/f4-computation.cpp:101
 5# rawGBGetMatrix at /home/mahrud/Projects/M2/quickfix/M2/Macaulay2/e/interface/groebner.cpp:336
 6# interface_rawGBGetMatrix at /home/mahrud/Projects/M2/quickfix/M2/Macaulay2/d/interface.dd:3601
 7# evaluate_evalraw at /home/mahrud/Projects/M2/quickfix/M2/Macaulay2/d/evaluate.d:1428
...
25# readeval3(parse_TokenFile_struct*, char, parse_DictionaryClosure_struct*, char, char, char) at /home/mahrud/Projects/M2/quickfix/M2/Macaulay2/d/interp.dd:277
26# readeval(parse_TokenFile_struct*, char, char) at /home/mahrud/Projects/M2/quickfix/M2/Macaulay2/d/interp.dd:290
27# interp_process at /home/mahrud/Projects/M2/quickfix/M2/Macaulay2/d/interp.dd:621
28# interpFunc(ArgCell*) at /home/mahrud/Projects/M2/quickfix/M2/Macaulay2/bin/main.cpp:210
29# ThreadTask::run(SupervisorThread*) at /home/mahrud/Projects/M2/quickfix/M2/Macaulay2/system/supervisor.cpp:359
30# SupervisorThread::threadEntryPoint() at /home/mahrud/Projects/M2/quickfix/M2/Macaulay2/system/supervisor.cpp:404
31# SupervisorThread::threadEntryPoint(void*) at /home/mahrud/Projects/M2/quickfix/M2/Macaulay2/system/supervisor.hpp:89
32# GC_inner_start_routine in /home/linuxbrew/.linuxbrew/opt/bdw-gc/lib/libgc.so.1
33# GC_call_with_stack_base in /home/linuxbrew/.linuxbrew/opt/bdw-gc/lib/libgc.so.1
34# start_thread in /lib64/libc.so.6
35# __clone3 in /lib64/libc.so.6
-- end stack trace *-

Process M2 exited abnormally with code 1

The gens crash seems to be because I used QQ but the lengthLimit engine error persists over finite field as well.

[mikestillman]

No, I made it a draft pull request to be able to easily see what accidentally got changed, while we were debugging, and also to make it easier to view. I'm also thinking this doesn't need to be in the upcoming release. @moorewf What do you think?

[moorewf]

I agree, it doesn't have to be in this release.

As for the output, it should only be putting out that information with gbTrace >= 2 (or higher) enabled, so that's a mistake. Also, the front end shouldn't be calling the new multithreaded LinearAlgebra code at all if the coefficients are not a finite field (right?), so we need to change that as well.