On 30.03.26 13:40, Martin Storsjö wrote:
A lot of our assembly has been written when the most available aarch64 devices all had Cortex-A53 cores, so there may be some tuning/scheduling bias towards that one - but if revising scheduling it may be good to consider all common cores.Thanks for the info. I have a variety of aarch64 cores available so I think I can give a picture on the "global" impact. A510/A520 are sadly missing from the collection.
Do your tools correctly simulate the specifics around e.g. the dedicated MAC accumulator forwarding paths in A53/A55/A520?Yes, we currently do model the MAC accumulator fwd path. It would also be no big problem to extend/disable this. In case you are curious to take a look for yourself how we model the Cortex-A55, our microarchitectural model is defined in Python and "somewhat" readable: https://github.com/slothy-optimizer/slothy/blob/main/slothy/targets/aarch64/cortex_a55.py
Functions for h264/hevc might give the biggest real-world impact.
That's what I was suspecting, thanks for confirming.
For evaluating the performance of assembly implementations, we primarily rely on the checkasm tool
Perfect, this is exactly what I was looking for!
If you can provide rescheduled versions of functions - that looks like handwritten assembly and fits into our coding style, I think we would appreciate the contributions!I will try a few examples over the next days and then report back on whether SLOTHY can do any good.
I'm less convinced that we're interested in integrating the framework as such into our build system.
Understandable!
But if it can be shown how users easily can run the tool on the existing code, I guess that someone could want to look at it!In case anyone got interested in SLOTHY, this is the link to a tutorial prepared by my colleague Matthias Kannwischer and myself: https://abdulrahman.de/slides/2025/slothytutorial.pdf It explains how the tool operates, what the user/developer needs to do, and includes some assignments as well.
Again, thank you very much for your help to get started. I'll report back once I got some results.
Kind regards Amin -- Amin Abdulrahman (he/him) PhD Student Max Planck Institute for Security and Privacy (MPI-SP) Universitätsstraße 140 44799 Bochum, Germany https://www.mpi-sp.org
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ ffmpeg-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
