Re: [Python-Dev] Store startup modules as C structures for 20%+ startup speed improvement?

[Neil Schemenauer]

On 2018-09-18, Carl Shapiro wrote:
> How might people feel about using the linker to bundle a list of pre-loaded
> modules into a single-file executable?

The users of Python are pretty diverse so it depends on who you ask.
Some would like a giant executable that includes everything they
need (so of like the Go approach).  Other people want an executable
that has just importlib inside it and then mix-and-match different
shared libs for their different purposes.  Some will not want work
"old school" and load from separate .py or .pyc files.

I see no reason why we can't support all these options.

Regards,

  Neil
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Store startup modules as C structures for 20%+ startup speed improvement?

[Carl Shapiro]

On Tue, Sep 18, 2018 at 11:38 AM, Steve Dower 
wrote:

> The primary benefit of the importlib hook approach is that it would not
> require rebuilding CPython each time you make a change. Since we need to
> consider a wide range of users across a wide range of platforms, having the
> ability to load a single native module that contains many "pre-loaded"
> modules allows many more people to access the benefits.
>

> It would not prevent some specific modules from being compiled into the
> main binary, but for those who do not build their own Python it would also
> allow specific applications to use the feature as well.
>

How might people feel about using the linker to bundle a list of pre-loaded
modules into a single-file executable?  That would avoid the inconvenience
of rebuilding all of CPython by shipping a static libpython and having the
tool generate a .o or .S file with the un-marshaled data.  (Linkers and
assemblers are small enough to be bundled on systems that do not have them.)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] SEC: Spectre variant 2: GCC: -mindirect-branch=thunk -mindirect-branch-register

[Franklin? Lee]

On Tue, Sep 18, 2018 at 2:40 AM INADA Naoki  wrote:
>
> On Tue, Sep 18, 2018 at 7:08 AM Wes Turner  wrote:
> >
> > To summarize:
> >
> > - CPython may be vulnerable to speculative execution vulnerabilities, but 
> > none are known.
> > - In general, CPython is currently too slow for speculative execution 
> > exploitation to be practical.
> >   - Sandboxed, JIT'ed JS is not too slow for speculative execution 
> > exploitation to be practical
> > - (Not otherwise discussed here: PyPy's sandboxed JIT may not be too 
> > slow for speculative execution exploitation to be practical.)
> >
>
> As far as I know, execution speed is important for attacker, not victim.
> In case of JavaScript, browser may load attacking code and run it while
> user watching websites.
> Browsers provides sandbox for JS, but attacker code may be able to
> bypass the sandbox by Spectre or Meltdown.  So browsers disabled
> high precision timer until OSes are updated.
>
> This topic is totally unrelated to compiler options: these compiler options
> doesn't prohibit running attacking code, it just guard branches from
> branch target injection.
>
> Does my understanding collect?  Why should we discuss about execution speed?

According to this article, the malicious program needs to act in the
amount of time it takes for the CPU to load a value from memory and
invalidate a branch prediction:
https://hackernoon.com/timing-is-everything-understanding-the-meltdown-and-spectre-attacks-5e1946e44f9f
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Store startup modules as C structures for 20%+ startup speed improvement?

[Fabio Zadrozny]

On Tue, Sep 18, 2018 at 2:57 PM, Carl Shapiro 
wrote:

> On Tue, Sep 18, 2018 at 5:55 AM, Fabio Zadrozny  wrote:
>
>> During the import process, Python can already deal with folders and .zip
>> files in sys.path... now, instead of having special handling for a new
>> concept with a custom command line, etc, why not just say that this is a
>> special file (e.g.: files with a .pyfrozen extension) and make importlib be
>> able to deal with it when it's on sys.path (that way there could be
>> multiple of those and there should be no need to turn it on/off, custom
>> command line, etc)?
>>
>
> That is an interesting idea but it might not be easy to work into this
> design.  The improvement in start-up time comes from eliminating the
> overheads of filesystem I/O, memory allocation, and un-marshaling
> bytecode.  Having this data on the filesystem would reintroduce the cost of
> filesystem I/O and it would add a load-time relocation to the equation so
> the overall performance benefits would be greatly lessened.
>
>
>> Another question: doesn't importlib already provide hooks for external
>> contributors which could address that use case? (so, this could initially
>> be available as a third party library for maturing outside of CPython and
>> then when it's deemed to be mature it could be integrated into CPython --
>> not that this can't happen on Python 3.8 timeframe, but it'd be useful
>> checking its use against the current Python version and measuring benefits
>> with real world code).
>>
>
> This may be possible but, for the same reasons I outline above, it would
> certainly come at the expense of performance.
>
> I think many people are interested in a better .pyc format but our goals
> are much more modest.  We are actually trying to not introduce a whole new
> way to externalize .py data in CPython.  Rather, we think of this as just
> making the existing frozen module capability much faster so its use can be
> broadened to making start-up performance better.  The user visible part,
> the command line interface to bypass the frozen module, would be a
> nice-to-have for developers but is something we could live without.
>

Just to make sure we're in the same page, the approach I'm talking about
would still be having a dll, not a better .pyc format, so, during the
import a custom importer would open that dll once and provide modules from
it -- do you think this would be much more overhead than what's proposed
now?

I guess it may be a bit slower because it'd have to obey the existing
import capabilities, but that shouldn't mean more time is spent on IO,
memory allocation nor un-marshaling bytecode (although it may be that I
misunderstood the approach or the current import capabilities don't provide
the proper api for that).
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Store startup modules as C structures for 20%+ startup speed improvement?

[Steve Dower]

On 18Sep2018 1057, Carl Shapiro wrote:
On Tue, Sep 18, 2018 at 5:55 AM, Fabio Zadrozny > wrote:


During the import process, Python can already deal with folders and
.zip files in sys.path... now, instead of having special handling
for a new concept with a custom command line, etc, why not just say
that this is a special file (e.g.: files with a .pyfrozen extension)
and make importlib be able to deal with it when it's on sys.path
(that way there could be multiple of those and there should be no
need to turn it on/off, custom command line, etc)?


That is an interesting idea but it might not be easy to work into this 
design.  The improvement in start-up time comes from eliminating the 
overheads of filesystem I/O, memory allocation, and un-marshaling 
bytecode.  Having this data on the filesystem would reintroduce the cost 
of filesystem I/O and it would add a load-time relocation to the 
equation so the overall performance benefits would be greatly lessened.


Another question: doesn't importlib already provide hooks for
external contributors which could address that use case? (so, this
could initially be available as a third party library for maturing
outside of CPython and then when it's deemed to be mature it could
be integrated into CPython -- not that this can't happen on Python
3.8 timeframe, but it'd be useful checking its use against the
current Python version and measuring benefits with real world code).


This may be possible but, for the same reasons I outline above, it would 
certainly come at the expense of performance.


I think many people are interested in a better .pyc format but our goals 
are much more modest.  We are actually trying to not introduce a whole 
new way to externalize .py data in CPython.  Rather, we think of this as 
just making the existing frozen module capability much faster so its use 
can be broadened to making start-up performance better.  The user 
visible part, the command line interface to bypass the frozen module, 
would be a nice-to-have for developers but is something we could live 
without.


The primary benefit of the importlib hook approach is that it would not 
require rebuilding CPython each time you make a change. Since we need to 
consider a wide range of users across a wide range of platforms, having 
the ability to load a single native module that contains many 
"pre-loaded" modules allows many more people to access the benefits.


It would not prevent some specific modules from being compiled into the 
main binary, but for those who do not build their own Python it would 
also allow specific applications to use the feature as well.


FWIW, I don't read this as being pushed back on Carl to implement before 
the idea is accepted. I think we're taking the (now proven) core idea 
and shaping it into a suitable form for the main CPython distribution, 
which has to take more use cases into account.


Cheers,
Steve
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Store startup modules as C structures for 20%+ startup speed improvement?

[Carl Shapiro]

On Tue, Sep 18, 2018 at 5:55 AM, Fabio Zadrozny  wrote:

> During the import process, Python can already deal with folders and .zip
> files in sys.path... now, instead of having special handling for a new
> concept with a custom command line, etc, why not just say that this is a
> special file (e.g.: files with a .pyfrozen extension) and make importlib be
> able to deal with it when it's on sys.path (that way there could be
> multiple of those and there should be no need to turn it on/off, custom
> command line, etc)?
>

That is an interesting idea but it might not be easy to work into this
design.  The improvement in start-up time comes from eliminating the
overheads of filesystem I/O, memory allocation, and un-marshaling
bytecode.  Having this data on the filesystem would reintroduce the cost of
filesystem I/O and it would add a load-time relocation to the equation so
the overall performance benefits would be greatly lessened.


> Another question: doesn't importlib already provide hooks for external
> contributors which could address that use case? (so, this could initially
> be available as a third party library for maturing outside of CPython and
> then when it's deemed to be mature it could be integrated into CPython --
> not that this can't happen on Python 3.8 timeframe, but it'd be useful
> checking its use against the current Python version and measuring benefits
> with real world code).
>

This may be possible but, for the same reasons I outline above, it would
certainly come at the expense of performance.

I think many people are interested in a better .pyc format but our goals
are much more modest.  We are actually trying to not introduce a whole new
way to externalize .py data in CPython.  Rather, we think of this as just
making the existing frozen module capability much faster so its use can be
broadened to making start-up performance better.  The user visible part,
the command line interface to bypass the frozen module, would be a
nice-to-have for developers but is something we could live without.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Store startup modules as C structures for 20%+ startup speed improvement?

[Carl Shapiro]

On Tue, Sep 18, 2018 at 1:31 AM, Antoine Pitrou  wrote:

> No idea.  In my previous experiments with module import speed, I
> concluded that executing module bytecode generally was the dominating
> contributor, but that doesn't mean loading bytecode is costless.
>

My observations might not be so different.  On a large application, we
measured ~25-30% of start-up time being spent in the loading of compiled
bytecode.  That includes: probing the filesystem, reading the bytecode off
disk, allocating heap storage, and un-marshaling objects into the heap.

Making that percentage go to ~0% using this change does not make the
non-import parts of our module body functions execute faster.  It does
create a greater opportunity for the application developer to do less work
in module body functions which is where the largest start-up time gains are
now likely to happen.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Nearly - all tests PASS for AIX

[Michael]

On 17/09/2018 12:50, Michael wrote:
> Dear all,
>
> The last two months I have spent nearly all my free time to cleanup "a
> frustration" - from my side - the long list of failing tests for AIX
> (there were nearly 20 when I started).

== Tests result: SUCCESS ==

393 tests OK.

1 test altered the execution environment:
    test_threading

25 tests skipped:
    test_dbm_gnu test_devpoll test_epoll test_gdb test_idle
    test_kqueue test_lzma test_msilib test_ossaudiodev test_readline
    test_spwd test_sqlite test_startfile test_tcl test_tix test_tk
    test_ttk_guionly test_ttk_textonly test_turtle test_unicode_file
    test_unicode_file_functions test_winconsoleio test_winreg
    test_winsound test_zipfile64

Total duration: 13 min 30 sec
Tests result: SUCCESS

May I put this up as a PR - not for merging - but to see how it
performs, or does not perform, with the Travis Ci, etc. tests?

Regards,

Michael

p.s. - most of the time test_threading just passes. Going to Rinse and
repeat!




signature.asc
Description: OpenPGP digital signature
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Store startup modules as C structures for 20%+ startup speed improvement?

[Fabio Zadrozny]

On Mon, Sep 17, 2018 at 9:23 PM, Carl Shapiro 
wrote:

> On Sun, Sep 16, 2018 at 1:24 PM, Antoine Pitrou 
> wrote:
>
>> I think it's of limited interest if it only helps with modules used
>> during the startup sequence, not arbitrary stdlib or third-party
>> modules.
>>
>
> This should help any use-case that is already using the freeze module
> already bundled with CPython.  Third-party code, like py2exe, py2app,
> pyinstaller, and XAR could build upon this to create applications that
> start faster.
>

I think this seems like a great idea.

Some questions though:

During the import process, Python can already deal with folders and .zip
files in sys.path... now, instead of having special handling for a new
concept with a custom command line, etc, why not just say that this is a
special file (e.g.: files with a .pyfrozen extension) and make importlib be
able to deal with it when it's on sys.path (that way there could be
multiple of those and there should be no need to turn it on/off, custom
command line, etc)?

Another question: doesn't importlib already provide hooks for external
contributors which could address that use case? (so, this could initially
be available as a third party library for maturing outside of CPython and
then when it's deemed to be mature it could be integrated into CPython --
not that this can't happen on Python 3.8 timeframe, but it'd be useful
checking its use against the current Python version and measuring benefits
with real world code).

To give an idea, on my machine the baseline Python startup is about 20ms
>> (`time python -c pass`), but if I import Numpy it grows to 100ms, and
>> with Pandas it's more than 200ms.  Saving 4ms on the baseline startup
>> would make no practical difference for concrete usage.
>>
>
> Do you have a feeling for how many of those milliseconds are spend loading
> bytecode from disk?  If so standalone executables that contain numpy and
> pandas (and mercurial) would start faster
>
>
>> I'm ready to think there are other use cases where it matters, though.
>>
>
> I think so.  I hope you will, too :-)
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> fabiofz%40gmail.com
>
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Request review of bpo-34125/GH-8416

[Jeroen Demeyer]

The gist of bpo-34125 is that the following two statements behave 
differently with respect to sys.setprofile() profiling:


>>> list.append([], None)

>>> list.append([], None, **{})

More precisely: the former call is profiled, but the latter is not. The 
fix at GH-8416 is simply to make this consistent by also profiling the 
latter.


Victor Stinner did not want to accept the pull request because he wanted 
"a wider discussion on function calls". I think that GH-8416 is a simple 
bugfix which can be merged anyway and which won't make future 
"discussions on function calls" any harder.


In any case, it would be good to have any *decision* (accepted or 
rejected) on that PR. I find the current uncertainty worse than a 
decision either way. Right now, my reference implementation of PEP 580 
conflicts with that branch and I would like to resolve that conflict 
after GH-8416 has been decided.


Links:
https://bugs.python.org/issue34125
https://github.com/python/cpython/pull/8416


Thanks,
Jeroen Demeyer.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] debugging test_importlib.test_bad_traverse - script status is SUCCESS - but FAIL is expected.

[Michael]

On 17/09/2018 09:39, Michael wrote:
> I read the discussion related to issue32374. That seems to be sure that
> other events that could
> cause the test to fail (i.e., the program executes successfully) are
> caught early, and/or ignored
> so that the program fails - and the test succeeds.

After reading below, I would appreciate knowing whether to ask that
issue32374 be reopened and the test adjusted so that the test is
"SkipIf" AIX? Or, something else? I'll work on something else, but I do
not want to guess the current intent of this test module.

+++

In: Modules/_testmultiphase.c - found where AIX and Linux differ
in their response to accessing a NULL pointer, in this case
m_state->integer

  +624  static int
  +625  bad_traverse(PyObject *self, visitproc visit, void *arg) {
  +626  testmultiphase_state *m_state;
  +627 FILE *err = fopen("/tmp/err","a");
  +628
  +629  m_state = PyModule_GetState(self);
  +630
  +631  fprintf(err,"%s:%d\n", __FILE__,__LINE__); fflush(err);
  +632  fprintf(err, "m_state:08%lx _state->integer:%08lx\n",
  +633  m_state, &(m_state->integer));
  +634  fclose(err);
  +635  Py_VISIT(m_state->integer);
  +636  /*
  +637  #define Py_VISIT(op)
  +638  do {
  +639  if (m_state->integer) {
  +640  int vret = visit((PyObject *)(m_state->integer), arg);
  +641  if (vret) {
  +642  return vret;
  +643  }
  +644  }
  +645  } while (0);
  +646  */
  +647  return 0;
  +648  }

The "m_state" and m_state->integer values are identical, but the
response is not.

root@x066:[/data/prj/python/git]uname
AIX
/data/prj/python/git/python3-3.8/Modules/_testmultiphase.c:631
m_state:080 _state->integer:

root@x074:/data/prj/python/git# uname
Linux
/data/prj/python/git/Python3-3.8.0/Modules/_testmultiphase.c:631
m_state:080 _state->integer:

++ Test program to demonstrate +++
AIX does not segmentfault on access of a NULL pointer
++
root@x074:/data/prj/python/git# cat nullpr.c
#include
main()
{
    int *vpt = NULL;

fprintf(stdout, "vpt = %08lx\n", vpt);
if (*vpt)
    fprintf(stdout,"True\n");
else
    fprintf(stdout,"False\n");
}

root@x074:/data/prj/python/git# rm -f nullpr; make nullpr; ./nullpr
make: Warning: File 'nullpr.c' has modification time 387 s in the future
cc nullpr.c   -o nullpr
nullpr.c:2:1: warning: return type defaults to 'int' [-Wimplicit-int]
 main()
 ^
make: warning:  Clock skew detected.  Your build may be incomplete.
vpt = 
Segmentation fault


++ AIX does not 'Segmenttation fault' +
root@x066:[/data/prj/python/git]rm -r nullpr; make nullpr; ./nullpr
cc nullpr.c   -o nullpr
vpt = 
False




signature.asc
Description: OpenPGP digital signature
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Store startup modules as C structures for 20%+ startup speed improvement?

[Antoine Pitrou]

On Mon, 17 Sep 2018 17:23:26 -0700
Carl Shapiro  wrote:
> 
> > To give an idea, on my machine the baseline Python startup is about 20ms
> > (`time python -c pass`), but if I import Numpy it grows to 100ms, and
> > with Pandas it's more than 200ms.  Saving 4ms on the baseline startup
> > would make no practical difference for concrete usage.
> >  
> 
> Do you have a feeling for how many of those milliseconds are spend loading
> bytecode from disk?

No idea.  In my previous experiments with module import speed, I
concluded that executing module bytecode generally was the dominating
contributor, but that doesn't mean loading bytecode is costless.

Regards

Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] SEC: Spectre variant 2: GCC: -mindirect-branch=thunk -mindirect-branch-register

[INADA Naoki]

On Tue, Sep 18, 2018 at 7:08 AM Wes Turner  wrote:
>
> To summarize:
>
> - CPython may be vulnerable to speculative execution vulnerabilities, but 
> none are known.
> - In general, CPython is currently too slow for speculative execution 
> exploitation to be practical.
>   - Sandboxed, JIT'ed JS is not too slow for speculative execution 
> exploitation to be practical
> - (Not otherwise discussed here: PyPy's sandboxed JIT may not be too slow 
> for speculative execution exploitation to be practical.)
>

As far as I know, execution speed is important for attacker, not victim.
In case of JavaScript, browser may load attacking code and run it while
user watching websites.
Browsers provides sandbox for JS, but attacker code may be able to
bypass the sandbox by Spectre or Meltdown.  So browsers disabled
high precision timer until OSes are updated.

This topic is totally unrelated to compiler options: these compiler options
doesn't prohibit running attacking code, it just guard branches from
branch target injection.

Does my understanding collect?  Why should we discuss about execution speed?

I think this topic should split to two topics: (1) Guard Python
process from Spectre/Meltdown
attack from other process, (2) Prohibit Python code attack other
processes by using
Spectre/Meltdown.


Regards,
-- 
INADA Naoki  
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com