Re: [PATCH v2 0/3] RISC-V: ifunced memcpy using new kernel hwprobe interface

[Palmer Dabbelt <palmer@rivosinc.com>]

On Fri, 31 Mar 2023 15:10:24 PDT (-0700), jeffreyalaw@gmail.com wrote:
>
>
> On 3/31/23 15:38, Palmer Dabbelt wrote:
>> On Fri, 31 Mar 2023 14:35:36 PDT (-0700), jeffreyalaw@gmail.com wrote:
>>>
>>>
>>> On 3/31/23 15:03, Palmer Dabbelt wrote:
>>>> On Fri, 31 Mar 2023 13:19:19 PDT (-0700), jeffreyalaw@gmail.com wrote:
>>>>
>>>> [just snipping the rest so we can focus on Jeff's ask, the other stuff
>>>> is interesting but a longer reply and we'd probably want to fork the
>>>> thread anyway...]
>>>>
>>>>> So perhaps we can narrow down the scope right now even further.  Can we
>>>>> agree to try and settle on a base implementation with no ISA extensions
>>>>> and no uarch variants?  ISTM if we can settle on those implementations
>>>>> that it should be usable immediately by the RV community at large and
>>>>> doesn't depend on the kernel->glibc interface work.
>>>>
>>>> That base includes V and ZBB?  In that case we'd be dropping support for
>>>> all existing hardware, which I would be very much against.
>>> No, it would not include V or ZBB.  It would be something that could
>>> work on any risc-v hardware.  Sorry if I wasn't clear about that.
>>
>> I'm still kind of confused then, maybe it's just too abstract?  Is there
>> something you could propose as being the base?
> So right now we use the generic (architecture independent) routines for
> str* and mem*.
>
> If we look at (for example) strcmp there's hand written variants out
> there are are purported to have better performance than the generic code
> in glibc.
>
> Note that any such performance claims likely predate the work from
> Adhemerval and others earlier this year to reduce the reliance on
> hand-coded assembly.
>
> So the first step is to answer the question, for any str* or mem* where
> we've received a patch submission of a hand coded assembly variant
> (which isn't using ZBB or V), does that hand coded assembly variant
> significantly out perform the generic code currently in glibc.  If yes
> and the generic code can't be significantly improved, then we should
> declare that hand written variant as the standard baseline for risc-v in
> glibc.  Review, adjust, commit and move on.
>
> My hope would be that many (most, all?) of the base architecture hand
> coded assembly variants no longer provide any significant benefit over
> the current generic versions.
>
> That's my minimal proposal for now.  It's not meant to solve everything
> in this space, but at least carve out a chunk of the work and get it
> resolved one way or the other.
>
> Does that help clarify what I'm suggesting?

Sorry for being slow here, this fell off the queue.

I think this proposal is in theory what we've done, it's just that 
nobody's posted patches like that -- unless I missed something?  
Certainly the original port had some assembly routines an we tossed 
those because we didn't care enough to justify them.  If someone's got 
code then I'm happy to look, but we'd also need some benchmarks (on real 
HW that's publicly available) and that's usually the sticking point.

That said, I'd guess that anyone trying to ship real product is going to 
need at least V (or some other explicitly data parallel instructions) 
before the performance of these routines matters.