[PATCH] D59539: [llvm-exegesis] Option to lobotomize dbscan (PR40880)

[Roman Lebedev via Phabricator via llvm-commits]

lebedev.ri added a comment.

In D59539#1439380 <https://reviews.llvm.org/D59539#1439380>, @lebedev.ri wrote:

> In D59539#1439375 <https://reviews.llvm.org/D59539#1439375>, @courbet wrote:
>
> > To make my suggestion clearer: if you just want to compare measured instruction data to its checked-in data, why not cluster by instruction opcode (to merge the several measurements for a given instruction) and run the analysis on that ?
> >
> > Essentially: clusterid == opcode, you just do away with dbscan fully.
>
>
>
>
> In D59539#1436216 <https://reviews.llvm.org/D59539#1436216>, @lebedev.ri wrote:
>
> > In D59539#1436193 <https://reviews.llvm.org/D59539#1436193>, @courbet wrote:
> >
> > > It think that's a fair point: I originally intended to sort of have one cluster be one sched class.
> > >  But why do you need clusters at all if all you care about is the mismatch between each instruction and its scheduling data ?
> > >
> > > Then why do you need clustering at all ? Why not create one cluster by instruction ?
> >
> >
> > No, the clustering is actually good.
> >  If i only take one measurements set, and then dumbly change all the sched values to match,
> >  then when i take a new measurements set, i will be "very" surprized that
> >  it all of a sudden no longer matches the checked-in values.
> >
> > Thus i take multiple measurements (3..10), and then if those measurements are different,
> >  the "cluster stabilization" (D58355 <https://reviews.llvm.org/D58355>) kicks in and i only get non-flaky clusters by default.
>


To reword: because if i do simple clustering by opcode, i will then need to add yet another
"stabilization" step - for each cluster, check that every measurement is neighbor of all
the other points in that cluster, and if they are not, mark cluster as noise.
(well, not every vs. every, just the lower/upper triangle excluding diagonal)

I can do that instead, maybe that would even better than this (no dependency on measurement ordering).

Any advice on how to proceed? I would really love to see this issue resolved :)


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59539/new/

https://reviews.llvm.org/D59539