[PATCH] D54418: [llvm-exegesis] InstructionBenchmarkClustering::dbScan(): replace SetVector with custom BitVectorVector

[Roman Lebedev via Phabricator via llvm-commits]

lebedev.ri added a comment.

In https://reviews.llvm.org/D54418#1296040, @MaskRay wrote:

> In https://reviews.llvm.org/D54418#1296028, @lebedev.ri wrote:
>
> > In https://reviews.llvm.org/D54418#1296001, @MaskRay wrote:
> >
> > > In https://reviews.llvm.org/D54418#1295942, @lebedev.ri wrote:
> > >
> > > > In https://reviews.llvm.org/D54418#1295941, @MaskRay wrote:
> > > >
> > > > > I'm also not following...
> > > >
> > > >
> > > > I'm sorry that i'm not following what you do not follow :)
> > > >
> > > > > DBSCAN is a BFS/Dijkstra-like algorithm. a `BitVector` + reserved `std::vector` suffice.
> > > >
> > > > Which is exactly what this `BitVectorVector` implements, as far as i can tell.
> > > >  I do not understand what the question is. I'm sorry. Can you reformulate the question, please?
> > >
> > >
> > > Maybe I should quote "talk is cheap" here... My idea is https://reviews.llvm.org/D54442 (I hope it won't interfere your other improvement)
> >
> >
> > I still do not understand what the question is.
> >  Yes, that pretty much the same as this code.
> > Differences:
> >
> > - uses pop back, instead of pop front. my measurements so far always showed pop back to be worse.
> > - Both data structures are inline, instead of abstracting them under BitVectorVector.
> > - One very interesting point - initial insertion is a special case, no need to check in the set. I do expect that to be faster, let's see..
>
>
> Can you suggest some way to get the large benchmark file as you have in `/tmp/benchmarks.yaml`? I need to experiment with it but it is still unclear to me why `pop_back` is slower.


F7539112: benchmarks.yaml <https://reviews.llvm.org/F7539112>
Please note that it is quite literally just first 500'000 lines of the full uop benchmark, which is ~10x as large.
It is that big because i was experimenting with repeating benchmarking 10x times, and then being able visually undestand what is the correct value when the benchmark ends up being noisy.


Repository:
  rL LLVM

https://reviews.llvm.org/D54418