My biggest concern is that the mersenne twister requires about 2.5k worth of state. Reducing locking but taking on a bunch of extra state in a SimObject may very well make performance worse. So, it seems like premature optimization to me. (Also, you should checkout mt19937_64, it may suit us better). In the long run, the best option might be similar to event queues and to allow them to be shared explicitly via configs. (Acutally, other than naming badness, you may just want to pair RNGs with event queues, perhaps there is a higher level container needed for event queues like stuff in the config space and the pointers should be about that higher level container.).
Nate On Sun, Aug 24, 2014 at 6:58 AM, Andreas Hansson via gem5-dev < gem5-dev@gem5.org> wrote: > Hi Nate, > > I¹m actually quite sure it would be fine to just add a lock at this point. > That said, I find the easiest way out to the dilemma to make sure each > object that requires random numbers has its own rng and only uses the > numbers generated by this one instance. Clean, easy to understand, easy to > checkpoint and it fits in the current flow. Do you see any issues with > this solution? > > Andreas > > On 24/08/2014 06:21, "nathan binkert via gem5-dev" <gem5-dev@gem5.org> > wrote: > > >How often is the RNG used. Is it so bad to put a lock around it? If so, > >can't you build a wrapper around the RNG that generates 1MB of random bits > >at a time and then funnels those bits through a lock free queue? > > > > Nate > > > > > >On Sat, Aug 23, 2014 at 9:33 AM, Nilay Vaish via gem5-dev > ><gem5-dev@gem5.org > >> wrote: > > > >> You are assuming that each object is associated with a particular thread > >> and only that thread would call on the rng of the object. I don't think > >> this assumption holds. > >> > >> I understand that experiments would not be repeatable in the strictest > >> sense. But if some change in the order of events causes the simulation > >> results to move away from the original results, I would not blame the > >> simulator for being non-deterministic. I think forcing determinism has > >>a > >> cost, to be paid at the time of programming or at runtime. > >> > >> -- > >> Nilay > >> > >> > >> > >> On Wed, 20 Aug 2014, Andreas Hansson wrote: > >> > >> I think your suggestion makes checkpointing very challenging. > >>Ultimately > >>> the state of the rngs should be check pointed, and unless we attached > >>>them > >>> to specific objects that will be next to impossible with the current > >>>flow. > >>> At least I would not know how to sensibly do it such that the > >>>checkpoint > >>> is not tied to a specific thread count. > >>> > >>> Andreas > >>> > >>> On 8/20/14, 10:13 PM, "Nilay Vaish" <ni...@cs.wisc.edu> wrote: > >>> > >>> On Wed, 20 Aug 2014, Andreas Hansson wrote: > >>>> > >>>> > >>>>> > >>>>> On Aug. 20, 2014, 5:06 p.m., Nilay Vaish wrote: > >>>>>> > >>>>>>> The patch seems fine. I think we should declare rngs to be thread > >>>>>>> local > >>>>>>> to begin with and have different seeds for each of these rng to > >>>>>>>avoid > >>>>>>> any > >>>>>>> correlation. > >>>>>>> > >>>>>> > >>>>> Agreed. Finding the thread boundaries might be tricky, so I propose > >>>>>we > >>>>> create a rng per Sim/MemOjbect and seed it with some form of hash of > >>>>> the > >>>>> object name. What do you think? > >>>>> > >>>>> > >>>> rng per sim object sounds too much, though the state would probably > >>>>be a > >>>> small number of bytes. And then there might be code that is not part > >>>>of > >>>> any sim object but needs random numbers. I suggest we declare > >>>> random_mt with __thread annotation, like we do for the curEventQueue > >>>> variable. > >>>> > >>>> -- > >>>> Nilay > >>>> > >>>> > >>> > >>> -- IMPORTANT NOTICE: The contents of this email and any attachments are > >>> confidential and may also be privileged. If you are not the intended > >>> recipient, please notify the sender immediately and do not disclose the > >>> contents to any other person, use it for any purpose, or store or copy > >>>the > >>> information in any medium. Thank you. > >>> > >>> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, > >>> Registered in England & Wales, Company No: 2557590 > >>> ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 > >>>9NJ, > >>> Registered in England & Wales, Company No: 2548782 > >>> > >>> > >>> > >>> _______________________________________________ > >> gem5-dev mailing list > >> gem5-dev@gem5.org > >> http://m5sim.org/mailman/listinfo/gem5-dev > >> > >_______________________________________________ > >gem5-dev mailing list > >gem5-dev@gem5.org > >http://m5sim.org/mailman/listinfo/gem5-dev > > > > > -- IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > > ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, > Registered in England & Wales, Company No: 2557590 > ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, > Registered in England & Wales, Company No: 2548782 > > _______________________________________________ > gem5-dev mailing list > gem5-dev@gem5.org > http://m5sim.org/mailman/listinfo/gem5-dev > _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
