On Friday 26 February 2010 08:54:31 pm Steve wrote: > Are there specific articles you can point me to? I haven't really > kept on top of the field lately, so if this hypothesis has already > been disproven I'd really like to learn more of the details. I agree > there's no concrete evidence that it's true either, I just think it's > premature to dismiss it without evidence either way. It's also a > function of how much detail you have; for example, the relative > overhead of syncing every N cycles is much lower if you have a very > detailed out-of-order core model than if you're doing a mostly > functional core simulation.
To be fair, when I said disproves your hypothesis, I should have said that the assumption that synchronizing every couple of cycles would work fast is wrong and that high accuracy can still be obtained with much less synchronization. One of the questions I'm hoping to answer is what the speedup/accuracy difference is between a sluggish detailed simulator and a very fast not so detailed simulator. See: Slacksim Graphite > > I'd also point out that "good speedups" and "near linear scalability" > aren't necessarily the same thing; True but given enough resources the only thing preventing a good speedup and near linear scalability is synchronization. > Don't get me wrong, I think this is a great idea... although 2-3X on 8 > cores would make me happy, if I can get 6X with only a slight loss of > accuracy I'll be even happier. > I'm hoping to make many people happy :-) > More specifically, "timing of events outside the CPUs", correct? Yes, that statement needed correction. > >> I think a basic approach that simply uses synchronization to prevent > >> fast threads from getting too far ahead is the best place to start > >> (where how you define "too far ahead" is basically your > >> performance/accuracy tradeoff). > > > > That's not an option for me. > > I don't follow... why not? You can still define quanta that are > larger than the lookahead to increase performance at the cost of some > error, but I think you're going to need some synchronization to > prevent the errors from becoming unbounded. Even if you want to do > something more sophisticated in the long run, I'd think this kind of > approach would be good for a baseline to see if your complex > algorithms are really buying you anything. > Oh sorry, I misread what you wrote. It makes complete sense and this has actually always been my intention. > Steve > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev >
_______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
