[Python-Dev] support of the android platform
Starting with API level 21 (Android 5.0), the build of python3 with the official android toolchains (that is, without resorting to external libraries for wide character support) runs correctly. With the set of patches described in the patches/Makefile file at [1], the cpython test suite runs[2] on the android x86 and armv7 emulators with only few errors[3]. Those errors are listed with their corresponding error messages, this may give a raw idea of the effort needed to support this platform. Xavier [1] https://bitbucket.org/xdegaye/pyona/src [2] To reproduce these results, follow the instructions found in INSTALL at https://bitbucket.org/xdegaye/pyona/wiki/install [3] https://bitbucket.org/xdegaye/pyona/wiki/testsuite ___ 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] support of the android platform
Xavier de Gaye gmail.com> writes: > Starting with API level 21 (Android 5.0), the build of python3 with the > official android toolchains (that is, without resorting to external libraries > for wide character support) runs correctly. With the set of patches described > in the patches/Makefile file at [1], the cpython test suite runs[2] on the > android x86 and armv7 emulators with only few errors[3]. Those errors are > listed with their corresponding error messages, this may give a raw idea of > the effort needed to support this platform. > > Xavier > > [1] https://bitbucket.org/xdegaye/pyona/src > [2] To reproduce these results, follow the instructions found in INSTALL > at https://bitbucket.org/xdegaye/pyona/wiki/install > [3] https://bitbucket.org/xdegaye/pyona/wiki/testsuite This looks great, very clean! As I understand the patches, the locale.h and langinfo.h problems are solved. Do you think the following issues on the Python bug tracker could be closed? http://bugs.python.org/issue20305 http://bugs.python.org/issue22747 http://bugs.python.org/issue17905 Stefan Krah ___ 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] Wordcode: new regular bytecode using 16-bit units
> On Apr 23, 2016, at 8:59 AM, Serhiy Storchaka wrote: > > I collected statistics for use opcodes with different arguments during > running CPython tests. Estimated size with using wordcode is 1.33 times less > than with using current bytecode. > > [1] http://comments.gmane.org/gmane.comp.python.ideas/38293 I think the word code patch should go in sooner rather than later. Several of us have been through the patch and it is in pretty good shape (some parts still need work though). The earlier this goes in, the more time we'll have to shake out any unexpected secondary effects. perfect-is-the-enemy-of-good-ly yours, Raymond P.S. The patch is smaller, more tractable, and in better shape than the C version of OrderedDict was when it went in. ___ 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] Wordcode: new regular bytecode using 16-bit units
Hi Raymond, 2016-04-24 21:45 GMT+02:00 Raymond Hettinger : > I think the word code patch should go in sooner rather than later. Several > of us have been through the patch and it is in pretty good shape (some parts > still need work though). The earlier this goes in, the more time we'll have > to shake out any unexpected secondary effects. Yury Selivanov and Serhiy Storchaka told me that they will review shortly the patch. I give them one more week and then I will push the patch. I agree that the patch is in a good shape. I reviewed first versions of the change. I pushed some minor and obvious changes. I also asked to revert unrelated changes. I proposed to not try to optimize ceval.c to fetch (oparg, opval) in a single 16-bit operation. It should be easy to implement it later, but I prefer to focus on changing the format of the bytecode. Victor ___ 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] Wordcode: new regular bytecode using 16-bit units
> On Apr 24, 2016, at 1:16 PM, Victor Stinner wrote: > > I proposed to not try to optimize ceval.c to fetch (oparg, opval) in a > single 16-bit operation. It should be easy to implement it later, but > I prefer to focus on changing the format of the bytecode. Improving instruction decoding was the whole point and it was what kicked-off the work on the patch. It is also where most of the performance improvement comes from and isn't the difficult part of the patch. The persnickety parts of the patch lay elsewhere, so there is really nothing to be gained gutting out our actual objective. The OPs original patch had already gotten this part done and it ran fine for me. Raymond ___ 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] Wordcode: new regular bytecode using 16-bit units
2016-04-24 23:16 GMT+02:00 Raymond Hettinger : >> On Apr 24, 2016, at 1:16 PM, Victor Stinner wrote: >> I proposed to not try to optimize ceval.c to fetch (oparg, opval) in a >> single 16-bit operation. It should be easy to implement it later, but >> I prefer to focus on changing the format of the bytecode. > > Improving instruction decoding was the whole point and it was what kicked-off > the work on the patch. It is also where most of the performance improvement > comes from and isn't the difficult part of the patch. The persnickety parts > of the patch lay elsewhere, so there is really nothing to be gained gutting > out our actual objective. > > The OPs original patch had already gotten this part done and it ran fine for > me. Oh wait, my phrasing is unclear. I do want optimize the (opcode, oparg) fetch, I just suggested to split the patch in two parts, and first review carefully the first part. Victor ___ 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] Wordcode: new regular bytecode using 16-bit units
> On Apr 24, 2016, at 2:31 PM, Victor Stinner wrote: > > 2016-04-24 23:16 GMT+02:00 Raymond Hettinger : >>> On Apr 24, 2016, at 1:16 PM, Victor Stinner >>> wrote: >>> I proposed to not try to optimize ceval.c to fetch (oparg, opval) in a >>> single 16-bit operation. It should be easy to implement it later, but >>> I prefer to focus on changing the format of the bytecode. >> >> Improving instruction decoding was the whole point and it was what >> kicked-off the work on the patch. It is also where most of the performance >> improvement comes from and isn't the difficult part of the patch. The >> persnickety parts of the patch lay elsewhere, so there is really nothing to >> be gained gutting out our actual objective. >> >> The OPs original patch had already gotten this part done and it ran fine for >> me. > > Oh wait, my phrasing is unclear. I do want optimize the (opcode, > oparg) fetch, I just suggested to split the patch in two parts, and > first review carefully the first part. Unless it is presenting a tough review challenge, we should do whatever we can to make it easier on the OP who seems to be working with very limited computational resources (I had to run the benchmarks for him because his setup lacked the requisite resources). He's already put a lot of work into the patch which is pretty good shape when it arrived. The opcode/oparg fetch logic is mostly already isolated to the part of the patch that touches ceval.c. I found that part to be relatively clean and clear. The part that took the most time to go through was for peephole.c. How about we let Yury and Serhiy take a pass at it as is. And, if they would benefit from splitting the patch into parts, then perhaps one of us with better tooling can pitch in to the help the OP. Raymond ___ 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
