[RFC]: Removing old Falkor ifuncs

[RFC]: Removing old Falkor ifuncs

[Wilco Dijkstra]

Hi Siddhesh,

Do we need the ifuncs for Falkor? The SIMD memcpy is now the default
generic memcpy and that is quite similar to the Falkor one, so it seems
time to remove the Falkor variants. Since you are the original author,
what do you think?

Cheers,
Wilco

Re: [RFC]: Removing old Falkor ifuncs

[Siddhesh Poyarekar]

On 2022-12-09 10:14, Wilco Dijkstra wrote:
> Do we need the ifuncs for Falkor? The SIMD memcpy is now the default
> generic memcpy and that is quite similar to the Falkor one, so it seems
> time to remove the Falkor variants. Since you are the original author,
> what do you think?

The key differentiator in memcpy/memmove at that time was the register 
number usage since that affected how the hardware prefetcher performed. 
Changing that might affect performance on falkor, although I don't 
exactly remember by how much.

The other key differentiator is in memset, where reading dczid_el0 was 
expensive on falkor, so the value is hard coded to avoid reading it 
everytime.

Sid

Re: [RFC]: Removing old Falkor ifuncs

[Wilco Dijkstra]

Hi Siddhesh,

>On 2022-12-09 10:14, Wilco Dijkstra wrote:
>> Do we need the ifuncs for Falkor? The SIMD memcpy is now the default
>> generic memcpy and that is quite similar to the Falkor one, so it seems
>> time to remove the Falkor variants. Since you are the original author,
>> what do you think?
>
> The key differentiator in memcpy/memmove at that time was the register 
> number usage since that affected how the hardware prefetcher performed. 
> Changing that might affect performance on falkor, although I don't 
> exactly remember by how much.

If there was a difference, it would likely be on large copies. But it would be hard
to test without access to a machine...

> The other key differentiator is in memset, where reading dczid_el0 was 
> expensive on falkor, so the value is hard coded to avoid reading it 
> everytime.

Yes this is true for various microarchitectures. I posted a patch to make this
more general a few years ago, ie. always use an ifunc if the ZVA size is 64
rather than do something CPU specific.

Cheers,
Wilco

Re: [RFC]: Removing old Falkor ifuncs

[Wilco Dijkstra]

Hi Siddhesh,

>>On 2022-12-09 10:14, Wilco Dijkstra wrote:
>>> Do we need the ifuncs for Falkor? The SIMD memcpy is now the default
>>> generic memcpy and that is quite similar to the Falkor one, so it seems
>>> time to remove the Falkor variants. Since you are the original author,
>>> what do you think?
>>
>> The key differentiator in memcpy/memmove at that time was the register 
>> number usage since that affected how the hardware prefetcher performed. 
>> Changing that might affect performance on falkor, although I don't 
>> exactly remember by how much.
>
> If there was a difference, it would likely be on large copies. But it would be hard
> to test without access to a machine...

I managed to get an old Falkor revived, so was able to finally run benchtests.
The new generic memcpy is about 10% faster on bench-memcpy-random test
when sizes fit in L1, and about 5% faster overall. Bench-memcpy-large and -walk
are very similar, so it doesn't seem to have any effect on prefetching in large copies.

So it looks like the new generic memcpy is better overall.

Cheers,
Wilco

Re: [RFC]: Removing old Falkor ifuncs

[Siddhesh Poyarekar]

On 2022-12-21 12:27, Wilco Dijkstra wrote:
> Hi Siddhesh,
> 
>>> On 2022-12-09 10:14, Wilco Dijkstra wrote:
>>>> Do we need the ifuncs for Falkor? The SIMD memcpy is now the default
>>>> generic memcpy and that is quite similar to the Falkor one, so it seems
>>>> time to remove the Falkor variants. Since you are the original author,
>>>> what do you think?
>>>
>>> The key differentiator in memcpy/memmove at that time was the register
>>> number usage since that affected how the hardware prefetcher performed.
>>> Changing that might affect performance on falkor, although I don't
>>> exactly remember by how much.
>>
>> If there was a difference, it would likely be on large copies. But it would be hard
>> to test without access to a machine...
> 
> I managed to get an old Falkor revived, so was able to finally run benchtests.
> The new generic memcpy is about 10% faster on bench-memcpy-random test
> when sizes fit in L1, and about 5% faster overall. Bench-memcpy-large and -walk
> are very similar, so it doesn't seem to have any effect on prefetching in large copies.
> 
> So it looks like the new generic memcpy is better overall.

Great, I'd say go for it then :)

Thanks,
Sid