> > > > I would make this go in separately from the feature itself (it is build > > machinery change). > > All right. > > > Especially since you say it does not reach > > reproducibility anyway until we patch hashtables? > > Yep, I'm testing a patch that should improve the reproducible build. > Thanks! > > I remember we had issues with streaming running in parallel with > > threads. Can't we get here corruption without atomic updates of nndoes > > and the next pointer? > > You are right, it can get into an inconsistent state in the pruning code. > I likely tend to drop the pruning path now, it's optional feature.
Agreed, lets get the implementation working (i.e. sign bit tracking non-reproducible gcov merges and gcc consuming it correctly) and care about pruning incrementally. In meantime I seem to have got the firefox inlining working right on GCC so we can see how well the three settings works. > > > > > I also remember that these parlalel updates was pretty bad, because if > > you have multithreaded concurent update of very frequent indirect > > branch, like in firefox, the likelyness that update happens between > > pruning and quite slow stream-out is high. > > Yes. Yep, but as said in other mail, it makes sense to care about profile quality with parallel updates if profile-reproducibility=multithreaded or single. I do not see point of configuring it to parallel-runs since it buys you nothing. > > Unfortunately, starting from this point we may set total to a negative value > (until > it's streamed). But training run can still do total++ for each instrumented > value. So this will have effect of decreasing the counter rahter than increasing. One interesting datapoint is that firefox train run seems to spend more time by streaming than by other tasks (becuase llvm training takes 7 minutes and gcc training cca 30 minutes) and if there is parallel task doing stuff like tab animation it may have enough time to corrupt the counter considerably. Unless you see very easy solution, I think we could handle this incrementally as well. With basic infrastrucutre on palce and way to trigger warnings on rejected profiles that would be otherwise useful, we should get better idea how important this is. Since we allocate the entries dynamically, perhaps we could steal the bit somewhere else than in actual counter to avoid concurent updating issues. Honza > > Martin > > > > > Honza > > >
