threads vs processes

[bob]

I just converted Crafty back to posix threads since we now have a decent POSIX threads library that replaced the old linux threads package. Took under one hour for reference, to show how close the two approaches are... Performance difference is exactly zero, except that EGTB is more efficient with threads since it then uses a shared LRU buffer chain which cuts down on I/O significantly as opposed to using 4 or 8 distinct buffers, one for each process.

[sje]

Relative efficiency is rather dependent upon the underlying OS implementation. Linux treats threads as lightweight processes, so there may not be much difference there. However, other systems like OpenBSD have a higher per process overhead, so threads could be the better deal.

[bob]

Relative efficiency is rather dependent upon the underlying OS implementation. Linux treats threads as lightweight processes, so there may not be much difference there. However, other systems like OpenBSD have a higher per process overhead, so threads could be the better deal.

I've run on all of 'em. Since copy-on-write was implemented in every paging system I have seen in the past 5+ years, I don't see any difference, except in the overhead to create the processes. Which I do exactly once in a game, so this means nothing. And the overhead between the linux Clone() (lightweight process creation) system call and the BSD fork() is _very_ minimal as it is, since the entire virtual memory address space is not duplicated on a fork() call today. In fact only the process table/descriptor/etc stuff is copied until a page of the virtual address space is modified by either process/thread...

[Zach Wegner]

But isn't the main difference the fact that you can get rid of the BOARD * with processes? I wouldn't expect any sort of speed difference otherwise.

[bob]

But isn't the main difference the fact that you can get rid of the BOARD * with processes? I wouldn't expect any sort of speed difference otherwise.

I can't, no. I still split inside a process to get other processes to help, so I have to carry the board pointer around everywhere. When I split, I allocate split blocks for each process/thread that will be working to help, which needs the pointer to the (in the case of Crafty) TREE structure which contains the board and anything else that a thread might update when searching.

[Graham Banks]

Loop came out at one stage as being able to use either threads or processes.
It performed better using threads.

[beachknight]

Do I understand right? A new release of Crafty is on the sight?

best,

[bob]

Loop came out at one stage as being able to use either threads or processes.
It performed better using threads.

I can't imagine why. These are two different ways to implement the same exact algorithm. As I mentioned, it took under an hour to convert back from processes to threads. It took about the same amount of time to convert to processes a couple of years ago...

[bob]

Do I understand right? A new release of Crafty is on the sight?

best,

Once we verify that the windows version works, yes, although it is not very different from the released 22.1 except for this thread issue that should clean up all the issues with "smpnice=1" under windoze.

[LoopList]

In order to get rid of the "board" pointer I implemented parallel processes. The engine became 10% faster in 32-bit mode and even 5% faster in 64-bit mode. But starting and terminating multiple slave processes is quite more complicated and ugly. Therefore the thread-powered engine with the additional "board" pointer was easier to develop and cleaner to tune. Furthermore, by using the "board" pointer I had the possibility to organise the "board"-class with private and public members. Passing "board" via const pointer enabled further security enhancements!

And DTS-like techniques are much too comlicated to be based on processes - communication overhead will increase compared to multiple threads. At least my research had shown me these results, perhaps I am wrong...

Fritz (Loop)