Author: Robert Hyatt
Date: 12:45:42 01/15/06
Go up one level in this thread
On January 15, 2006 at 12:36:30, Rolf Tueschen wrote: >Excuse me that I as nobody come into that parallelism debate. I have a general >question for you that could make things better understandable IMO. > >Often I read here messages of tht sort that such and such result could not be >used at all because this isnt regulated etc. pp. > >Let me ask you a basic question to your classes. If you want to make students >understand that they can make experiments and can compare the results - ALTHOUGH >as you just mentioned, even the very same behavior cannot be expected in case of >parallel processors, how do you do that education? What is the important point >to understand, so that it's then almost easy to understand? In general it's the >question if and when, under what conditions, one is allowed to make conclusions, >in what form, and when it's no more allowed? > >Could you give a couple of statements? - I ask because I come from a little >debate with Albert, who is doubting that a little test by Marc would make no >sense insofar one couldnt take the results into any other area. I said that his >experiment and also the results of course had a meaning. Could you perhaps >include that totally different question into your explanation? What is data >worth and what can we do with it furthermore? > >Thanks. Here is what I usually tell 'em. 1. Change only one thing at a time. If you change two things, then how can you decide which of the two changes was good and which was bad? Students are bad about changing everything, particularly when trying to work on a parallel program, and then they can't figure out whether change A made things better or worse. And usually, if the "whole mess" looks better, they keep it all, even though one of the changes actually hurt, and fixing it would further improve things. 2. Parallel programs should, ideally, be 100% deterministic in their behavior. And I could do this in chess. In fact, I've done it before. But the problem is that introduces _severe_ performance issues that make the deterministic parallel search produce not-so-good speedups. So to overcome that synchronization overhead, I get rid of it, which lets the threads modify the hash table in various orders that change each time the thing gets run. Faster overall, but now the results are more variable, which leads to the issue at hand. When I first parallelized Crafty (and you can see this in the comments in main.c, where I first did a much restricted parallel search to provide far more deterministic behavior (not perfectly deterministic however) so that I could debug the thing easier. Once that appeared to work, I'd relax things a step farther, and see both the speed and variability of results increase. Until eventually I "unleashed the whole thing" for max performance but also max non-deterministic behavior... I give a parallel program dealing with simulating blackjack (a hobby of mine) and the most challenging thing to the students is to make the program produce _identical_ results with 1, 2, ... and N processors. That is an interesting assignment when the entire simulation is based on random numbers. And once they get this to work properly, they have a good understanding about non-deterministic behavior, why it is bad, but also why it is sometimes useful.
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.