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

[Roman Lebedev via Phabricator via llvm-commits]

lebedev.ri added a comment.

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.





Repository:
  rL LLVM

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

https://reviews.llvm.org/D59539