Re: [Numpy-discussion] Sayed Adel has joined the developer team.

[Sayed Adel]

On Jan 4 2021, at 6:52 pm, Ralf Gommers  wrote:
>
>
> On Mon, Jan 4, 2021 at 5:35 PM Matti Picus  (mailto:matti.pi...@gmail.com)> wrote:
> >
> > On 1/4/21 6:05 PM, Charles R Harris wrote:
> > > Hi All,
> > >
> > > Sayed Adel is now part of the developer team. His SIMD work has been
> > > substantial and ongoing, may it long continue. Welcome Sayed.
> > >
> > > Chuck
> > >
> > Welcome Sayed.
>
>
> Very well-deserved, thanks for all the great work Sayed!
>
> Cheers,
> Ralf
>
>

Happy to join in! Thanks for the warm welcome,
Sayed

___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Re: [RFC] - numpy/SVML appears to be poorly optimized

[Sayed Adel]

> appears to be poorly optimized.

It should perform well, not poor neither heavily optimized.
> this also makes it quite difficult to improve (with either a better compiler 
> or by hand).
We can put the blame on Intel for not sharing their source code but honestly, 
it seems we had no other option except accept what they provide.
> Some of the glaring issues are:
> 1. register allocation / spilling
> 2. rodata layouts / const-propagation of the values.
> 3. Very odd use of internal functions that really ought to be inlined.

let me add to your list another two points:
- It only works on Linux.
- It only works with AVX512.

> If so, are people open to patches that optimize them (either with new C 
> implementations are in the current assembly
implementations).

Hopefully, we will able to convert them to universal intrinsics (nep-38) one 
day. As one of the team, I will try to push more time for it.
Thanks, Sayed.
On Nov 6 2021, at 5:54 pm, Ralf Gommers  wrote:
>
>
> On Sat, Nov 6, 2021 at 1:18 PM Noah Goldstein  (mailto:goldstein@gmail.com)> wrote:
> > On Fri, Nov 5, 2021 at 1:38 PM Devulapalli, Raghuveer
> > mailto:raghuveer.devulapa...@intel.com)> 
> > wrote:
> > >
> > > They are meant to be optimized. Any contribution to improve them further 
> > > is more than welcome.
> >
> > Fantastic. I don't see any tests for any of the functions in there.
> > Does anyone know where I
> > can find them?
>
>
> Use the main NumPy test suite by updating the svml submodule to the commit 
> with your changes, then run the test suite the regular way (e.g. `python 
> runtests.py`).
>
> Cheers,
> Ralf
>
>
> ___
> NumPy-Discussion mailing list -- numpy-discussion@python.org
> To unsubscribe send an email to numpy-discussion-le...@python.org
> https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
> Member address: se...@imavr.com

___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com

[Numpy-discussion] Re: ANN: NumPy Fellowship Program & Sayed Adel as our first Developer in Residence

[Sayed Adel]

I feel delighted and more motivated to work. I am now working on 
accepting the new reality and organize the tasks entrusted to me. Thanks 
to the NumPy team who supported me from the beginning until now.


Thanks, Sayed.

On 12/2/22 01:03, Brigitta Sipőcz wrote:

Wonderful news, congratulations Sayed!

Brigitta

On Thu, 1 Dec 2022 at 13:18, Ralf Gommers  wrote:

Hi all,

I'm excited to be able to share this announcement on behalf of the
NumPy Steering Council. We have created a new program, the NumPy
Fellowship Program, and offered Sayed Adel the very first
Developer in Residence role. Sayed starts his 1 year tenure in
that role today, and we are really looking forward to him working
on NumPy full-time.

We wrote a blog post about the program, and why we offered the
role to Sayed:
https://blog.scientific-python.org/numpy/fellowship-program/. I've
copied the blog post content at the end of this email.

In addition, here is some more detail on NumPy project finances
that didn't make it into the blog post (which is likely to have a
wider audience than the readership of this mailing list), but is
quite relevant to share here:

Over the past decade, NumPy has accumulated individual donations
as well as payments from Tidelift. NumPy has been a fiscally
sponsored project of NumFOCUS for a decade - meaning that
NumFOCUS, as a 501(c)3 nonprofit, administers funds for NumPy. As
a result, NumPy has accumulated funds for a long time - and those
are now transparently administered on Open Collective
<https://opencollective.com/numpy>. There you will see a "general
fund", currently with a ~$23,000 balance, and two open "projects"
with committed funding - one for the active CZI grant we have, and
one for this new Fellowship Program. Guidelines for using those
funds are described in
https://numpy.org/neps/nep-0048-spending-project-funds.html.

Finally it is worth pointing out that we are now able to solicit
donations on Open Collective, and have added contribution tiers on
the front page of https://opencollective.com/numpy. Until now, we
have never actively solicited donations as a project, because the
accounting support and transparent financial reporting was not in
place. That has changed now though, so we are hoping that with
guidelines to spend funds plus a concrete fellowship program that
we're expecting to be quite impactful, we are now able to
confidently tell people that if they donate to NumPy, we will
manage their contribution well and translate it into more time for
someone on the NumPy team to make NumPy better.

Cheers,
Ralf


blog post content:

The NumPy team is excited to announce the launch of the NumPy
Fellowship Program and the appointment of Sayed Adel (@seiko2plus)
as the first NumPy Developer in Residence. This is a significant
milestone in the history of the project: for the first time, NumPy
is in a position to use its project funds to pay for a full year
of maintainer time. We believe that this will be an impactful
program that will contribute to NumPy’s long-term sustainability
as a community-driven open source project.

Sayed has been making major contributions to NumPy since the start
of 2020, in particular around computational performance. He is the
main author of the NumPy SIMD architecture (NEP 38, docs),
generously shared his knowledge of SIMD instructions with the core
developer team, and helped integrate the work of various volunteer
and industry contributors in this area. As a result, we’ve been
able to expand support to multiple CPU architectures, integrating
contributions from IBM, Intel, Apple, and others, none of which
would have been possible without Sayed. Furthermore, when NumPy
tentatively started using C++ in 2021, Sayed was one of the
proponents of the move and helped with its implementation.

The NumPy Steering Council sees Sayed’s appointment to this role
as both recognition of his past outstanding contributions as well
as an opportunity to continue improving NumPy’s computational
performance. In the next 12 months, we’d like to see Sayed focus
on the following:

    SIMD code maintenance,
    code review of SIMD contributions from others,
    performance-related features,
    sharing SIMD and C++ expertise with the team and growing a
NumPy sub-team around it,
    SIMD build system migration to Meson,
    and wherever else Sayed’s interests take him.

    “I’m both happy and nervous: this is a great opportunity, but
also a great responsibility,” said Sayed in response to his
appointment.

The funds for the NumPy Fellowship Program come from a partnership
with Tidelift and from individual donations. We sincerely thank
   

[Numpy-discussion] Bumping CPU baseline to x86-64-v2

[Sayed Adel]

Hi All,

I wanted to bring your attention to an important change to NumPy that will
affect CPU compatibility requirements on x86.

PR #28896 (https://github.com/numpy/numpy/pull/28896) is reorganizing how
NumPy handles x86 CPU features by moving from individual instruction set
extensions to standardized microarchitecture levels. As part of this
change,

*the minimum CPU requirement for x86 systems will be raised to x86-64-v2*If
your x86 CPU was manufactured in 2009 or later, you likely won't be
affected, unless you're using Intel Atom CPUs released before 2013.
We're making this change in 2025, when CPUs that don't support x86-64-v2
are now over 15 years old. Supporting these antiquated processors increases
maintenance burden and binary size.
Bumping the default baseline can also increase the performance since not
all code paths are dispatched.
--
Cheers,
Sayed

Sayed Adel
GitHub: seiko2plus
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com

[Numpy-discussion] Re: Bumping CPU baseline to x86-64-v2

[Sayed Adel]

Hi Marten,

By default, they won't work at all - Python runtime error will be raised or
segfault/illegal instruction error may occur. However, if Linux distros or
downstream packagers want to change this default setting, they can do it
through the build options, but without manual SIMD support for the baseline
- just the scalar fallbacks. They can still count on the dispatched kernels
for newer processors.

I have also updated the docs providing an example for this case, see:
https://github.com/numpy/numpy/blob/c41541abe9656987c34eb3f5822879ade84ec612/doc/source/reference/simd/build-options.rst#targeting-older-cpus
On Sat, May 17, 2025 at 4:01 PM  wrote:

> Hi Sayed,
>
> I'm a bit confused: does your suggested change mean that prre-2009
> processors won't work at all, or that no use will be made of the (little)
> acceleration that they provided?  The latter seems fine, but not working at
> all seems rather bad. Though I'd think that for any old processors one can
> just fall back to the standard `libm` implementations.
>
> All the best,
>
> Marten
> ___
> NumPy-Discussion mailing list -- numpy-discussion@python.org
> To unsubscribe send an email to numpy-discussion-le...@python.org
> https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
> Member address: se...@imavr.com
>


--
Cheers,
Sayed

Sayed Adel
GitHub: seiko2plus
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com

[Numpy-discussion] Re: Bumping CPU baseline to x86-64-v2

[Sayed Adel]

Hi Jerome,

`X86_V2` includes also `POPCNT CX16 LAHF` along with SSE4.2.
All CPUs that support `SSE4.2` also include these instructions.

I think Ralf is right to exclude servers in the case of using X86_V2 as a
baseline.
Basically, older servers that run architectures like Penryn (17 years ago)
or Intel Core (18 years ago)
are energy monsters with very poor performance compared to modern
alternatives making them increasingly expensive
to operate as energy costs rise.

On Sun, May 18, 2025 at 10:40 AM Jerome Kieffer 
wrote:

> Hi,
>
> First I would like to highlight that "X86_V2" is very specific to the
> implementation in numpy, basically this implies the support of all 128
> bits SIMD extensions, i.e. SSE1,2,3&4, but does apparenty not requires
> any 256bit SIMD (AVX).
>
> Ralph, the stats you are using are made on end-user hardware which gets
> replaced much faster than servers, while numpy is very likely to be
> used on elder hardware, especially for CI where elder hardware still ok
> and often recycled. For example, we are still renting severs which is
> X86_V2 but not X86_V3 for  performing the CI/CD of our projects.
>
> Cheers,
>
> Jerome
>
> On Sat, 17 May 2025 20:55:00 +0200
> Ralf Gommers via NumPy-Discussion  wrote:
>
> > On Sat, May 17, 2025 at 3:00 PM  wrote:
> >
> > > Hi Sayed,
> > >
> > > I'm a bit confused: does your suggested change mean that prre-2009
> > > processors won't work at all, or that no use will be made of the
> (little)
> > > acceleration that they provided?  The latter seems fine, but not
> working at
> > > all seems rather bad.
> >
> >
> > I don't think it's that bad. It's always a tradeoff between performance,
> > binary size, effort, and compatibility. We've had this discussion before,
> > e.g. when moving to SSE3 as the baseline, and decided that we should not
> > drop support for a feature if less than 99.5% of CPUs in the wild has
> > support, but if it's above we can do it. Previous bumps have not given
> any
> > significant pushback from our user base.
> >
> > >From https://github.com/numpy/numpy/issues/27851, half a year ago:
> >
> > *The most widely used data source for determining what hardware is out
> > there is, I believe,
> > https://store.steampowered.com/hwsurvey/?platform=combined
> > . That
> > currently says that SSE3 is at 100%, SSE4.1 at 99.78% and SSE4.2 at
> 99.70%.
> > Meaning that if we bump the baseline up to SSE4.2, we'd only be dropping
> > support for ~0.3% of systems with really old CPUs.*
> >
> > SSE 4.2 support as of today increased to 99.78%, so the number of CPUs
> we'd
> > drop support for moved from 0.3% to 0.22% in 6 months. That means we're
> > still being very conservative after this bump, IIRC more so than when we
> > dropped support for CPUs without SSE3.
> >
> > Cheers,
> > Ralf
> >
> >
> >
> > > Though I'd think that for any old processors one can just fall back to
> the
> > > standard `libm` implementations.
> > >
> > > All the best,
> > >
> > > Marten
> > > ___
> > > NumPy-Discussion mailing list -- numpy-discussion@python.org
> > > To unsubscribe send an email to numpy-discussion-le...@python.org
> > > https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
> > > Member address: ralf.gomm...@gmail.com
> > >
>
>
> --
> Jérôme Kieffer
> ___
> NumPy-Discussion mailing list -- numpy-discussion@python.org
> To unsubscribe send an email to numpy-discussion-le...@python.org
> https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
> Member address: se...@imavr.com
>
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com