Removal of the sub-optimal type (confused it with some old code, easy fix)
Refactoring of the logic that computes closestPoints
I was skeptical about going with the second point at first since technically, it looks like it's working:
And I've also been finally getting results that extend beyond 2 for a 'Recommended' value (previously that was the max I got for some reason), for functions like forder for e.g.:
But logically, I agree with Toby's comments and reasoning as maximizing the difference like I did would not yield accurate results/points always.
AFAIU, for each function/expr I need to first filter the 'Measured' speedup/y-axis values that are greater (or it should be equal too as I think? ge should be the case imo) than the 'Recommended' speedup values (coming from the 0.5 slope line), find whichever value is the highest among them, and then collectively (with it's corresponding x-axis/threadCount value) assign it as the point of intersection.
Includes:
closestPointsI was skeptical about going with the second point at first since technically, it looks like it's working:
And I've also been finally getting results that extend beyond 2 for a 'Recommended' value (previously that was the max I got for some reason), for functions like
forderfor e.g.:But logically, I agree with Toby's comments and reasoning as maximizing the difference like I did would not yield accurate results/points always.
AFAIU, for each function/
exprI need to first filter the 'Measured'speedup/y-axis values that are greater (or it should be equal too as I think?geshould be the case imo) than the 'Recommended' speedup values (coming from the 0.5 slope line), find whichever value is the highest among them, and then collectively (with it's corresponding x-axis/threadCountvalue) assign it as the point of intersection.