michiguel wrote:You are saying that everything that has been allocated with malloc() is copied when processes are launched? that was my original question simplified.
Miguel
Ahhh, I see. Then the answer is:
Yes for Linux (including the malloc'd memory)
No for Windows. (no memory, not even malloc'd)
Windows programs can create new child processes (of course) but Windows doesn't have (an exposed API) for creating a child process with a copy of any of the memory from the parent (except for inheriting things like environment variables, security descriptors, etc).
In Windows, you will need to use shared memory for the hash tables.
There is a project on SourceForge that has a Win32 version of fork(): http://pw32.sourceforge.net/
Not complete, and no 64 bit version. Just in case someone wants to fool around with the basic ideas.
Cygnus can also do a fork() on Windows.
However, since Windows was not designed to do fork() by the OS, in Windows, the Cygwin fork() performs very slowly compared to real POSIX.
michiguel wrote:You are saying that everything that has been allocated with malloc() is copied when processes are launched? that was my original question simplified.
Miguel
Ahhh, I see. Then the answer is:
Yes for Linux (including the malloc'd memory)
No for Windows. (no memory, not even malloc'd)
Windows programs can create new child processes (of course) but Windows doesn't have (an exposed API) for creating a child process with a copy of any of the memory from the parent (except for inheriting things like environment variables, security descriptors, etc).
In Windows, you will need to use shared memory for the hash tables.
There is a project on SourceForge that has a Win32 version of fork(): http://pw32.sourceforge.net/
Not complete, and no 64 bit version. Just in case someone wants to fool around with the basic ideas.
Cygnus can also do a fork() on Windows.
However, since Windows was not designed to do fork() by the OS, in Windows, the Cygwin fork() performs very slowly compared to real POSIX.
Summarizing: making something portable for Windows and Linux using threads is relatively simple (even I have done it), but for multiprocessing (which I do not have experience) seems to be a mess. Considering that there are only two programs that may use multiprocessing, I should consider to give a very low priority for the Gaviota Tablebases to support that. Worst case scenario if those two programs want to use them, they are not going to be worse than Nalimov's in this respect.
If someone wants to convince me on the contrary, I am willing to listen.
michiguel wrote:...but for multiprocessing (which I do not have experience) seems to be a mess.
Well... I don't know if I would go that far.
The underlying issue here was sharing memory between processes, for the purpose of sharing the EGTB cache. Unfortunately, an easy way to do this in Linux, by using fork(), isn't supported by Windows.
However this can still be done pretty easily, and in a portable way, using interprocess memory sharing techniques like memory mapped files.
That being said, threads might still be the best way to go for this particular problem.
"The foundation of morality is to have done, once for all, with lying; to give up pretending to believe that for which there is no evidence, and repeating unintelligible propositions about things beyond the possibilities of knowledge." - T. H. Huxley
michiguel wrote:You are saying that everything that has been allocated with malloc() is copied when processes are launched? that was my original question simplified.
Miguel
Ahhh, I see. Then the answer is:
Yes for Linux (including the malloc'd memory)
No for Windows. (no memory, not even malloc'd)
Windows programs can create new child processes (of course) but Windows doesn't have (an exposed API) for creating a child process with a copy of any of the memory from the parent (except for inheriting things like environment variables, security descriptors, etc).
In Windows, you will need to use shared memory for the hash tables.
There is a project on SourceForge that has a Win32 version of fork(): http://pw32.sourceforge.net/
Not complete, and no 64 bit version. Just in case someone wants to fool around with the basic ideas.
Cygnus can also do a fork() on Windows.
However, since Windows was not designed to do fork() by the OS, in Windows, the Cygwin fork() performs very slowly compared to real POSIX.
Summarizing: making something portable for Windows and Linux using threads is relatively simple (even I have done it), but for multiprocessing (which I do not have experience) seems to be a mess. Considering that there are only two programs that may use multiprocessing, I should consider to give a very low priority for the Gaviota Tablebases to support that. Worst case scenario if those two programs want to use them, they are not going to be worse than Nalimov's in this respect.
If someone wants to convince me on the contrary, I am willing to listen.
Miguel
A solution that seems workable to me is to used shared memory for the tablebase access.
In order to do this portably, a single API should be used.
Perhaps shmem from here: http://www.garret.ru/ipc.html
would be worth a look.
If it's not too much bother to do it that way, then it seems a worthwhile change.
