On Tue, Dec 3, 2019 at 8:20 AM Mark Shannon <m...@hotpy.org> wrote:
> The Python language does not specify limits for many of its features.
> Not having any limit to these values seems to enhance programmer freedom,
> at least superficially, but in practice the CPython VM and other Python
> virtual
> machines have implicit limits or are forced to assume that the limits are
> astronomical, which is expensive.

The basic idea makes sense to me. Well-defined limits that can be
supported properly are better than vague limits that are supported by
wishful thinking.

> This PR lists a number of features which are to have a limit of one
> million.
> If a language feature is not listed but appears unlimited and must be
> finite,
> for physical reasons if no other, then a limit of one million should be
> assumed.

This language is probably too broad... for example, there's certainly
a limit on how many objects can be alive at the same time due to the
physical limits of memory, but that limit is way higher than a
million.

> This PR proposes that the following language features and runtime values
> be limited to one million.
>
> * The number of source code lines in a module
> * The number of bytecode instructions in a code object.
> * The sum of local variables and stack usage for a code object.
> * The number of distinct names in a code object
> * The number of constants in a code object.

These are all attributes of source files, so sure, a million is
plenty, and the interpreter spends a ton of time manipulating tables
of these things.

> * The number of classes in a running interpreter.

This one isn't as obvious to me... classes are basically just objects
of type 'type', and there is definitely code out there that creates
classes dynamically. A million still seems like a lot, and I'm not
saying I'd *recommend* a design that involves creating millions of
different type objects, but it might exist already.

> * The number of live coroutines in a running interpreter.

I don't get this one. I'm not thinking of any motivation (the
interpreter doesn't track live coroutines differently from any other
object), and the limit seems dangerously low. A million coroutines
only requires a few gigabytes of RAM, and there are definitely people
who run single process systems with >1e6 concurrent tasks (random
example: https://goroutines.com/10m)

I don't know if there's anyone doing this in *Python right now, due to
Python's performance limitations, but it's nowhere near as silly as a
function with a million local variables.

> Total number of classes in a running interpreter
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> This limit has to the potential to reduce the size of object headers
> considerably.
>
> Currently objects have a two word header, for objects without references
> (int, float, str, etc.) or a four word header for objects with references.
> By reducing the maximum number of classes, the space for the class reference
> can be reduced from 64 bits to fewer than 32 bits allowing a much more
> compact header.
>
> For example, a super-compact header format might look like this:
>
> .. code-block::
>
>      struct header {
>          uint32_t gc_flags:6; /* Needs finalisation, might be part of a
> cycle, etc. */
>          uint32_t class_id:26; /* Can be efficiently mapped to address
> by ensuring suitable alignment of classes */
>          uint32_t refcount; /* Limited memory or saturating */
>      }
>
> This format would reduce the size of a Python object without slots, on a
> 64 bit machine, from 40 to 16 bytes.

In this example, I can't figure out how you'd map your 26 bit class_id
to a class object. On a 32-bit system it would be fine, you just need
64 byte alignment, but you're talking about 64-bit systems, so... I
know you aren't suggesting classes should have 2**(64 - 26) =
~3x10**11 byte alignment :-)

-n

--
Nathaniel J. Smith -- https://vorpus.org
_______________________________________________
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/TL62SYQ6DGCCLRTIGMCUFAT5UEWMB7KN/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to