Author: Robert Hyatt
Date: 15:01:55 08/16/05
Go up one level in this thread
On August 16, 2005 at 16:56:18, Vincent Diepeveen wrote: >On August 15, 2005 at 21:25:42, Robert Hyatt wrote: > >>Thought I would answer this in public, rather than multiple times via email. >> >>"What did you have to do to get Crafty to work correctly on the new opteron?" >> >>The first thing was getting it to run, and AMD installed red hat linux >>(enterprise edition) on the box for me. My first quick "scaling tests" showed >>serious problems. Later it turned out that it was less about scaling and more >>about quirks in posix threads. Something is wrong with the posix threads >>version of the normal C library, in that it provides sporadic and flakey timing >>information. This made the scaling look bad, but in fact much of the problem >>was just a problem in the library somewhere. >> >>A couple of years back, I had already implemented a fork() version of the >>parallel search for some alpha testing I was doing, since they didn't have posix >>threads on their NUMA system. The basic idea is that I changed the malloc() >>calls to use shmget() and shmat() before forking processes. This creates >>shared-memory blocks that will remain shared after a fork(). The main change >>was that there were a significant number of global variables that are shared by >>default in posix threads. I had to collect all of those into a struct, and map >>the struct onto another shmget()/shmat() shared memory block. So the final >>result is that everything that was shared, still is shared. >> >>On linux it is also important to note that when you do a fork(), your virtual >>address space is not copied on the spot. Linux uses copy-on-write, which means > >What matters in linux is that when you fork() the processes in itself are in the >same virtual adress space, in contradiction to windows. > >That means for example that in linux if you the forked processes use shared >memory that has pointers in the shared memory that reference other shared >memory, that different processes can share those pointers. > >In windows this just is totally screwed up, to say polite. > >The only way to force shared memory in the 'same' virtual adress space is >by going via the page file, which means you get usually swapped by windows >real bad. > >So in linux this works far better thanks to fork() > >Vincent > Don't know much at all about windows and how it handles threads and processes. Linux I do know, obviously. The memory management there is pretty straight-forward once you start thinking about faulting things in rather than the actual malloc() stage which is irrelevant in the NUMA implementation on linux.
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.