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

Roman Lebedev via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Mar 20 05:28:42 PDT 2019


lebedev.ri added a comment.

In D59539#1436193 <https://reviews.llvm.org/D59539#1436193>, @courbet wrote:

> > This may or may not be a correct implementation of dbscan clustering algorithm.
>
> Yes, that's what we want. This really is one cluster.


Yes, i do think that is the correct implementation //of the algorithm//.

>> While the current default is good for abstract 'analyse clustering of measurements',
> 
> i'm not sure how often that is the actual goal, not 'compare llvm data with measurements'.
>  So i'm not sure what should be the default.



> 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





More information about the llvm-commits mailing list