[aarch64-port-dev ] RFR: 8229351: AArch64: Make the stub threshold of string_compare intrinsic tunable

[Andrew Dinn]

On 13/11/2019 12:27, Andrew Haley wrote:
> Thank you for your patch, but I'm afraid that I have some reservations.

I also have the same reservations.

> This patch seems to do rather a lot.
> 
> What are the thresholds you tested? How are we supposed to test with
> these different thresholds? Are the thresholds bytes or characters?
> Why are the different thresholds not tested in this patch?

I agree that we would really need some numbers in order to determine
whether to make this change. However, before we go down that path ...

> But the more serious problem is the fact that we have different code
> paths for different microarchitectures, and somehow this has to be
> standard supportable software. In order to test this stuff we'll need
> different test parameters for SoftwarePrefetchHintDistance,
> CompareLongStringLimitLatin, CompareLongStringLimitUTF.

The key word here is /supportable/. This current proposed change is the
start of a slippery slope where we can end up with a plethora of
'tuning' parameters, not just for different manufacturers' but for this
years model and then next years model and so on. As the number and, more
importantly, combination of such parameters grows we can easily end up
in a situation where we are unable to generate a useful configuration
for all combinations of tuning parameters that meet the totality of
different application needs. Worse, we risk ending up in a situation
where we see terrible performance in the worst cases and no idea of how
we got there. This is a problem of complexity and tractability. Even if
we could in principle, given enough time, arrive at a global maximum or,
failing that, an optimal compromise that trades off competing needs the
danger is that in practice getting there can end up taking increasingly
large amounts of development and maintenance time that we don't have.

So, the gains for any addition of tuning parameters need to be
significant if we are to justify the costs incurred by implementing and
maintaining them. It is not enough for such a tuning feature to optimize
a specific case, especially just for a specific architecture, by a
noticeable amount e.g. the 1.5x that you cite for your architecture. For
an improvement to be significant enough to merit the incurred support
burden the gain ought to apply to many applications or, perhaps, to a
few critical, high-value applications and needs manifestly not to risk
lowering performance in all other applications. It also ought, at the
least, to be shown not to hurt performance on other architectures and,
preferably, provide at least some other architectures with the
opportunity also to improve performance.

> I -- and I'm sure it's not just me -- would be tremendously grateful
> if all of the AArch64 developers would concentrate on improving code
> quality overall rather than tweaking stub parameters.
I can confirm that this is not just Andrew's sentiment.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill