Sharing a random stream harvest among threads

Bruce_Weaver · ‎03-25-2013

Hi,

For issues of memory and simplicity, I'd like to share random number stream harvests among threads. I don't care if, occasionally, a thread gets the 'wrong' or same random number as another thread because the index has not been bumped yet. That is, the threads would share the index into the stream and the stream. When any thread noticed the index becoming close to the end of the stream, it would invoke a continuation of the stream.

My attempts to implement this have the program blowing off w/ no diagnostics or references to irrelevant lines of code. Could it be that the VSL routines save data which becomes corrupted if there are multiple threads accessing the code simultaneously? Wouldn't this also be a problem if I gave up on this approach and set the indicies private?

thanks,

Bruce

SergeyKostrov · ‎03-26-2013

>>My attempts to implement this have the program blowing off w/ no diagnostics or references to irrelevant lines of code. >>Could it be that the VSL routines save data which becomes corrupted if there are multiple threads accessing the code >>simultaneously? Wouldn't this also be a problem if I gave up on this approach and set the indicies private? I have a couple of questions: - Do you use MKL? - Did you try your tests in Debug configuration? What compiler, IDE and platform do you use? Thanks.

Bruce_Weaver · ‎03-26-2013

Hi,

Yes, I'm using MKL (parallel). I am doing them in Debug. VS 2010; latest Intel software, Dual E5-2690 with windows 7.

SergeyKostrov · ‎03-26-2013

Hi Bruce and Thanks for additional information. >>...That is, the threads would share the index into the stream and the stream. When any thread noticed the index becoming >>close to the end of the stream, it would invoke a continuation of the stream... I think as soon continuation of the stream starts all the threads should pause until that procedure is completed. Some synchronization object, a mutex, an event or a critical section, needs to be used. If you don't do this ( that is, threads pause ) then any thread could try to access some position in the stream which is still Not Ready for processing and has junk / uninitialized data. Does it make sense?

jimdempseyatthecove · ‎03-27-2013

>>I don't care if, occasionally, a thread gets the 'wrong' or same random number as another thread because the index has not been bumped yet.

I assume you want performance. Asume also it is not important for the end of life of use of a random number by a specific thread be the same sequence as the beginning of life of use of a random number.

Then have each thread use their own random number generator who's initial seed is dependent upon thread number or thread ID in a manner such that collisions initially at large intervals (or not at all).

Jim Dempsey

Bruce_Weaver · ‎03-27-2013

Thanks for your thoughts.

Sergey: I use lots of random numbers throughout the code. If I have to stop everyone for each call, it would be hopeless. Note that the Fortran RAN intrinsic works fine, however the low quality of the sequence kills the convergence after a few hours.

Jim: I'm not sure I exactly understand "not important for the end of life of use of a random number by a specific thread be the same sequence as the beginning of life of use of a random number." I have thought of using different random number generators (well, same generator, different seeds) and I'm getting close to trying that. There are some reasons to try the shared stream approach and I'm not sure why that doesn't seem to work. It seems that the threads should be able to share the stream...but perhaps not. ANd yes, it is ALL about performance...this code takes days to run and we're about to expand its range significantly.

thanks again, Bruce

SergeyKostrov · ‎03-28-2013

>>...If you don't do this ( that is, threads pause ) then any thread could try to access some position in the stream which is >>still Not Ready for processing... Bruce, I think it would be nice to log into a txt-file values for indecies, thread numbers ( IDs ) and the size of the stream during processing. If you manage to record these values then you will be able to better anaylize and understand the problem. I could be wrong but I think you're dealing with Out-Of-Bound case.

Bruce_Weaver · ‎03-28-2013

Hi Sergey,

Yes, I did seem to have some out of bounds problems but I think I cleared them up before I started this thread. I'm going ot give it one more try and then fall back to making everything private and see if that works easily.

thanks

Bruce_Weaver · ‎03-28-2013

Hi all,

OK, I gave up for now and made'm thread private via a module and so far it seems ok...it'll take several hours to see if it converges properly.