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

[Filipe Laíns]

On Sat, 2019-05-25 at 21:27 +1000, Allan McRae via arch-dev-public wrote:
> On 25/5/19 9:19 pm, 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.
> 
> glibc detects available instruction sets and uses the best for many
> functions.
> 
> I'd be very, very, very much against providing multiple variants of a
> package in our repos.  Using asp and makepkg are is a hard solution for
> those who really need a few packages rebuilt.
> 
> PS - I rebuilt [core] with -march=haswell recently as a test.  Automated
> building is not an issue.  Unattended package/database signing is the
> major stumbling block.
> 
> Allan

In cases where the instruction set is detected at runtime it would not
be needed a new variation of the package since we can guarantee the
software isn't going to try to run any unsupported instructions.
What we are discussing really only applies to packages without runtime
SIMD code selection.

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/a7134035/attachment.sig>