[arch-dev-public] Create guidelines regarding SIMD instructions/x86 extensions

Filipe Laíns lains at archlinux.org
Sat May 25 12:31:47 UTC 2019


On Sat, 2019-05-25 at 13:19 +0200, Bruno Pagani via arch-dev-public wrote:
> Hi,
> 
> Le 25/05/2019 à 02:17, Filipe Laíns via arch-dev-public a écrit :
> > I would also like to explore the idea of adding an "high performance"
> > architecture which would be able to make use of SSE{,2,3,4,4.1,4.2} and
> > AVX, which seem to be the standard for newer processors (>=2013). This
> > would only be available for packages that do high performance computing
> > (ex. openblas, sdrangel, etc.). Any thoughts on this?
> 
> As said on IRC, they have been discussions before on having multiple
> targets and corresponding repos, but the starting point is that we need
> automated build before going into such a direction, and this in turn has
> several requirements. I’ve linked to you the pad where we put our ideas
> together regarding this.
> 
> In the meantime, we had the case before of whether we should package
> e.g. $pkgname-{sse4,avx} in a case where it mattered a lot, but it
> turned out the software in question (embree) is able to do runtime
> detection of available ISA. Maybe some other packages are doing this
> too, else we could discuss whether allowing such flavours as a temporary
> measure would be acceptable for selected packages.
> 
> Regards,
> Bruno

This is fine my me. My biggest concern was the fact C doesn't support
__attribute__(("instruction set here")) but there are of course
workarounds. Creating a new architecture only makes sense if there are
multiple packages needing this but it seems not. I am fine with a
suffix, although I was thinking more something like -simd as SSE4, AVX,
etc. are usually available at the same time. In this cases I think we
should add a post_install step that gives a warning if the user CPU
doesn't support the used instruction sets.

Thanks,
Filipe Laíns
3DCE 51D6 0930 EBA4 7858 BA41 46F6 33CB B0EB 4BF2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <https://lists.archlinux.org/pipermail/arch-dev-public/attachments/20190525/03f9caa2/attachment.sig>


More information about the arch-dev-public mailing list