[Numpy-discussion] Re: [RFC] - numpy/SVML appears to be poorly optimized
On 6/11/21 6:56 pm, Sayed Adel wrote: > 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. Note the benchmarks on Sayed's PR [0] to move tanh to universal intrinsics. It not only supplies the routines for all universal-intrinsics-supported platforms, it even slightly increased performance on AVX512 (usual disclaimers about dangers of comparing benchmarks apply). Matti [0] https://github.com/numpy/numpy/pull/20363 ___ 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: Code formatters
On Sun, Nov 14, 2021 at 4:28 PM Juan Nunez-Iglesias wrote: > > > On 15 Nov 2021, at 8:23 am, Stefan van der Walt > wrote: > > On Sun, Nov 14, 2021, at 09:13, Charles R Harris wrote: > > The black formatter is much improved in its latest version and I think > good enough to start using. The main drawbacks that I see are: > >- all operators, including '*' and '/', get spaces around them, >- very long strings are not broken into multiple lines, >- lists, tuples, and function signatures are either on one line, or >broken into multiple lines of one element/argument each, >- the formatting of extended logical expressions could be improved to >emphasize the priority of 'and' over 'or' operators > > > We've also been having a conversation around mathematical formatting here: > https://discuss.scientific-python.org/t/how-to-format-mathematical-expressions/62/8 > > I tried yapf recently, and was pleased with the output. One concern about > yapf was that it has many configuration options: but the only important > thing is that you fix the knobs, then you simply have a different version > of black. > > > In my experience, while none of these tools are perfect, not having to > have discussions around formatting is completely worth it! > > > +1 on everything Stéfan said. I never liked black’s formatting, but I have > *absolutely* appreciated having zero discussions/push commits/code > suggestions to deal with formatting in napari. I have since added yapf to > my own repos with a config I like *and* added yapf auto-formatting-on-save > to my VSCode, and I don’t even have to have formatting discussions with > *myself* anymore. 😂 It’s very liberating! > > For reference, here’s my yapf config: > > > https://github.com/jni/skan/blob/74507344b4cd4453cc43b4dbd0b5742fc08eb5a0/.style.yapf > > As Stéfan said, fix the knobs (yours might be different), then forget > about it! > > Oh, and yes, yapf does allow formatting only the diff. I agree that > reformatting the entire code base is problematic. > > yapf does look like a better alternative than black. Chuck ___ 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: Code formatters
On Mon, 2021-11-15 at 14:28 -0700, Charles R Harris wrote:
> On Sun, Nov 14, 2021 at 4:28 PM Juan Nunez-Iglesias
>
> wrote:
> >
> > https://github.com/jni/skan/blob/74507344b4cd4453cc43b4dbd0b5742fc08eb5a0/.style.yapf
> >
> > As Stéfan said, fix the knobs (yours might be different), then
> > forget
> > about it!
> >
> > Oh, and yes, yapf does allow formatting only the diff. I agree that
> > reformatting the entire code base is problematic.
> >
> >
> yapf does look like a better alternative than black.
I think we could give try yapf/clang-format a shot. Frankly, I would
be very happy to just defer most/all of the knob setting and making the
call on adoption to you Chuck :).
(Unless maybe anyone aims for cross-project sharing of these already.)
In the end, I expect we will all quickly get used to the vast majority
of changes. And projects that adopted auto-formatters seem happy...
clang-format has a couple of knobs we could play around with, e.g.:
AlignAfterOpenBracket: DontAlign
helps with the `if` issue (but comes at additional indentation costs).
And there are the penalty options, e.g.:
PenaltyBreakString: 150 # random value
which, if set, seem to allow a few characters beyond the 79 limit if it
saves a line.
There are some places where, IMO, existing line breaks make more sense
than automatic breaks:
if (npy_parse_arguments("astype", args, len_args, kwnames,
"dtype", &PyArray_DescrConverter, &dtype,
"|order", &PyArray_OrderConverter, &order,
"|casting", &PyArray_CastingConverter, &casting,
"|subok", &PyArray_PythonPyIntFromInt, &subok,
"|copy", &PyArray_PythonPyIntFromInt, &forcecopy,
NULL, NULL, NULL) < 0) {
where each parameter starts on its own line, and:
static struct PyMethodDef array_module_methods[] = {
{"_get_implementing_args",
(PyCFunction)array__get_implementing_args,
METH_VARARGS, NULL},
{"_get_ndarray_c_version",
(PyCFunction)array__get_ndarray_c_version,
METH_VARARGS|METH_KEYWORDS, NULL},
...
(Less clear, but in that case I really like the uniformity of having
the name on its own line.)
But I guess we could add `\\` to force line breaks, or disable
formatting for those method defs.
Cheers,
Sebastian
>
> Chuck
> ___
> 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: sebast...@sipsolutions.net
signature.asc
Description: This is a digitally signed message part
___
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: Code formatters
On Mon, Nov 15, 2021 at 3:02 PM Sebastian Berg
wrote:
> On Mon, 2021-11-15 at 14:28 -0700, Charles R Harris wrote:
> > On Sun, Nov 14, 2021 at 4:28 PM Juan Nunez-Iglesias
> >
> > wrote:
> > >
>
>
>
> > >
> https://github.com/jni/skan/blob/74507344b4cd4453cc43b4dbd0b5742fc08eb5a0/.style.yapf
> > >
> > > As Stéfan said, fix the knobs (yours might be different), then
> > > forget
> > > about it!
> > >
> > > Oh, and yes, yapf does allow formatting only the diff. I agree that
> > > reformatting the entire code base is problematic.
> > >
> > >
> > yapf does look like a better alternative than black.
>
>
> I think we could give try yapf/clang-format a shot. Frankly, I would
> be very happy to just defer most/all of the knob setting and making the
> call on adoption to you Chuck :).
> (Unless maybe anyone aims for cross-project sharing of these already.)
>
Thanks :)
>
> In the end, I expect we will all quickly get used to the vast majority
> of changes. And projects that adopted auto-formatters seem happy...
>
>
> clang-format has a couple of knobs we could play around with, e.g.:
>
> AlignAfterOpenBracket: DontAlign
>
> helps with the `if` issue (but comes at additional indentation costs).
> And there are the penalty options, e.g.:
>
> PenaltyBreakString: 150 # random value
>
> which, if set, seem to allow a few characters beyond the 79 limit if it
> saves a line.
>
>
I was hoping someone else would tweak it as we gain experience. I don't
think any of the formatting options should be blessed until we gain some
experience. At some point it will become "good enough".
> There are some places where, IMO, existing line breaks make more sense
> than automatic breaks:
>
> if (npy_parse_arguments("astype", args, len_args, kwnames,
> "dtype", &PyArray_DescrConverter, &dtype,
> "|order", &PyArray_OrderConverter, &order,
> "|casting", &PyArray_CastingConverter, &casting,
> "|subok", &PyArray_PythonPyIntFromInt, &subok,
> "|copy", &PyArray_PythonPyIntFromInt, &forcecopy,
> NULL, NULL, NULL) < 0) {
>
> where each parameter starts on its own line, and:
>
> static struct PyMethodDef array_module_methods[] = {
> {"_get_implementing_args",
> (PyCFunction)array__get_implementing_args,
> METH_VARARGS, NULL},
> {"_get_ndarray_c_version",
> (PyCFunction)array__get_ndarray_c_version,
> METH_VARARGS|METH_KEYWORDS, NULL},
> ...
>
> (Less clear, but in that case I really like the uniformity of having
> the name on its own line.)
>
> But I guess we could add `\\` to force line breaks, or disable
> formatting for those method defs.
>
Chuck
___
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
