Bug 246194 - math/blis: pacify portlint, add test target, optimize for power9
Summary: math/blis: pacify portlint, add test target, optimize for power9
Status: In Progress
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: powerpc Any
: --- Affects Only Me
Assignee: Johannes M Dieterich
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-05-04 21:11 UTC by Piotr Kubaj
Modified: 2020-05-10 09:45 UTC (History)
2 users (show)

See Also:
bugzilla: maintainer-feedback? (jmd)


Attachments
patch (1.11 KB, patch)
2020-05-04 21:11 UTC, Piotr Kubaj
pkubaj: maintainer-approval? (jmd)
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Piotr Kubaj freebsd_committer 2020-05-04 21:11:04 UTC
Created attachment 214125 [details]
patch

1. Move USES block to pacify portlint.
2. Add test target.
3. Add perl as a build dependency, I'm not sure how it worked before.
4. Optimize for power9 on powerpc64. This will break blis on all earlier POWER generations, but nothing depends on this port so I guess it's ok. make test passes fine on both elfv1 and elfv2.
5. Remove LIBNAME, it's not necessary.

Question: would it be possible to add flavors with all kernels? That way, users could install the version optimized for their CPU or just generic.
Comment 1 Johannes M Dieterich freebsd_committer 2020-05-09 20:50:47 UTC
No objections to 1-3, 5.

4: are these generations supported by powerpc64? If so, can we add fallback to generic? That should work by introducing a "powerpc64" family containing both the family 9 optimized one as well as the generic fallback

I'm not a friend of complicating the port too much - I'd rather us use proper families for all targets to not run into surprises and be able to distribute the packages. The overhead of having non-applicable kernels compiled and packaged seems tolerable?
Comment 2 Piotr Kubaj freebsd_committer 2020-05-09 22:03:29 UTC
FreeBSD supports all IBM POWER chips from the first PPC970 (in Macs G5) up to the latest POWER9 and also Freescale's ppc64 chips found in embedded devices.

So yes, optimizing for POWER9 will make it more useful to POWER9 users. It will also make this port useless on all earlier generations, but:
1) since nothing depends on this port, optimizing to POWER9 will only be relevant to people directly using this port on powerpc64 older than POWER9, not to someone using some reverse dependency (because there are none),
2) I think people using software strictly for scientific computations tend to use the latest available hardware because of power usage improvements. I don't think anyone will use their old PowerMac G5 with this port.

Regarding complicating this port, on e.g. ARM we build generic binaries, but per https://github.com/flame/blis/blob/master/config_registry, there are two armv7-optimized variants and three aarch64-optimized variants, depending on the actual CPU. For amd64, there are overall 11 possible variants (optimized for specific CPUs).

This is why I proposed this port getting flavours, that would make it possible for users to install their preferred version.

If you ask about POWER and BGQ in the above link, AFAIK this is IBM Blue Gene which uses custom PowerPC chips and support for it is not available in FreeBSD anyway.
Comment 3 Johannes M Dieterich freebsd_committer 2020-05-09 22:46:16 UTC
My goal for this port is to have it be an option as a BLAS solution in the ports framework, so I'm hesitant to break it for anything. We should be able to work with upstream to ensure a family config is available that works ideally on 9 and falls back correctly.

That's the point of the x86_64 family is to support all 11 amd64/intel64 x86_64. They added this on my request.

I'd rather work with upstream to properly bundle the ARM and Power configs as well (with fallback, so that's unlike the x86_64 family which does not possess a fallback - but maybe should) and switch them at runtime. That way everybody gets ideal performance without older generations breaking.

That's equivalent to what e.g. math/openblas does.
Comment 4 Piotr Kubaj freebsd_committer 2020-05-10 09:45:49 UTC
> That's equivalent to what e.g. math/openblas does.

That's true on amd64, it supports DYNAMIC_ARCH. But it's not true on powerpc64, unless something has changed recently. To have it built, I needed to target PPC970. POWER6 also works, but nothing more recent (for big-endian, little-endian is another story, but FreeBSD doesn't support it). 0.3.10 is supposed to support POWER8, but I don't think DYNAMIC_ARCH will work.