[Python-ideas] Re: Permanent code objects (less memory, quicker load, less Unix Copy On Write)

[Jeethu Rao]

On a related note, there was a patch that I’d written for Python 3.6 to store 
code objects in the read only segment of the interpreter binary for faster 
interpreter startup.
I’d sent the patch to Larry Hastings, who graciously ported it to Python 3.8 
and posted it on bpo[1].

- Jeethu

[1]: https://bugs.python.org/issue34690

> On 21 Jun 2020, at 00:47, Guido van Rossum  wrote:
>
> Hm, I remember Greg's free threading too, but that's not the idea I was 
> trying to recall this time. There really was something about bytecode objects 
> being loaded from a read-only segment to speed up code loading. (Much quicker 
> than unmarshalling a .pyc file.) I don't think we ever got the details worked 
> out to the point where we could benchmark.
>
> On Sat, Jun 20, 2020 at 4:57 AM Jonathan Fine  wrote:
>
>> Hi All
>>
>> Guido wrote:
>>
>>> I remember vaguely that about two decades ago Greg Stein hatched an idea 
>>> for code objects loaded from a read-only segment in shared libraries.
>>
>> [Thank you for this, Guido. Your memory is good.]
>>
>> Here's a thread from 2009, where Guido said: Greg Stein reached this same 
>> conclusion (and similar numbers) over 10 years ago ...
>>
>> Subject: Remove GIL with CAS instructions?
>> https://mail.python.org/archives/list/python-ideas@python.org/thread/6ZONFLMGCFP66AOMAFHY7ZB2VH3MUCM4/#XV3GBWJEYP7UAVSZXWRXABR7BVQMEKS2
>>
>> I looked up https://en.wikipedia.org/wiki/Compare-and-swap to read about CAS.
>>
>> Guido said this in the context of Antione's statement: Which makes me agree 
>> with the commonly expressed opinion that CPython would probably need to 
>> ditch refcounting (at least in the critical paths) if we want to remove the 
>> GIL.
>>
>> In 2007 Guido posted to Artima: It isn't Easy to Remove the GIL:
>> https://www.artima.com/weblogs/viewpost.jsp?thread=214235
>>
>> In this post Guido writes: In 1999 Greg Stein (with Mark Hammond?) produced 
>> a fork of Python (1.5 I believe) that removed the GIL, replacing it with 
>> fine-grained locks on all mutable data structures. [...] However, after 
>> benchmarking, it was shown that even on the platform with the fastest 
>> locking primitive (Windows at the time) it slowed down single-threaded 
>> execution nearly two-fold.
>>
>> Guido also referenced this write-up from Greg:
>> https://mail.python.org/pipermail/python-dev/2001-August/017099.html
>>
>> I hope this helps.
>>
>> --
>> Jonathan
>>
>>>
>
> --
>
> --Guido van Rossum (python.org/~guido)
> Pronouns: he/him [(why is my pronoun 
> here?)](http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/)___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/J3473XFSM6LLLTXL3BVXF67TJ64FHQGM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Permanent code objects (less memory, quicker load, less Unix Copy On Write)

[Guido van Rossum]

Hm, I remember Greg's free threading too, but that's not the idea I was
trying to recall this time. There really was something about bytecode
objects being loaded from a read-only segment to speed up code loading.
(Much quicker than unmarshalling a .pyc file.) I don't think we ever got
the details worked out to the point where we could benchmark.

On Sat, Jun 20, 2020 at 4:57 AM Jonathan Fine  wrote:

> Hi All
>
> Guido wrote:
>
>  I remember vaguely that about two decades ago Greg Stein hatched an idea
>> for code objects loaded from a read-only segment in shared libraries.
>>
>
> [Thank you for this, Guido. Your memory is good.]
>
> Here's a thread from 2009, where Guido said: Greg Stein reached this same
> conclusion (and similar numbers) over 10 years ago ...
>
> Subject: Remove GIL with CAS instructions?
>
> https://mail.python.org/archives/list/python-ideas@python.org/thread/6ZONFLMGCFP66AOMAFHY7ZB2VH3MUCM4/#XV3GBWJEYP7UAVSZXWRXABR7BVQMEKS2
>
> I looked up https://en.wikipedia.org/wiki/Compare-and-swap to read about
> CAS.
>
> Guido said this in the context of Antione's statement: Which makes me
> agree with the commonly expressed opinion that CPython would probably need
> to ditch refcounting (at least in the critical paths) if we want to remove
> the GIL.
>
> In 2007 Guido posted to Artima: It isn't Easy to Remove the GIL:
> https://www.artima.com/weblogs/viewpost.jsp?thread=214235
>
> In this post Guido writes:  In 1999 Greg Stein (with Mark Hammond?)
> produced a fork of Python (1.5 I believe) that removed the GIL, replacing
> it with fine-grained locks on all mutable data structures. [...] However,
> after benchmarking, it was shown that even on the platform with the fastest
> locking primitive (Windows at the time) it slowed down single-threaded
> execution nearly two-fold.
>
> Guido also referenced this write-up from Greg:
> https://mail.python.org/pipermail/python-dev/2001-August/017099.html
>
> I hope this helps.
>
> --
> Jonathan
>
>
>>

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

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/7XTH3P66VKZWYCARIDKSFPASKNYAXOLS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: "return if "

[Vegard Stikbakke]

On Sat, 20 Jun 2020 at 04:02, MRAB  wrote:

> On 2020-06-20 02:22, Robert DeLanghe wrote:
> > You can already do compact conditional returns with the current syntax:
> >
> > def foo(a, b):
> >  return (a != b or None) and a * b
> >
> >
> > or even:
> >
> > foo = (lambda a, b: (a != b or None) and a * b)
> >
> > both return:
> >
> >
> > foo(2, 5) # 10
> > foo(1, 1) # None
> >
> >
> > ... but clarity would be better.
> >
> That can be written more clearly:
>
>  def foo(a, b):
>  return a * b if a != b else None

I find the non-compact version to be clearer:

def foo(a, b):
if a != b:
return a*b
return None

>
>
> >
> >
> > On Fri, Jun 19, 2020 at 4:20 AM Serhiy Storchaka  > > wrote:
> >
> > 18.06.20 15:30, Daniel. пише:
> >  > I love the do_stuff if cond syntax in Ruby and in perl. It's very
> >  > natural to real, much more to follow than if cond: do_stuff
> >  >
> >  > But still I don't think that it is enough to demand a language
> > change.
> >  >
> >  > Something near this is to have a default of none for
> >  >
> >  > A if B else None
> >  >
> >  > So we can ommit the else None part, but this goes against the
> > explicit
> >  > is better than implicit
> >
> > Only around 10% of "if" expressions have "else None" part. It is not
> > enough to justify a new syntax (even if ignore other objections).
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/J7TH3N76S6C7CITCYCJWI76Y2F6DHPGF/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/TG46SCE4VOG5E5QGNOAII27SDWC4EXT3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Permanent code objects (less memory, quicker load, less Unix Copy On Write)

[Jonathan Fine]

Hi All

Guido wrote:

 I remember vaguely that about two decades ago Greg Stein hatched an idea
> for code objects loaded from a read-only segment in shared libraries.
>

[Thank you for this, Guido. Your memory is good.]

Here's a thread from 2009, where Guido said: Greg Stein reached this same
conclusion (and similar numbers) over 10 years ago ...

Subject: Remove GIL with CAS instructions?
https://mail.python.org/archives/list/python-ideas@python.org/thread/6ZONFLMGCFP66AOMAFHY7ZB2VH3MUCM4/#XV3GBWJEYP7UAVSZXWRXABR7BVQMEKS2

I looked up https://en.wikipedia.org/wiki/Compare-and-swap to read about
CAS.

Guido said this in the context of Antione's statement: Which makes me agree
with the commonly expressed opinion that CPython would probably need to
ditch refcounting (at least in the critical paths) if we want to remove the
GIL.

In 2007 Guido posted to Artima: It isn't Easy to Remove the GIL:
https://www.artima.com/weblogs/viewpost.jsp?thread=214235

In this post Guido writes:  In 1999 Greg Stein (with Mark Hammond?)
produced a fork of Python (1.5 I believe) that removed the GIL, replacing
it with fine-grained locks on all mutable data structures. [...] However,
after benchmarking, it was shown that even on the platform with the fastest
locking primitive (Windows at the time) it slowed down single-threaded
execution nearly two-fold.

Guido also referenced this write-up from Greg:
https://mail.python.org/pipermail/python-dev/2001-August/017099.html

I hope this helps.

-- 
Jonathan


>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/72TRD6M2VJALHT63MHFTE5CU4EHKL3IO/
Code of Conduct: http://python.org/psf/codeofconduct/