[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