This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Ping: [Patch] aarch64: Thunderx specific memcpy and memmove
On Thursday 25 May 2017 11:19 PM, Wilco Dijkstra wrote:
> Given the number of micro architectures already existing, it would be a really
> bad situation to end up with one memcpy per micro architecture...
It's not just per micro-architecture...
> Micro architectures will tend to converge rather than diverge as performance
> level increases. So I believe it's generally best to use the same instructions for
> memcpy as for compiled code as that is what CPUs will actually encounter
> and optimize for. For the rare, very large copies we could do something different
> if it helps (eg. prefetch, non-temporals, SIMD registers etc).
... because as you say, micro-architectures may well converge over time
to some extent, but you will still end up having multiple memcpy
implementation taking advantage of different features in aarch64
architecture over time. For example, SVE routines vs non-SVE routines.
You'll need both and looking at how x86 has evolved, there will be much
more to come.
> An ifunc has a measurable overhead unfortunately, and that would no longer
> be trivially avoidable via static linking. Most calls to memcpy tend to be very
> small copies. Maybe we should investigate statically linking the small copy part
> of memcpy with say -O3?
Sure, that might be something to look at as a data point, but again
getting rid of multiarch is not the option for desktop/server
implementations, especially if micro-architecture specific routines give
measurable gains over generic implementations in the general case, i.e.
dynamically linked programs that need to run out of the box and
optimally on multiple types of hardware. Static binaries unfortunately
become the edge case here.
Siddhesh