[Python-Dev] Re: obmalloc (was Have a big machine and spare time? Here's a possible Python bug.)

[Inada Naoki]

On Tue, Jul 9, 2019 at 9:46 AM Tim Peters  wrote:
>
> >  At last, all size classes has1~3 used/cached memory blocks.
>
> No doubt part of it, but hard to believe it's most of it.  If the loop
> count above really is 10240, then there's only about 80K worth of
> pointers in the final `buf`.

You are right.  List.append is not the major part of memory consumer
of "large" class (8KiB+1 ~ 512KiB).   They are several causes of large
size alloc:

* bm_logging uses StringIO.seek(0); StringIO.truncate() to reset buffer.
  So internal buffer of StringIO become Py_UCS4 array instead of a list
  of strings from the 2nd loop.  This buffer is using same policy to list
  for increase capacity.  `size + size >> 8 + (size < 9 ? 3 : 6)`.
  Actually, when I use `-n 1` option, memory usage is only 9MiB.
* The intern dict.
* Many modules are loaded, and FileIO.readall() is used to read pyc files.
  This creates and deletes various size of bytes objects.
* logging module uses several regular expressions.  `b'\0' * 0xff00` is
  used in sre_compile.
  https://github.com/python/cpython/blob/master/Lib/sre_compile.py#L320


>
> But does it really matter? ;-)  mimalloc "should have" done MADV_FREE
> on the pages holding the older `buf` instances, so it's not like the
> app is demanding to hold on to the RAM (albeit that it may well show
> up in the app's RSS unless/until the OS takes the RAM away).
>

mimalloc doesn't call madvice for each free().  Each size classes
keeps a 64KiB "page".
And several pages (4KiB) in the "page" are committed but not used.

I dumped all "mimalloc page" stat.
https://paper.dropbox.com/doc/mimalloc-on-CPython--Agg3g6XhoX77KLLmN43V48cfAg-fFyIm8P9aJpymKQN0scpp#:uid=671467140288877659659079&h2=memory-usage-of-logging_format

For example:

bin block_size   used capacity reserved
 29   2560  1   22   25 (14 pages are committed, 2560
bytes are in use)
 29   2560 14   25   25 (16 pages are committed,
2560*14 bytes are in use)
 29   2560 11   25   25
 31   3584  15   18 (5 pages are committed, 3584
bytes are in use)
 33   5120  14   12
 33   5120  2   12   12
 33   5120  2   12   12
 37  10240  3   11  409
 41  20480  16  204
 57 327680  12   12

* committed pages can be calculated by `ceil(block_size * capacity /
4096)` roughly.

There are dozen of unused memory block and committed pages in each size classes.
This caused 10MiB+ memory usage overhead on logging_format and logging_simple
benchmarks.


>> I was more intrigued by your first (speed) comparison:
>
> > - spectral_norm: 202 ms +- 5 ms -> 176 ms +- 3 ms: 1.15x faster (-13%)
>
> Now _that's_ interesting ;-)  Looks like spectral_norm recycles many
> short-lived Python floats at a swift pace.  So memory management
> should account for a large part of its runtime (the arithmetic it does
> is cheap in comparison), and obmalloc and mimalloc should both excel
> at recycling mountains of small objects.  Why is mimalloc
> significantly faster?
[snip]
>  obmalloc's `address_in_range()` is definitely a major overhead in its
> fastest `free()` path, but then mimalloc has to figure out which
> thread is doing the freeing (looks cheaper than address_in_range, but
> not free).  Perhaps the layers of indirection that have been wrapped
> around obmalloc over the years are to blame?  Perhaps mimalloc's
> larger (16x) pools and arenas let it stay in its fastest paths more
> often?  I don't know why, but it would be interesting to find out :-)

Totally agree.  I'll investigate this next.

Regards,
-- 
Inada Naoki  
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/MXEE2NOEDAP72RFVTC7H4GJSE2CHP3SX/

[Python-Dev] Docs: audit event table empty

[Christian Heimes]

Hi,

the table with auditing events does not render on docs.python.org,
https://docs.python.org/3.9/library/audit_events.html. Steve and I are
going to present the auditing feature tomorrow at EuroPython. It would
be helpful to have the table available.

It works on Steve's and my local machine without any issues. I suspect
it's either an outdated sphinx version or caching issue. Could somebody
from the docs team or shell access to the docs machine please look into
the matter?

Thanks!
Christian

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/POWT35ULU2CPELWQ6BRTLTU5H3YKHQZW/

[Python-Dev] Re: Docs: audit event table empty

[Julien Palard via Python-Dev]

Hi Christian,

> the table with auditing events does not render on docs.python.org,
> https://docs.python.org/3.9/library/audit_events.html. Steve and I are
> going to present the auditing feature tomorrow at EuroPython. It would
> be helpful to have the table available.

This was not an easy one... and it may be a Sphinx issue, yet I'm still not 
sure, maybe Steve can shed some light on it:

It's the "-j" option of sphinx-build (to parallelize) that causes the issue. I 
double checked it (full commands at the end of the message in case someone want 
to reproduce it):

- Run with -j4 → No table
- Run without -j → Table is here
- Run again with -j4 → No table!
- Run again without -j → Table is back!

I'm patching docsbuild-scripts to stop using -j4 with is not really helpfull 
anyway as docsbuild script is parallelizing by starting multiple sphinx-build 
(for multiple languages / versions).

I also copied the file and invalidated the cache, so 
https://docs.python.org/3.9/library/audit_events.html is good again.

If I'm too slow testing locally and releasing a new docsbuild_script.py, the 
cron MAY break the file again, don't hesitate to poke me if it happen without 
me noticing first.

Full test:

docsbuild@docs:/srv/docsbuild/3.9/cpython-en/Doc$ 
/srv/docsbuild/venv/bin/sphinx-build -b html -d build/doctrees -D 
latex_elements.papersize= -D latex_engine=xelatex -D latex_elements.inputenc= 
-D latex_elements.fontenc= -j4 -q -Ea -A daily=1 -A switchers=1  . build/html
docsbuild@docs:/srv/docsbuild/3.9/cpython-en/Doc$ grep breakpoint 
build/html/library/audit_events.html
docsbuild@docs:/srv/docsbuild/3.9/cpython-en/Doc$ 
/srv/docsbuild/venv/bin/sphinx-build -b html -d build/doctrees -D 
latex_elements.papersize= -D latex_engine=xelatex -D latex_elements.inputenc= 
-D latex_elements.fontenc= -q -Ea -A daily=1 -A switchers=1  . build/html
docsbuild@docs:/srv/docsbuild/3.9/cpython-en/Doc$ grep breakpoint 
build/html/library/audit_events.html
builtins.breakpoint
breakpointhook
[1]
docsbuild@docs:/srv/docsbuild/3.9/cpython-en/Doc$ 
/srv/docsbuild/venv/bin/sphinx-build -b html -d build/doctrees -D 
latex_elements.papersize= -D latex_engine=xelatex -D latex_elements.inputenc= 
-D latex_elements.fontenc= -j4 -q -Ea -A daily=1 -A switchers=1  . build/html
docsbuild@docs:/srv/docsbuild/3.9/cpython-en/Doc$ grep breakpoint 
build/html/library/audit_events.html
docsbuild@docs:/srv/docsbuild/3.9/cpython-en/Doc$ 
/srv/docsbuild/venv/bin/sphinx-build -b html -d build/doctrees -D 
latex_elements.papersize= -D latex_engine=xelatex -D latex_elements.inputenc= 
-D latex_elements.fontenc= -q -Ea -A daily=1 -A switchers=1  . build/html
docsbuild@docs:/srv/docsbuild/3.9/cpython-en/Doc$ grep breakpoint 
build/html/library/audit_events.html
builtins.breakpoint
breakpointhook
[1]

Bests,
-- 
Julien Palard
https://mdk.fr
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/Q23O23HXTD7MSQGQW4Z5RO4XK5XYW2LZ/

[Python-Dev] Keyword arguments with non-string names

[Jeroen Demeyer]

When passing **kwargs to a callable, the expectation is that kwargs is a 
dict with string keys. The interpreter enforces that it's a dict, but it 
does NOT check the types of the keys. It's currently the job of the 
called function to check that. In some cases, this check is not applied:


>>> from collections import OrderedDict
>>> OrderedDict(**{1:2})
OrderedDict([(1, 2)])

So this leads to the question: should the interpreter check the keys of 
a **kwargs dict?


I don't have an answer myself, I'm just asking the question because it 
comes up in https://github.com/python/cpython/pull/13930 and 
https://github.com/python/cpython/pull/14589



Jeroen.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/7CYDQX5T53XK7TWPV3MTYPTHM2KFUBWS/

[Python-Dev] Re: Keyword arguments with non-string names

[Jeroen Demeyer]

On 2019-07-09 14:36, Jeroen Demeyer wrote:

So this leads to the question: should the interpreter check the keys of
a **kwargs dict?


Some pointers:
- https://bugs.python.org/issue8419
- https://bugs.python.org/issue29360
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/GOM22KOBQD5Q42WPW5RYQGCWNDAY5T2V/

[Python-Dev] Optimizing pymalloc (was obmalloc

[Inada Naoki]

On Tue, Jul 9, 2019 at 5:29 PM Inada Naoki  wrote:
>
> On Tue, Jul 9, 2019 at 9:46 AM Tim Peters  wrote:
> >
> >> I was more intrigued by your first (speed) comparison:
> >
> > > - spectral_norm: 202 ms +- 5 ms -> 176 ms +- 3 ms: 1.15x faster (-13%)
> >
> > Now _that's_ interesting ;-)  Looks like spectral_norm recycles many
> > short-lived Python floats at a swift pace.  So memory management
> > should account for a large part of its runtime (the arithmetic it does
> > is cheap in comparison), and obmalloc and mimalloc should both excel
> > at recycling mountains of small objects.  Why is mimalloc
> > significantly faster?
>
> Totally agree.  I'll investigate this next.
>

I compared "perf" output of mimalloc and pymalloc, and I succeeded to
optimize pymalloc!

$ ./python bm_spectral_norm.py --compare-to ./python-master
python-master: . 199 ms +- 1 ms
python: . 182 ms +- 4 ms

Mean +- std dev: [python-master] 199 ms +- 1 ms -> [python] 182 ms +-
4 ms: 1.10x faster (-9%)

mimalloc uses many small static (inline) functions.
On the other hand, pymalloc_alloc and pymalloc_free is large function
containing slow/rare path.

PyObject_Malloc inlines pymalloc_alloc, and PyObject_Free inlines pymalloc_free.
But compiler doesn't know which is the hot part in pymalloc_alloc and
pymalloc_free.
So gcc failed to chose code to inline.  Remaining part of
pymalloc_alloc and pymalloc_free
are called and many push/pop are executed because they contains complex logic.

So I tried to use LIKELY/UNLIKELY macro to teach compiler hot part.
But I need to use
"static inline" for pymalloc_alloc and pymalloc_free yet [1].
Generated assembly is optimized
well, the hot code is in top of the PyObject_Malloc [2] and PyObject_Free [3].
But there are many code duplication in PyObject_Malloc and
PyObject_Calloc, etc...

[1] https://github.com/python/cpython/pull/14674/files
[2] 
https://gist.github.com/methane/ab8e71c00423a776cb5819fa1e4f871f#file-obmalloc-s-L232-L274
[3] 
https://gist.github.com/methane/ab8e71c00423a776cb5819fa1e4f871f#file-obmalloc-s-L2-L32

I will try to split pymalloc_alloc and pymalloc_free to smaller functions.

Except above, there is one more important difference.

pymalloc return free pool to freepool list soon when pool become empty.
On the other hand, mimalloc return "page" (it's similar to "pool" in pymalloc)
not everytime when it's empty [4].  So they can avoid rebuilding linked list of
free blocks.
I think pymalloc should do same optimization.

[4] 
https://github.com/microsoft/mimalloc/blob/1125271c2756ee1db1303918816fea35e08b3405/src/page.c#L365-L375

BTW, which is proper name? pymalloc, or obmalloc.

Regards,
-- 
Inada Naoki  
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/YWNWHGTJUMZ4D34DPRFXECF7O7GRJK2M/

[Python-Dev] Re: Docs: audit event table empty

[Christian Heimes]

On 09/07/2019 14.02, Julien Palard wrote:
> Hi Christian,
> 
>> the table with auditing events does not render on docs.python.org,
>> https://docs.python.org/3.9/library/audit_events.html. Steve and I are
>> going to present the auditing feature tomorrow at EuroPython. It would
>> be helpful to have the table available.
> 
> This was not an easy one... and it may be a Sphinx issue, yet I'm still not 
> sure, maybe Steve can shed some light on it:
> 
> It's the "-j" option of sphinx-build (to parallelize) that causes the issue. 
> I double checked it (full commands at the end of the message in case someone 
> want to reproduce it):
> 
> - Run with -j4 → No table
> - Run without -j → Table is here
> - Run again with -j4 → No table!
> - Run again without -j → Table is back!
> 
> I'm patching docsbuild-scripts to stop using -j4 with is not really helpfull 
> anyway as docsbuild script is parallelizing by starting multiple sphinx-build 
> (for multiple languages / versions).
> 
> I also copied the file and invalidated the cache, so 
> https://docs.python.org/3.9/library/audit_events.html is good again.
> 
> If I'm too slow testing locally and releasing a new docsbuild_script.py, the 
> cron MAY break the file again, don't hesitate to poke me if it happen without 
> me noticing first.

Fantastic! It'll do for now. Thank you!

I'll follow up with you after EuroPython.

Christian
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/6IW5QY7VRSILMJ5R475VSM25V7OAVQDB/

[Python-Dev] Re: Further off-topic: webmaster@ volunteers

[Steve Holden]

[python-dev -> Bcc]

There are questions to answer, but they are mostly of a pretty mundane
kind. Technical issues are deflected by the auto-response, which contains
many pointers to sources of possible assistance, and so can usually be
disregarded or followed up with a simple response underlining the need to
seek assistance elsewhere. We see remarkably little spam, so moderating the
list isn't an issue and I've been doing that unaided for over a year
without noticing.

Kind regards,
Steve Holden


On Mon, Jul 8, 2019 at 11:56 PM Ethan Furman  wrote:

> On 07/08/2019 03:12 PM, Steve Holden wrote:
>
> > [even further off-topic]
> >
> > While I have the attention of so many community-spirited individuals, I
> might mention that webmaster@ could do with a few lurkers to get used to
> the traffic. At present it's solely maintained by Mats Wichmann and me, and
> I'm planning to step back from all PSF duties soon. The duties aren't
> heavy, but the traffic is fairly regular and most of it benefits from being
> answered sooner rather than later.
>
> What kind of traffic?  Actually answering questions or the same type of
> gate-keeper duties as the list mods?
>
> --
> ~Ethan~
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/MEQPOPC5AQV5EGPDC6EP7WMQ6YR4DB4A/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/BANAFWMIAKTSBVCY7QAOMEZRL5U3QREC/

[Python-Dev] Re: Keyword arguments with non-string names

[Janzert]

On 7/9/2019 8:50 AM, Jeroen Demeyer wrote:

On 2019-07-09 14:36, Jeroen Demeyer wrote:

So this leads to the question: should the interpreter check the keys of
a **kwargs dict?


Some pointers:
- https://bugs.python.org/issue8419
- https://bugs.python.org/issue29360


It was also discussed last October; which I believe is the most recent 
previous discussion:


https://mail.python.org/pipermail/python-dev/2018-October/155435.html

Janzert
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/JWNYI6K4VNJLBCYG6NHQ6OB7JOOKFWLF/

[Python-Dev] Re: Docs: audit event table empty

[Karthikeyan]

On Tue, Jul 9, 2019 at 5:34 PM Julien Palard via Python-Dev <
python-dev@python.org> wrote:

> Hi Christian,
>
> > the table with auditing events does not render on docs.python.org,
> > https://docs.python.org/3.9/library/audit_events.html. Steve and I are
> > going to present the auditing feature tomorrow at EuroPython. It would
> > be helpful to have the table available.
>
> This was not an easy one... and it may be a Sphinx issue, yet I'm still
> not sure, maybe Steve can shed some light on it:
>
> It's the "-j" option of sphinx-build (to parallelize) that causes the
> issue. I double checked it (full commands at the end of the message in case
> someone want to reproduce it):
>
> - Run with -j4 → No table
> - Run without -j → Table is here
> - Run again with -j4 → No table!
> - Run again without -j → Table is back!
>

I can reproduce the same with table not appearing in parallel builds and
table is successfully built on non-parallel builds. On adding -j4 to
ALLSPHINXOPTS in my Makefile in Docs/ folder there is no table generated.
Currently, the audit events are collected in a dictionary and are stored in
self.state.document.settings.env that is initialized with empty dict in
AuditEvent directive [0].

* On non-parallel builds when I use print statement with hasattr to check
for all_audit_events, it's False for first time and then remains True with
tuple set for rest of the collection. In process_audit_events for
non-parallel builds the attribute is set with a dictionary of all audit
events.
* On parallel builds when I use print statement with hasattr to check for
all_audit_events, it returns True and False randomly throughout the build.
I guess it's due to attribute not being properly initialized. In
process_audit_events for parallel builds the all_audit_events attribute is
not at all set during table creation and falls back to empty tuple writing
no rows to the table.

I am not sure if modifying the env attribute on parallel builds is safe
since I couldn't find any guarantees from the sphinx docs. The default docs
Makefile is not parallel which could be the reason it was not reproducible
locally.

Thanks for fixing this.

[0]
https://github.com/python/cpython/blob/73ea54620a6f91c3f2e53880373dd47813691a21/Doc/tools/extensions/pyspecific.py#L187


> I'm patching docsbuild-scripts to stop using -j4 with is not really
> helpfull anyway as docsbuild script is parallelizing by starting multiple
> sphinx-build (for multiple languages / versions).
>
> I also copied the file and invalidated the cache, so
> https://docs.python.org/3.9/library/audit_events.html is good again.
>
> If I'm too slow testing locally and releasing a new docsbuild_script.py,
> the cron MAY break the file again, don't hesitate to poke me if it happen
> without me noticing first.
>
> Full test:
>
> docsbuild@docs:/srv/docsbuild/3.9/cpython-en/Doc$
> /srv/docsbuild/venv/bin/sphinx-build -b html -d build/doctrees -D
> latex_elements.papersize= -D latex_engine=xelatex -D
> latex_elements.inputenc= -D latex_elements.fontenc= -j4 -q -Ea -A daily=1
> -A switchers=1  . build/html
> docsbuild@docs:/srv/docsbuild/3.9/cpython-en/Doc$ grep breakpoint
> build/html/library/audit_events.html
> docsbuild@docs:/srv/docsbuild/3.9/cpython-en/Doc$
> /srv/docsbuild/venv/bin/sphinx-build -b html -d build/doctrees -D
> latex_elements.papersize= -D latex_engine=xelatex -D
> latex_elements.inputenc= -D latex_elements.fontenc= -q -Ea -A daily=1 -A
> switchers=1  . build/html
> docsbuild@docs:/srv/docsbuild/3.9/cpython-en/Doc$ grep breakpoint
> build/html/library/audit_events.html
> builtins.breakpoint
>  class="pre">breakpointhook
>  href="functions.html#breakpoint">[1]
> docsbuild@docs:/srv/docsbuild/3.9/cpython-en/Doc$
> /srv/docsbuild/venv/bin/sphinx-build -b html -d build/doctrees -D
> latex_elements.papersize= -D latex_engine=xelatex -D
> latex_elements.inputenc= -D latex_elements.fontenc= -j4 -q -Ea -A daily=1
> -A switchers=1  . build/html
> docsbuild@docs:/srv/docsbuild/3.9/cpython-en/Doc$ grep breakpoint
> build/html/library/audit_events.html
> docsbuild@docs:/srv/docsbuild/3.9/cpython-en/Doc$
> /srv/docsbuild/venv/bin/sphinx-build -b html -d build/doctrees -D
> latex_elements.papersize= -D latex_engine=xelatex -D
> latex_elements.inputenc= -D latex_elements.fontenc= -q -Ea -A daily=1 -A
> switchers=1  . build/html
> docsbuild@docs:/srv/docsbuild/3.9/cpython-en/Doc$ grep breakpoint
> build/html/library/audit_events.html
> builtins.breakpoint
>  class="pre">breakpointhook
>  href="functions.html#breakpoint">[1]
>
> Bests,
> --
> Julien Palard
> https://mdk.fr
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/Q23O23HXTD7MSQGQW4Z5RO4XK5XYW2LZ/
>


-- 
Regards,
Karthikeyan S
___

[Python-Dev] Re: Keyword arguments with non-string names

[Jeroen Demeyer]

Thanks for the pointer, but that's more about allowing strings which are 
not valid identifiers. I'm talking about passing non-strings and more 
specifically about the C protocol. For Python functions, non-string 
keyword arguments are already disallowed, but that's because of the 
implementation of the "function" object, it's not enforced by the 
CPython core.


Jeroen.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/JSAQAZD2GREBH72VCHO5ZZJQSYQHLTOV/

[Python-Dev] Re: Keyword arguments with non-string names

[Guido van Rossum]

Thinking about this, I don't believe allowing non-string keys here are a
desirable feature.

It's tempting not to check for this in some cases where it does no harm
(skipping the check shaves a few microseconds off execution time), but I
think the reference manual should require strings here and we would do well
to tighten the implementation.

We may find though that this has accidentally become a gray area that some
code has come to depend on, so we may have to deprecate it. This really
depends on how much code depends on it though, there's no strict rule for
such cases.

On Tue, Jul 9, 2019 at 9:42 AM Jeroen Demeyer  wrote:

> Thanks for the pointer, but that's more about allowing strings which are
> not valid identifiers. I'm talking about passing non-strings and more
> specifically about the C protocol. For Python functions, non-string
> keyword arguments are already disallowed, but that's because of the
> implementation of the "function" object, it's not enforced by the
> CPython core.
>
> Jeroen.
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/JSAQAZD2GREBH72VCHO5ZZJQSYQHLTOV/
>


-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him/his **(why is my pronoun here?)*

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/BITO2WT5CE43JCCY2BFXDRCEHKYK3FJF/

[Python-Dev] Re: Optimizing pymalloc (was obmalloc

[Tim Peters]

[Inada Naoki ,
 looking into why mimalloc did so much better on spectral_norm]
> I compared "perf" output of mimalloc and pymalloc, and I succeeded to
> optimize pymalloc!
>
> $ ./python bm_spectral_norm.py --compare-to ./python-master
> python-master: . 199 ms +- 1 ms
> python: . 182 ms +- 4 ms
>
> Mean +- std dev: [python-master] 199 ms +- 1 ms -> [python] 182 ms +-
> 4 ms: 1.10x faster (-9%)

Yay!!  Nice :-)


> mimalloc uses many small static (inline) functions.

Too many , if you ask me ;-)  Really, the enormous number of tiny
functions makes the code very hard to follow for me.  OTOH, the tiny
number of enormous functions in pymalloc makes that hard to follow too
:-(

> On the other hand, pymalloc_alloc and pymalloc_free is large function
> containing slow/rare path.

obmalloc.c was written when compiler inlining was barely a thing.
Some restructuring is a fine idea - overdue, in fact.


> PyObject_Malloc inlines pymalloc_alloc, and PyObject_Free inlines 
> pymalloc_free.
> But compiler doesn't know which is the hot part in pymalloc_alloc and
> pymalloc_free.
> So gcc failed to chose code to inline.  Remaining part of
> pymalloc_alloc and pymalloc_free
> are called and many push/pop are executed because they contains complex logic.
>
> So I tried to use LIKELY/UNLIKELY macro to teach compiler hot part.
> But I need to use
> "static inline" for pymalloc_alloc and pymalloc_free yet [1].
> Generated assembly is optimized
> well, the hot code is in top of the PyObject_Malloc [2] and PyObject_Free [3].
> But there are many code duplication in PyObject_Malloc and
> PyObject_Calloc, etc...
>
> [1] https://github.com/python/cpython/pull/14674/files
> [2] 
> https://gist.github.com/methane/ab8e71c00423a776cb5819fa1e4f871f#file-obmalloc-s-L232-L274
> [3] 
> https://gist.github.com/methane/ab8e71c00423a776cb5819fa1e4f871f#file-obmalloc-s-L2-L32
>
> I will try to split pymalloc_alloc and pymalloc_free to smaller functions.

Yes, splitting out the slower paths should be a win.

Note this is one reason I remain keen to increase pool size:  the
bigger the pools, the more objects can be handed out & reclaimed
_from_ the fastest paths.  You've now discovered that "the fastest
paths" are, for pragmatic compiler-is-overwhelmed reasons,
significantly slower than they "should be".


> Except above, there is one more important difference.
>
> pymalloc return free pool to freepool list soon when pool become empty.

Fine by me, & I think it should continue to do so.  Details below.

> On the other hand, mimalloc return "page" (it's similar to "pool" in pymalloc)
> not everytime when it's empty [4].  So they can avoid rebuilding linked list 
> of
> free blocks.

pymalloc never returns anything to the system at smaller than "arena"
granularity, so it's not a big deal at all _merely_ to link and unlink
a pool to/from an arena's freepool list.  There's no possibility than
any byte in the pool can change while the pool is sitting on a
freepools list.

If we freed the last pool of a given size class, and next need to
allocate another object of that size class (most common), it's cheap:
when the pool is unlinked from the pool free list, it sees that the
pool's last size class is the same as the size class being requested,
and skips almost all pool initialization (the pool is already fully
prepared for objects of this size class).

init_pool:
/* Frontlink to used pools. */
next = usedpools[size + size]; /* == prev */
pool->nextpool = next;
pool->prevpool = next;
next->nextpool = pool;
next->prevpool = pool;
pool->nalloc = 1;
if (pool->szidx == size) {//   HERE xxxc
/* Luckily, this pool last contained blocks
 * of the same size class, so its header
 * and free list are already initialized.
 */
bp = pool->freeblock;
assert(bp != NULL);
pool->freeblock = *(block **)bp;
goto success;// xxx FASTEST PATH xx
}
   // and here there's a mound of code in case
   // the size classes don't match, including code
   // to restart the process of linking the pool's
   // blocks into a free list.

So In the common case, the pool's free list is reused exactly as-is at
the time the pool was linked to the freepool list.

> I think pymalloc should do same optimization.

As above, I believe pymalloc is already optimal in this case,

On the other end, something to consider:  when a block is freed from
an entirely used pool, the pool now contains one free block, and is
linked to the front of usedpools[sizeclass].  So the next request for
a block of that size will come from that pool, which will again cause
the pool to become entirely used.

That's a kind of possible thrashing, and acts against mimalloc's
(sane, to my eyes) desire to _entirely_ use up a given pool ("page")
once it starts pass

[Python-Dev] Re: Docs: audit event table empty

[Terry Reedy]

On 7/9/2019 6:44 AM, Christian Heimes wrote:

Hi,

the table with auditing events does not render on docs.python.org,
https://docs.python.org/3.9/library/audit_events.html. Steve and I are
going to present the auditing feature tomorrow at EuroPython. It would
be helpful to have the table available.

It works on Steve's and my local machine without any issues. I suspect
it's either an outdated sphinx version or caching issue. Could somebody
from the docs team or shell access to the docs machine please look into
the matter?


After they did so, this now works for me.  Looks great.

--
Terry Jan Reedy
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/JWFXUUO3PXX4ATLDKAPVGLWW7NH7FB6Y/

[Python-Dev] Re: Docs: audit event table empty

[Terry Reedy]

On 7/9/2019 3:53 PM, Terry Reedy wrote:


https://docs.python.org/3.9/library/audit_events.html. Steve and I are
going to present the auditing feature tomorrow at EuroPython.


That should be interesting.  My experiment with the following

>>> def audit(event, args): print(event, args)

>>> import sys; sys.addaudithook(audit)

produced a line, on IDLE, like this:
builtins.id (1501408069568,)

builtins.id is not in the table.  Should it be?



--
Terry Jan Reedy
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/3WJUP7G5TGIGN22WSH2HFDHMIXDJ7AJ6/

[Python-Dev] Re: Optimizing pymalloc (was obmalloc

[Neil Schemenauer]

On 2019-07-09, Inada Naoki wrote:
> So I tried to use LIKELY/UNLIKELY macro to teach compiler hot part.
> But I need to use
> "static inline" for pymalloc_alloc and pymalloc_free yet [1].

I think LIKELY/UNLIKELY is not helpful if you compile with LTO/PGO
enabled.  So, I would try that first.  Also, if you use relatively
small static functions that are defined before use (no forward
declarations), I have found that GCC is usually smart about inlining
them.  So, I don't think you should have to use "static inline"
rather than just "static".

Good work looking into this.  Should be some relatively easy
performance win.

Cheers,

  Neil
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/TISXQ7E3AA5BPMVPTDWKDWBKV5VPVOTI/