Re: [PATCH v3] powerpc: strstr optimization

[Steven Munroe <munroesj at linux dot vnet dot ibm dot comcom>]

On Mon, 2015-07-27 at 11:19 +0200, OndÅej BÃlka wrote:
> On Sun, Jul 26, 2015 at 08:26:06PM -0500, Steven Munroe wrote:
> > On Sat, 2015-07-25 at 10:20 +0200, OndÅej BÃlka wrote:
> > > No my objection was that this should be reverted as patch that wasn't
> > > reviewed. My main reason to believe are numerous issues that every
> > > competent reviewer should notice. First red flag was Tulio telling its
> > > ok for me, then telling that he received message there is bug in strstr.
> > > 
> > 
> > This is ridiculous. most of this personal and unprofessional attack
> > below is based on incorrect assumptions (of things you do not actually
> > know) or taken out of context and twisted to fit your narrative.
> > 
> > You really need to take a deep breath and think before you say anything
> > else.
> >
> 
> Could you stop doing ad hominem attacks please? I noticed that you
> resort to these when I show that facts speak otherwise.
> 
> As this being out of context I expected that you will of course deny
> everything and say something like that. So could you answer following
> three questions?
> 
> 1. Reviews, it would be better to always write reviews publictly. But as
> you still have them could you send reviews here to clarify.
> 
> 2. Quadratic behaviour. It should be clear for any expert that with 2047
> byte needle you need check all these bytes for each byte in haystack. If
> you optimisticaly check 8 bytes per cycle then it would take 256 cycles
> times haystack size. In practice its slower as its equivalent to strcmp
> which on power7 has following timing:
> Length 1024, alignment 14/ 7:   593.5   651.016 318.844 447.203
> 
> So why you didn't insist to fix that by changing constant to something
> reasonable?
> 
> 3. Why despite your frequent reviews a implementation is in average case
> still slower than simple bugfix of generic strstr.
> 
> As for that I do incorrect assumptions and take things out of context
> its quite easy to make vague accussations like this. So be more
> specific, what assumptions and where is your evidence that assumption 
> is incorrect?
> 

What we have here is complete failure to communicate.

On June 9th: I suggested that if you felt so strongly about this for
reasons that I did not understand, then you should provide an objective
benchmark that provided you point.

https://sourceware.org/ml/libc-alpha/2015-06/msg00365.html

On June 10th Roland agreed that that was a reasonable way to proceed.

https://sourceware.org/ml/libc-alpha/2015-06/msg00367.html

You rejected this. So Raji continued to use the one strstr benchmark we
have. We tried to compromise by adjusting the crossover point between
the new and old algorithm and avoid the specific case you gave.

And you rejected that.

On July 16th Raji submitted the V3 of the patch

https://sourceware.org/ml/libc-alpha/2015-06/msg00788.html

On June 16th you basically told Carlos that my team was incompetent and
could not be trusted, hhhm does this qualify as an ad hominem attach?

https://sourceware.org/ml/libc-apha/2015-07/msg00501.html

At which point I stop listening. There does not seem to be anything that
I can say or do to satisfy you. So I stopped trying.

On July 23rd Carlos asked for a second opinion on if what we had was in
fact quadratics.

https://sourceware.org/ml/libc-alpha/2015-07/msg00799.html

The consensus was no, and was at worse O(nm)

This has wasted huge amounts of time. Time we could have used to
improved the code for the next release. 

I will make you a promise. If you will provide the objective benchmark
that illustrates this issue and get the community to accept it as an
objective measure of a realistic scenario. I will ask the team to work
on appropriate improvements.