>Kevin Kofler wrote:
>>Dave Love wrote:
>> As far as I can tell, it doesn't do dynamic dispatch. Experimentally,
>> if you build with -mavx2 and run on ivybridge (or for skx and run on
>> haswell), the test code generates illegal instruction errors. It's some
>> time ago since I looked at it,
Dave Love wrote:
> As far as I can tell, it doesn't do dynamic dispatch. Experimentally,
> if you build with -mavx2 and run on ivybridge (or for skx and run on
> haswell), the test code generates illegal instruction errors. It's some
> time ago since I looked at it, and I don't remember, but
Dan writes:
>> Dave Love writes:
>> Well, what I've already said from some experience and research. Where's the
>> POWER and >>S390 support? All I saw is x86 and arm. We've heard there's
>> ppc64le compatibility support
>>anyhow, which is rising
>
>gcc provides compat x86 intrinsics via
Kevin Kofler wrote
>>Florian Weimer wrote:
>>...
>> In general, that is not true. You can use the target function attribute
and function
>> multiversioning instead in many cases.
>This may (or may not) have been recently fixed, but last I checked,
intrinsics for a vector
>instruction set XYZ2
> gcc provides compat x86 intrinsics via "x86intrin.h", they were
> successfully used eg. by darktable (raw photo sw)
Okay. Thanks for the info.
--
Jun | He - His - Him
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an
> They're packages for a header-only system, not libraries, hence my
confusion.
Hi Dave, okay.
> Who's pushing this, and how do I present an HPC performance engineering
perspective?
I appreciate your interest in the bioinformatics in HPC.
The simde Fedora package: Me
The simde Debian package:
On Mon, 27 Apr 2020 16:23:39 +0100
Dave Love wrote:
> Jun Aruga writes:
>
> >> > For the better user experience, we are promoting the system
> >> > library for both RPM and Debian based Linux distributions.
> >>
> >> What system library, for what purpose?
> >
> > Hi Dave,
> > The simde system
Jun Aruga writes:
>> > For the better user experience, we are promoting the system library
>> > for both RPM and Debian based Linux distributions.
>>
>> What system library, for what purpose?
>
> Hi Dave,
> The simde system library is
>
> * simde-devel in Fedora and EPEL [1]
> * libsimde-dev in
Kevin Kofler writes:
> Florian Weimer wrote:
>> In general, that is not true. You can use the target function attribute
>> and function multiversioning instead in many cases.
>
> This may (or may not) have been recently fixed, but last I checked,
> intrinsics for a vector instruction set XYZ2
Florian Weimer wrote:
> In general, that is not true. You can use the target function attribute
> and function multiversioning instead in many cases.
This may (or may not) have been recently fixed, but last I checked,
intrinsics for a vector instruction set XYZ2 were only available with the
On Mon, Apr 27, 2020 at 7:26 AM Stephen Gallagher
wrote:
> On Wed, Apr 22, 2020 at 10:52 AM Richard Shaw
> wrote:
> > Could we treat them like arches?
> > Something like:
> > X86_64 & X86_64-AVX2
> > armv7hf & armv7fh-NEON
> > etc...
> >
> > It would absolutely have to be OPT IN because once
* Kevin Kofler:
> Jun Aruga wrote:
>> simde is a header files only library. It's not a binary.
>
> Then it is inherently unsuitable for automatic runtime selection, and
> all the runtime selection still has to be done in the client program.
>
> GCC requires you to compile for separate vector
On Wed, Apr 22, 2020 at 10:52 AM Richard Shaw wrote:
>
> On Wed, Apr 22, 2020 at 9:28 AM Artur Iwicki wrote:
>>
>> Regarding x86_64 and AVX2, last year we had a very heated discussion about
>> this on the mailing list.
>>
>>
> > For the better user experience, we are promoting the system library
> > for both RPM and Debian based Linux distributions.
>
> What system library, for what purpose?
Hi Dave,
The simde system library is
* simde-devel in Fedora and EPEL [1]
* libsimde-dev in Debian [2]
The purpose is to
Jun Aruga writes:
> For the better user experience, we are promoting the system library
> for both RPM and Debian based Linux distributions.
What system library, for what purpose?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe
Jun Aruga writes:
> You do not need to care about the availability by arch or compiler
> when using this library.
As far as I can tell, it doesn't do dynamic dispatch. Experimentally,
if you build with -mavx2 and run on ivybridge (or for skx and run on
haswell), the test code generates illegal
Jun Aruga wrote:
> simde is a header files only library. It's not a binary.
Then it is inherently unsuitable for automatic runtime selection, and all
the runtime selection still has to be done in the client program.
GCC requires you to compile for separate vector instruction sets in separate
Richard Shaw wrote:
> It's funny we just had this conversation yesterday, I woke up to a pull
> request to add SSE support.
>
> https://github.com/drowe67/LPCNet/pull/25
Unfortunately, that requires SSE4.1, which is still too much to assume.
Looking at the comments, the author actually tried
On Sun, Apr 26, 2020 at 5:25 PM Dave Love
wrote:
> Kevin Kofler writes:
>
> > Has anyone (upstream or elsewhere) ever looked into doing an SSE2
> version of
> > the vector code? It should be faster than scalar (especially considering
> > that the "scalar" floating-point code (under the default
> Again it's not the binaries. People need to build with it. But do not need to
> distribute it for
> each project. For the better user experience, we are promoting the system
> library for both
> RPM and Debian based Linux distributions.
Again compiling with an "enhanced API" like simde or
Kevin Kofler writes:
> Has anyone (upstream or elsewhere) ever looked into doing an SSE2 version of
> the vector code? It should be faster than scalar (especially considering
> that the "scalar" floating-point code (under the default -mfpmath=sse)
> actually loads everything into SSE2
Richard Shaw writes:
>> tl;dr: there was a proposal to make "x86_64" in Fedora mean "must support
>> at least AVX2" and it met with a lot of backlash.
Yes, that's the wrong approach to performance engineering.
> Now that you mention it that does tickle some brain cells...
>
> So it seems
On Sun, Apr 26, 2020 at 9:41 PM Steven Munroe wrote:
>
> Jun Aruga writes:
>
> > I recommend using the simde (SIMD Everywhere) library for the packaging and
> > contribution
> > to the upstream. https://github.com/nemequ/simde
>
> This does not help unless the project LPCNet maintainers are
Jun Aruga writes:
> I recommend using the simde (SIMD Everywhere) library for the packaging
and contribution
> to the upstream. https://github.com/nemequ/simde
This does not help unless the project LPCNet maintainers are willing to
built the fat binaries and support dynamic selection. Otherwise
On 4/26/20 5:07 AM, Richard Shaw wrote:
Below is a quick table from the PR showing relative decode performance
per SIMD pathway:
* Fedora 31
* gcc 9.3.1
* Ryzen 5 2600
SIMDTime (s)% real time
None19.796 39.8%
SSE 4.1 17.971 36.1%
AVX 10.185 20.5%
AVX29.459
On Sat, Apr 25, 2020 at 7:24 AM Kevin Kofler wrote:
> Richard Shaw wrote:
> > As far as LCPNet itself I've communicated with the primary developer
> quite
> > a bit over the last week. LPCNet *will not work* without optimizations
> (at
> > least not in real time which is the point).
>
> Has
On 4/25/20 12:24 UTC, Kevin Kofler wrote:
Richard Shaw wrote:
As far as LCPNet itself I've communicated with the primary developer quite
a bit over the last week. LPCNet *will not work* without optimizations (at
least not in real time which is the point).
Has anyone (upstream or elsewhere)
On Sat, Apr 25, 2020 at 7:24 AM Kevin Kofler wrote:
> Richard Shaw wrote:
> > As far as LCPNet itself I've communicated with the primary developer
> quite
> > a bit over the last week. LPCNet *will not work* without optimizations
> (at
> > least not in real time which is the point).
>
> Has
Hi Rechard,
I recommend using the simde (SIMD Everywhere) library for the
packaging and contribution to the upstream.
https://github.com/nemequ/simde
You do not need to care about the availability by arch or compiler
when using this library.
simde-devel is available in Fedora stable versions
Richard Shaw wrote:
> As far as LCPNet itself I've communicated with the primary developer quite
> a bit over the last week. LPCNet *will not work* without optimizations (at
> least not in real time which is the point).
Has anyone (upstream or elsewhere) ever looked into doing an SSE2 version of
Sam Varshavchik wrote:
> Linux thinkpad 5.5.16-200.fc31.x86_64 #1 SMP Wed Apr 8 16:43:33 UTC 2020
> x86_64 x86_64 x86_64 GNU/Linux
> [
> /proc/cpuinfo:
>
> flags : ... avx ...
And even that is not safe to assume.
The baseline is SSE2, nothing more. No SSE3, SSSE3, SSE4.1, SSE4.2,
On Fri, Apr 24, 2020 at 6:10 PM Steven Munroe wrote:
>
> The Linux kernel notified each process of the Platform and Hardware
> Capabilities it the AUX Vector (Defined in the Application Binary
> Interface Document for each platform). The compilers provide a easy to
> use interface to interrogate
There really two questions here. Will/can Fedora automatically take
advantage of new instruction set architecture (ISA). And can my
project take advantage to new ISA.
The short answer is yes/maybe.
The longer answer is the mechanisms exist (built into the compilers
and runtime), but not all
Richard Shaw writes:
I'm having trouble determining what the base CPU targets for Fedora can
accommodate.
For example, ss it safe to assume AVX2 on x86_64?
Nope.
Linux thinkpad 5.5.16-200.fc31.x86_64 #1 SMP Wed Apr 8 16:43:33 UTC 2020
x86_64 x86_64 x86_64 GNU/Linux
[
/proc/cpuinfo:
On Wed, Apr 22, 2020 at 10:42 AM Richard W.M. Jones
wrote:
> On Wed, Apr 22, 2020 at 10:19:47AM -0500, Richard Shaw wrote:
> > I'm not sure all upstream have the manpower or knowledge to do it
> > dynamically, plus in the case of LPCNet, it's required as it's the whole
> > point of the project.
On Wed, Apr 22, 2020 at 10:19:47AM -0500, Richard Shaw wrote:
> On Wed, Apr 22, 2020 at 10:13 AM Michael Cronenworth
> wrote:
>
> > On 4/22/20 9:51 AM, Richard Shaw wrote:
> > > So it seems what's really needed is a method to support software with
> > > optimizations above the baseline without
* Dominik Mierzejewski:
> If upstream doesn't support runtime selection of SIMD-optimized code
> paths based on CPU capabilities, you can build several versions and
> have glibc handle that by putting each version in a special subdirectory
> of /usr/lib64, e.g.:
> /usr/lib64/haswell
>
On Wed, Apr 22, 2020 at 9:25 AM Dominik 'Rathann' Mierzejewski
wrote:
> If upstream doesn't support runtime selection of SIMD-optimized code
> paths based on CPU capabilities, you can build several versions and
> have glibc handle that by putting each version in a special subdirectory
> of
On Wednesday, 22 April 2020 at 16:51, Richard Shaw wrote:
> On Wed, Apr 22, 2020 at 9:28 AM Artur Iwicki wrote:
>
> > Regarding x86_64 and AVX2, last year we had a very heated discussion about
> > this on the mailing list.
> >
> >
> >
On Wed, Apr 22, 2020 at 10:13 AM Michael Cronenworth
wrote:
> On 4/22/20 9:51 AM, Richard Shaw wrote:
> > So it seems what's really needed is a method to support software with
> > optimizations above the baseline without leaving other people behind.
>
> There are varying software that do this.
On 4/22/20 9:51 AM, Richard Shaw wrote:
So it seems what's really needed is a method to support software with
optimizations above the baseline without leaving other people behind.
There are varying software that do this. Glibc is one. FFmpeg is another. There's
also a library that could
On Wed, Apr 22, 2020 at 9:28 AM Artur Iwicki wrote:
> Regarding x86_64 and AVX2, last year we had a very heated discussion about
> this on the mailing list.
>
>
>
Regarding x86_64 and AVX2, last year we had a very heated discussion about this
on the mailing list.
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/MPFXH4Y5LDC5L2VXWKUHAX3WAKBQXR4U/#MPFXH4Y5LDC5L2VXWKUHAX3WAKBQXR4U
tl;dr: there was a proposal to make "x86_64"
Ok, so to sum up...
I can assume NEON on aarch64 and that's about it.
So how do I handle this from a packaging perspective? Do I build multiple
times and create optimized and non-optimized packages?
and -AVX/AVX2/NEON?
I don't want to ExcludeArch as long as it "builds" but without the
* Peter Robinson:
>> > What about VSX on ppc64le?
>>
>> Yes, but only the parts that are in POWER8.
>
> We on;y support POWER8 and later in Fedora for ppc64le.
Yes, that's what I meant: you cannot assume POWER9 or -mfuture.
(There is nothing earlier than POWER8 for ppc64le anyway, some earlier
W dniu 22.04.2020 o 14:52, Florian Weimer pisze:
>> At this time upstream only supports AVX/AVX2/NEON, but if they did
>> add support for SVE on aarch64, can I use it?
> No. I don't think the builders support it yet.
You can assume NEON on aarch64 as it is mandatory part. SVE is in one
or two
On Wed, Apr 22, 2020 at 1:54 PM Florian Weimer wrote:
>
> * Richard Shaw:
>
> > I'm working on packaging a project that makes use of AVX/AVX2/NEON to
> > process and
> > improve the quality of low bitrate human speech:
> >
> > https://github.com/mozilla/LPCNet
> >
> > I'm having trouble
* Richard Shaw:
> I'm working on packaging a project that makes use of AVX/AVX2/NEON to process
> and
> improve the quality of low bitrate human speech:
>
> https://github.com/mozilla/LPCNet
>
> I'm having trouble determining what the base CPU targets for Fedora can
> accommodate.
>
> For
I'm working on packaging a project that makes use of AVX/AVX2/NEON to
process and improve the quality of low bitrate human speech:
https://github.com/mozilla/LPCNet
I'm having trouble determining what the base CPU targets for Fedora can
accommodate.
For example, ss it safe to assume AVX2 on
49 matches
Mail list logo
