Performance problem, high system load

[csoeger]

I noticed that in some cases running the same example via GAP is much slower than running it with normaliz directly. One example is the 5x5 magic square which can be found in the normaliz examples. I also added a GAP version in the example dir of NormalizInterface.

The general behaviour is the same, so it really looks like the same computation. But in the evaluation of the simplices the system load goes up to 60% and it is noticably slower than using normaliz directly, where I cannot see a high system load.

I tried do the exactly same thing in GAP and directly. I used the normaliz executable which uses the same shared library, the same set of options, ... I also tried it with and without OpenMP.

Below are the timings:

./Normaliz.git/DST/bin/normaliz Normaliz.git/example/5x5.in -cq
211,97s user     0,34s system     99% cpu     3:32,33 total

 Runtimes();
rec( system_time := 583, system_time_children := 0, user_time := 3863, 
  user_time_children := 0 )
NmzHilbertSeries(5x5cone);
Runtimes();
rec( system_time := 353284, system_time_children := 0, user_time := 289599, 
  user_time_children := 0 )

In other examples I cannot see a difference in the running times. I will try to characterize for which cases this happens.

[csoeger]

We found the cause of the problem. gap is setting another allocator for gmp which does not perform well in this case. (mp_set_memory_functions in src/gmpints.c)
As a workaround we could reset it internally to the default before starting a libnormaliz computation.

[fingolfin]

I submitted a PR to GAP which removes the call to mp_set_memory_functions, see gap-system/gap#272 -- if that is accepted, it will be in GAP 4.8.0, and we won't have to do anything.

Otherwise, we may indeed need to (re)set the allocator before invoking any libnormaliz functions, and return it to the previous values afterwards.

[fingolfin]

The GAP PR I mentioned was merged, and will be in GAP 4.8.0; since I changed PackageInfo.g to require 4.8 for other reasons anyway, we should be able to close this issue now.

But perhaps Christof can test it once more, to make sure it is really gone?

[csoeger]

Yes, no problem there.