we are using several independent Gecode solvers in one program, and we want to run them in parallel, in different threads. It works correctly, but is extremely slow: running N solvers in parallel, each solver slows down by at least a factor of N. This alread occurs for N=2, on servers with many cores and with large memory.
The reason seems to be the global variable for memory management, as mentioned in Section 31.1 "Memory areas" in the "Modelling and Programming with Gecode". So the different threads, which in our cases need to acquire a lot of heap memory, have to go through this single resource, and thus are permanently blocking each other.
So apparently we need to write a custom memory allocator, as mentioned at the end of Section 31.1. Unfortunately not much further information is given. Our task should be very simple: we just want to turn the global variable
Heap heap;
(line 44 of heap.cpp in gecode.org/doc/6.2.0/reference/heap_8cpp_source.html )
for heap management into a local one, so that each thread can use its own heap management.
We don't have yet any experience with doing such things. We would be thankful for any help!
With best regards
Oliver Kullmann
thanks for the prompt answer.
I installed now 6.3.0, which worked find (just using "./configure; make; sudo make install").
But now trying to compile our code I get the following error:
/usr/local/include/gecode/kernel/gpi.hpp: In member function ‘Gecode::Kernel::GPI::Info* Gecode::Kernel::GPI::allocate(unsigned int)’:
/usr/local/include/gecode/kernel/gpi.hpp:190:50: error: ‘memory_order_seq_cst’ is not a member of ‘std::memory_order’
190 | c->init(npid.fetch_add(1, std::memory_order::memory_order_seq_cst),gid);
Apparently the compilation used -std=c++17 throughout, while we are compiling our code with -std=c++20 (gcc 10.3.0).
According to
en.cppreference.com/w/cpp/atomic/memory_order
it should be either
std::memory_order_seq_cst
or
std::memory_order::seq_cst
but not
std::memory_order::memory_order_seq_cst
??
Best
Oliver
thanks, now everything worked: and running the parallel threads now seems to work well!
You wrote
"This was very useful in cases where very many propagators were created quickly."
And that was likely the problem (we perform many look-aheads, by just copying the space).
Thanks a lot!
Oliver
To view this discussion on the web visit https://groups.google.com/d/msgid/gecode/CAPKxCj47T0-YhsD9Mo-Rs-my2t%3DGhYFOE1CDymiMprujM0ZJvg%40mail.gmail.com.