Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

On Sat, Feb 13, 2010 at 12:12 AM, Maciej Fijalkowski wrote: > I like this wording far more. It's at the very least far more precise. > Those examples are fair enough (except the fact that PyPy is not 32bit > x86 only, the JIT is). [snip] > "slower than US on some workloads" is true, while not real

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

On Fri, Feb 12, 2010 at 7:04 PM, Collin Winter wrote: > Hey Maciej, > > On Thu, Feb 11, 2010 at 6:39 AM, Maciej Fijalkowski wrote: >> Snippet from: >> >> http://codereview.appspot.com/186247/diff2/5014:8003/7002 >> >> *PyPy*: PyPy [#pypy]_ has good performance on numerical code, but is >> slower

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

Collin Winter wrote: > Hey Maciej, > > On Thu, Feb 11, 2010 at 6:39 AM, Maciej Fijalkowski wrote: >> Snippet from: >> >> http://codereview.appspot.com/186247/diff2/5014:8003/7002 >> >> *PyPy*: PyPy [#pypy]_ has good performance on numerical code, but is >> slower than Unladen Swallow on non-numer

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

Hey Maciej, On Thu, Feb 11, 2010 at 6:39 AM, Maciej Fijalkowski wrote: > Snippet from: > > http://codereview.appspot.com/186247/diff2/5014:8003/7002 > > *PyPy*: PyPy [#pypy]_ has good performance on numerical code, but is > slower than Unladen Swallow on non-numerical workloads. PyPy only > suppo

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

Snippet from: http://codereview.appspot.com/186247/diff2/5014:8003/7002 *PyPy*: PyPy [#pypy]_ has good performance on numerical code, but is slower than Unladen Swallow on non-numerical workloads. PyPy only supports 32-bit x86 code generation. It has poor support for CPython extension modules, ma

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

On Tue, Feb 9, 2010 at 14:47, Collin Winter wrote: > To follow up on some of the open issues: > > On Wed, Jan 20, 2010 at 2:27 PM, Collin Winter > wrote: > [snip] >> Open Issues >> === >> >> - *Code review policy for the ``py3k-jit`` branch.* How does the CPython >>  community want us to

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

To follow up on some of the open issues: On Wed, Jan 20, 2010 at 2:27 PM, Collin Winter wrote: [snip] > Open Issues > === > > - *Code review policy for the ``py3k-jit`` branch.* How does the CPython >  community want us to procede with respect to checkins on the ``py3k-jit`` >  branch? Pr

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

Hi Craig, On Tue, Feb 2, 2010 at 4:42 PM, Craig Citro wrote: >> Done. The diff is at >> http://codereview.appspot.com/186247/diff2/5014:8003/7002. I listed >> Cython, Shedskin and a bunch of other alternatives to pure CPython. >> Some of that information is based on conversations I've had with th

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

On Wed, Feb 3, 2010 at 6:51 AM, M.-A. Lemburg wrote: > You lost me there :-) > > I am not familiar with how U-S actually implements the compilation > step and was thinking of it working at the functions/methods level > and based on input/output parameter type information. Yes, but it's more like

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

Reid Kleckner wrote: > On Tue, Feb 2, 2010 at 8:57 PM, Collin Winter wrote: >>> Wouldn't it be possible to have the compiler approach work >>> in three phases in order to reduce the memory footprint and >>> startup time hit, ie. >>> >>> 1. run an instrumented Python interpreter to collect all >>>

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

On Tue, Feb 2, 2010 at 23:54, Collin Winter wrote: > Done. The diff is at > http://codereview.appspot.com/186247/diff2/5014:8003/7002. I listed > Cython, Shedskin and a bunch of other alternatives to pure CPython. > Some of that information is based on conversations I've had with the > respective

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

On Tue, Feb 2, 2010 at 8:57 PM, Collin Winter wrote: >> Wouldn't it be possible to have the compiler approach work >> in three phases in order to reduce the memory footprint and >> startup time hit, ie. >> >>  1. run an instrumented Python interpreter to collect all >>    the needed compiler infor

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

Hey MA, On Fri, Jan 29, 2010 at 11:14 AM, M.-A. Lemburg wrote: > Collin Winter wrote: >> I added startup benchmarks for Mercurial and Bazaar yesterday >> (http://code.google.com/p/unladen-swallow/source/detail?r=1019) so we >> can use them as more macro-ish benchmarks, rather than merely starting

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

> Done. The diff is at > http://codereview.appspot.com/186247/diff2/5014:8003/7002. I listed > Cython, Shedskin and a bunch of other alternatives to pure CPython. > Some of that information is based on conversations I've had with the > respective developers, and I'd appreciate corrections if I'm ou

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

Hey Dirkjan, [Circling back to this part of the thread] On Thu, Jan 21, 2010 at 1:37 PM, Dirkjan Ochtman wrote: > On Thu, Jan 21, 2010 at 21:14, Collin Winter wrote: [snip] >> My quick take on Cython and Shedskin is that they are >> useful-but-limited workarounds for CPython's historically-poor

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

M.-A. Lemburg wrote: > BTW: I also doubt that Mercurial will make any of this easier. > It makes creating branches easier for non-committers, but the > problem of having to maintain the branches remains. It greatly simplifies the process of syncing the branch with the main line of development so y

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

Collin Winter wrote: > On Mon, Feb 1, 2010 at 11:17 AM, M.-A. Lemburg wrote: >> Collin Winter wrote: >>> I think this idea underestimates a) how deeply the current CPython VM >>> is intertwined with the rest of the implementation, and b) the nature >>> of the changes required by these separate VMs

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

2010/2/1 Collin Winter > I believe these VMs would have little overlap. I cannot imagine that > Unladen Swallow's needs have much in common with Stackless's, or with > those of a hypothetical register machine to replace the current stack > machine. > > Let's consider that last example in more det

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

On 2/1/2010 1:32 PM, Collin Winter wrote: Hey MA, On Mon, Feb 1, 2010 at 9:58 AM, M.-A. Lemburg wrote: BTW: Some years ago we discussed the idea of pluggable VMs for Python. Wouldn't U-S be a good motivation to revisit this idea ? We could then have a VM based on byte code using a stack machi

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

On Mon, Feb 1, 2010 at 11:17 AM, M.-A. Lemburg wrote: > Collin Winter wrote: >> I think this idea underestimates a) how deeply the current CPython VM >> is intertwined with the rest of the implementation, and b) the nature >> of the changes required by these separate VMs. For example, Unladen >> S

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

Collin Winter wrote: > Hey MA, > > On Mon, Feb 1, 2010 at 9:58 AM, M.-A. Lemburg wrote: >> BTW: Some years ago we discussed the idea of pluggable VMs for >> Python. Wouldn't U-S be a good motivation to revisit this idea ? >> >> We could then have a VM based on byte code using a stack >> machines,

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

Hey MA, On Mon, Feb 1, 2010 at 9:58 AM, M.-A. Lemburg wrote: > BTW: Some years ago we discussed the idea of pluggable VMs for > Python. Wouldn't U-S be a good motivation to revisit this idea ? > > We could then have a VM based on byte code using a stack > machines, one based on word code using a

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

M.-A. Lemburg wrote: > Collin Winter wrote: >> I added startup benchmarks for Mercurial and Bazaar yesterday >> (http://code.google.com/p/unladen-swallow/source/detail?r=1019) so we >> can use them as more macro-ish benchmarks, rather than merely starting >> the CPython binary over and over again.

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

On Fri, Jan 29, 2010 at 15:04, wrote: > On 10:47 pm, tjre...@udel.edu wrote: >> >> On 1/29/2010 4:19 PM, Collin Winter wrote: >>> >>> On Fri, Jan 29, 2010 at 7:22 AM, Nick Coghlan wrote: >> >>> Agreed. We originally switched Unladen Swallow to wordcode in our >>> 2009Q1 release, and saw a perform

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

I'm back with some tests that I made with the U-S test suite. 2010/1/30 Scott Dial > > Cesare, just FYI, your Hg repository has lost the execute bits on some > files (namely "./configure" and "./Parser/asdl_c.py"), so it does not > quite build out-of-the-box. > Unfortunately, I haven't found a

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

On 29 January 2010 23:45, "Martin v. Löwis" wrote: >> On Windows, would a C extension author be able to distribute a single >> binary (bdist_wininst/bdist_msi) which would be compatible with >> with-LLVM and without-LLVM builds of Python? > > When PEP 384 gets implemented, you not only get that, b

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

2010/1/30 Scott Dial > > Cesare, just FYI, your Hg repository has lost the execute bits on some > files (namely "./configure" and "./Parser/asdl_c.py"), so it does not > quite build out-of-the-box. > That's probably because I worked on Windows. I have to address this issue. Thanks. > I took th

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

2010/1/30 > On 10:55 pm, collinwin...@google.com wrote: > >> >> That people are directly munging CPython >> bytecode means that CPython should provide a better, more abstract way >> to do the same thing that's more resistant to these kinds of changes. >> > > It might be helpful to hear more abou

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

Terry Reedy wrote: > On 1/29/2010 6:45 PM, "Martin v. Löwis" wrote: >> When PEP 384 gets implemented, you not only get that, but you will also >> be able to use the same extension module for 3.2, 3.3, 3.4, etc, with >> or without U-S. > > Even if CPython changes VC compiler version? In any case, g

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

On 1/29/2010 8:43 AM, Cesare Di Mauro wrote: > If you use Mercurial, you can grab a local copy this way: > > hg clone https://wpython10.wpython2.googlecode.com/hg/ wpython2-wpython10 > > Wpython is intended to run on any platform where CPython 2.6.4 runs. > Cesare, just FYI, your Hg repository

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

On 1/29/2010 6:45 PM, "Martin v. Löwis" wrote: On Windows, would a C extension author be able to distribute a single binary (bdist_wininst/bdist_msi) which would be compatible with with-LLVM and without-LLVM builds of Python? When PEP 384 gets implemented, you not only get that, but you will al

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

On 1/29/2010 5:55 PM, Collin Winter wrote: Hey Terry, On Fri, Jan 29, 2010 at 2:47 PM, Terry Reedy wrote: Several years, there was serious consideration of switching to a registerbased vm, which would have been even more of a change. Since I learned 1.4, Guido has consistently insisted that t

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

> On Windows, would a C extension author be able to distribute a single > binary (bdist_wininst/bdist_msi) which would be compatible with > with-LLVM and without-LLVM builds of Python? When PEP 384 gets implemented, you not only get that, but you will also be able to use the same extension module

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

On 10:55 pm, collinwin...@google.com wrote: That people are directly munging CPython bytecode means that CPython should provide a better, more abstract way to do the same thing that's more resistant to these kinds of changes. Yes, definitely! Requesting a supported way to do the kind of intr

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

On 10:47 pm, tjre...@udel.edu wrote: On 1/29/2010 4:19 PM, Collin Winter wrote: On Fri, Jan 29, 2010 at 7:22 AM, Nick Coghlan wrote: Agreed. We originally switched Unladen Swallow to wordcode in our 2009Q1 release, and saw a performance improvement from this across the board. We switched back

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

Hey Terry, On Fri, Jan 29, 2010 at 2:47 PM, Terry Reedy wrote: > On 1/29/2010 4:19 PM, Collin Winter wrote: >> >> On Fri, Jan 29, 2010 at 7:22 AM, Nick Coghlan  wrote: > >> Agreed. We originally switched Unladen Swallow to wordcode in our >> 2009Q1 release, and saw a performance improvement from

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

On 1/29/2010 4:19 PM, Collin Winter wrote: On Fri, Jan 29, 2010 at 7:22 AM, Nick Coghlan wrote: Agreed. We originally switched Unladen Swallow to wordcode in our 2009Q1 release, and saw a performance improvement from this across the board. We switched back to bytecode for the JIT compiler to

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

On Fri, Jan 29, 2010 at 7:22 AM, Nick Coghlan wrote: > Antoine Pitrou wrote: >> Or you could submit patches piecewise on http://bugs.python.org >> I think the first step would be to switch to 16-bit bytecodes. It would be >> uncontroversial (the increase in code size probably has no negative effec

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

Collin Winter wrote: > I added startup benchmarks for Mercurial and Bazaar yesterday > (http://code.google.com/p/unladen-swallow/source/detail?r=1019) so we > can use them as more macro-ish benchmarks, rather than merely starting > the CPython binary over and over again. If you have ideas for bette

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

2010/1/29 Antoine Pitrou > Actually, "wordcode" could allow accesses in the eval loop to be done on > aligned words, so as to fetch operands in one step on little-endian CPUs > (instead of recombining bytes manually). > > Regards > > Antoine. > I think that big-endians CPUs can get benefits too

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

I made a mistake talking about the example. Exchange binary operator and unary operator. Cesare 2010/1/29 Cesare Di Mauro > 2010/1/29 Nick Coghlan > > I wouldn't consider changing from bytecode to wordcode uncontroversial - >> the potential to have an effect on cache hit ratios means it needs

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

2010/1/29 Nick Coghlan > I wouldn't consider changing from bytecode to wordcode uncontroversial - > the potential to have an effect on cache hit ratios means it needs to be > benchmarked (the U-S performance tests should be helpful there). > It's quite strange, but from the tests made it seems t

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

Nick Coghlan gmail.com> writes: > > Antoine Pitrou wrote: > > Or you could submit patches piecewise on http://bugs.python.org > > I think the first step would be to switch to 16-bit bytecodes. It would be > > uncontroversial (the increase in code size probably has no negative effect) and > > wo

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

Antoine Pitrou wrote: > Or you could submit patches piecewise on http://bugs.python.org > I think the first step would be to switch to 16-bit bytecodes. It would be > uncontroversial (the increase in code size probably has no negative effect) > and > would provide the foundation for all of your op

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

2010/1/29 > > One strong suggestion for future releases: Please put a top-level directory > in your archives. It is annoying to expect that only to have an archive > expand into the current directory without creating a directory of its own. > I've been burned often enough that I always check be

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

2010/1/29 Antoine Pitrou > Cesare Di Mauro gmail.com> writes: > > > > If python dev community is interested, I can work on a 3.x branch, > porting > > all optimizations I made (and many others that I've planned to implement) > one > > step at the time, in order to carefully check and validate an

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

Cesare> You can find 7-Zip tools here Cesare> . Thanks. Found a tool named 7za in MacPorts which I was able to install. One strong suggestion for future releases: Please put a top-level directory in your archives. It is annoying to expect that only t

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

Cesare Di Mauro gmail.com> writes: > > If python dev community is interested, I can work on a 3.x branch, porting > all optimizations I made (and many others that I've planned to implement) one > step at the time, in order to carefully check and validate any change with > expert people monitorin

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

2010/1/29 > >Cesare> ... (you can find the wpython 1.0 final here >Cesare> ). > > I tried downloading it. Something about wpython10.7z and wpython10_fix.7z. > What's a 7z file? What tool on my Mac will unpack that? Can I build and > ru

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

On 29/01/2010 13:24, s...@pobox.com wrote: Cesare> ... (you can find the wpython 1.0 final here Cesare> ). I tried downloading it. Something about wpython10.7z and wpython10_fix.7z. What's a 7z file? What tool on my Mac will unpack

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

Cesare> ... (you can find the wpython 1.0 final here Cesare> ). I tried downloading it. Something about wpython10.7z and wpython10_fix.7z. What's a 7z file? What tool on my Mac will unpack that? Can I build and run wpython on my Mac or

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

2010/1/29 > >Cesare> I think that wpython as a proof-of-concept have done its work, >Cesare> showing its potentials. > > If you haven't alreayd is there any chance you can run the Unladen Swallow > performance test suite and post the results? The code is separate from U-S > and should w

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

Cesare> I think that wpython as a proof-of-concept have done its work, Cesare> showing its potentials. If you haven't alreayd is there any chance you can run the Unladen Swallow performance test suite and post the results? The code is separate from U-S and should work with wpython:

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

Hi Collin, Thanks for the useful links. I think that superinstructions require a bit more work, because they aren't just opcode arguments rearrangement. For example, in wpython 1.1 (that I'll release next month) I've introduced a CALL_SUB opcode to handle all kind of function types, so the 2 word

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

On Thu, Jan 28, 2010 at 1:14 PM, Paul Moore wrote: > So, just to extend the question a little (or reiterate, it may be that > this is already covered and I didn't fully understand): > > On Windows, would a C extension author be able to distribute a single > binary (bdist_wininst/bdist_msi) which w

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

On 28 January 2010 12:58, Daniel Fetchinson wrote: >>> If this is the case then I, as a C extension author, will have no >>> choice than working with a python installation that includes llvm/US. >>> Which, as far as I undestand it, means dealing with C++ issues. Is >>> this correct? Or the same pu

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

>> A question from someone writing C extension modules for python > > I doubt that this will have any impact on C extension developers. > > >> If this is correct, I still have one worry: since I wouldn't want to >> touch the python install most linux distributions ship or most >> windows/mac users

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

>> If this is the case then I, as a C extension author, will have no >> choice than working with a python installation that includes llvm/US. >> Which, as far as I undestand it, means dealing with C++ issues. Is >> this correct? Or the same pure C extension module compiled with C-only >> compilers

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

Daniel Fetchinson, 28.01.2010 13:19: > A question from someone writing C extension modules for python I doubt that this will have any impact on C extension developers. > If this is correct, I still have one worry: since I wouldn't want to > touch the python install most linux distributions ship

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

Daniel Fetchinson wrote: > If this is the case then I, as a C extension author, will have no > choice than working with a python installation that includes llvm/US. > Which, as far as I undestand it, means dealing with C++ issues. Is > this correct? Or the same pure C extension module compiled with

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

A question from someone writing C extension modules for python but not involved in python-dev: It has been said that compiling python with --without-llvm would not include unladen swallow and would bypass llvm together with all C++. Basically, as I understand it, --without-llvm gives the 'usual' c

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

Tim> I think the performance/memory tradeoffs being discussed are fine Tim> for the long-running / server apps (20mb on a 8Gb machine is Tim> negligable) At work our apps' memory footprints are dominated by the Boost-wrapped C++ libraries we use. 100MB VM usage at run-time is pr

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

On Wed, 2010-01-27 at 10:25 -0800, Collin Winter wrote: > On Wed, Jan 27, 2010 at 7:26 AM, William Dode wrote: > > I imagine that startup time and memory was also critical for V8. > > Startup time and memory usage are arguably *more* critical for a > Javascript implementation, since if you only s

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

On 27 January 2010 08:37, David Malcolm wrote: > On Thu, 2010-01-21 at 14:46 -0800, Jeffrey Yasskin wrote: > > On Thu, Jan 21, 2010 at 10:09 AM, Hanno Schlichting > wrote: > > > I'm a relative outsider to core development (I'm just a Plone release > > > manager), but'll allow myself a couple of

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

On Wed, 2010-01-27 at 11:34 -0800, Jeffrey Yasskin wrote: > On Wed, Jan 27, 2010 at 11:16 AM, Collin Winter > wrote: > > We absolutely do not want CPython to include a copy of LLVM in its > > source tree. Unladen Swallow has done this to make it easier to pick > > up changes to LLVM's codebase as

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

On Wed, Jan 27, 2010 at 11:16 AM, Collin Winter wrote: > We absolutely do not want CPython to include a copy of LLVM in its > source tree. Unladen Swallow has done this to make it easier to pick > up changes to LLVM's codebase as we make them, but this is not a > viable model for CPython's long-te

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

Hi William, On Wed, Jan 27, 2010 at 11:02 AM, William Dode wrote: > The startup time and memory comsumption are a limitation of llvm that > their developers plan to resolve or is it only specific to the current > python integration ? I mean the work to correct this is more on U-S or > on llvm ?

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

Hi David, On Wed, Jan 27, 2010 at 8:37 AM, David Malcolm wrote: [snip] > As a downstream distributor of Python, a major pain point for me is when > Python embeds a copy of a library's source code, rather than linking > against a system library (zlib, libffi and expat spring to mind): if > bugs (e

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

On 27-01-2010, Collin Winter wrote: > Hi William, > > On Wed, Jan 27, 2010 at 7:26 AM, William Dode wrote: >> Hi (as a simple user), >> >> I'd like to know why you didn't followed the same way as V8 Javascript, >> or the opposite, why for V8 they didn't choose llvm ? >> >> I imagine that startup t

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

David> As a downstream distributor of Python, a major pain point for me David> is when Python embeds a copy of a library's source code, rather David> than linking against a system library (zlib, libffi and expat David> spring to mind): if bugs (e.g. security issues) arise in a

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

Hi William, On Wed, Jan 27, 2010 at 7:26 AM, William Dode wrote: > Hi (as a simple user), > > I'd like to know why you didn't followed the same way as V8 Javascript, > or the opposite, why for V8 they didn't choose llvm ? > > I imagine that startup time and memory was also critical for V8. Start

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

On Thu, 2010-01-21 at 14:46 -0800, Jeffrey Yasskin wrote: > On Thu, Jan 21, 2010 at 10:09 AM, Hanno Schlichting wrote: > > I'm a relative outsider to core development (I'm just a Plone release > > manager), but'll allow myself a couple of questions. Feel free to > > ignore them, if you think they

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

Hi (as a simple user), I'd like to know why you didn't followed the same way as V8 Javascript, or the opposite, why for V8 they didn't choose llvm ? I imagine that startup time and memory was also critical for V8. thanks -- William Dodé - http://flibuste.net Informaticien Indépendant __

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

On 1/26/2010 6:17 PM, Collin Winter wrote: 70MB of the increase was indeed debug information. Since the Linux distros that I checked ship stripped Python binaries, I've stripped the Unladen Swallow binaries as well, and while the size increase is still significant, it's not as large as it once w

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

Hey Martin, On Thu, Jan 21, 2010 at 2:25 PM, "Martin v. Löwis" wrote: > Reid Kleckner wrote: >> On Thu, Jan 21, 2010 at 4:34 PM, "Martin v. Löwis" >> wrote: How large is the LLVM shared library? One surprising data point is that the binary is much larger than some of the memory footpr

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

Hi Cesare, On Tue, Jan 26, 2010 at 12:29 AM, Cesare Di Mauro wrote: > Hi Collin, > > One more question: is it easy to support more opcodes, or a different opcode > structure, in Unladen Swallow project? I assume you're asking about integrating WPython. Yes, adding new opcodes to Unladen Swallow

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

> This > may not be a problem in the LLVM code base, but it is the typical > problem that C++ devs run into with initialization of objects with > static storage duration. This *really* doesn't have to do anything with U-S, but I'd like to point out that standard C++ has a very clear semantics in t

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

Hi Skip For "relatively stable code" I talk about recent years. My experience with CPython is limited, of course. Cesare 2010/1/26 > >Cesare> ... but ceval.c has a relatively stable code ... > > I believe you are mistaken on several counts: > >* The names of the functions in there hav

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

Cesare> ... but ceval.c has a relatively stable code ... I believe you are mistaken on several counts: * The names of the functions in there have changed over time. * The suite of byte code operations have changed dramatically over the past ten years or so. * The relati

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

Hello Collin On Mon, Jan 25, 2010 at 05:27:38PM -0800, Collin Winter wrote: > On Mon, Jan 25, 2010 at 1:25 PM, Floris Bruynooghe > wrote: > > On Mon, Jan 25, 2010 at 10:14:35AM -0800, Collin Winter wrote: > >> I'm working on a patch to completely remove all traces of C++ with > >> configured with

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

Hi Collin, One more question: is it easy to support more opcodes, or a different opcode structure, in Unladen Swallow project? Thanks, Cesare ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscrib

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

Hi Collin, 2010/1/25 Collin Winter > Hi Cesare, > > On Sat, Jan 23, 2010 at 1:09 PM, Cesare Di Mauro > wrote: > > Hi Collin > > > > IMO it'll be better to make Unladen Swallow project a module, to be > > installed and used if needed, so demanding to users the choice of having > it > > or not. T

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

Nick Coghlan wrote: > Jeffrey Yasskin wrote: >> (b) could be a problem if we depend on LLVM as a shared library on one >> of these platforms (and, of course, if LLVM's JIT supports these >> systems at all). The obvious answers are: 1) --without-llvm on these >> systems, 2) link statically on these

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

On Mon, Jan 25, 2010 at 9:05 PM, Meador Inge wrote: > Also related to reduced code size with C++ I was wondering whether or not > anyone has explored using the ability of some toolchains to remove unused > code and data?  In GCC this can be enabled by compiling with > '-ffunction-sections' and '-f

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

Meador Inge wrote: > When 'obj1' and 'obj2' get linked into the final image there are no > guarantees on whose constructor (T::T or S::S) will be called first. > Sometimes folks write code where this initialization order matters. It > may cause strange behavior at run-time that is hard to pin dow

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

Jeffrey Yasskin wrote: > (b) could be a problem if we depend on LLVM as a shared library on one > of these platforms (and, of course, if LLVM's JIT supports these > systems at all). The obvious answers are: 1) --without-llvm on these > systems, 2) link statically on these systems, 3) eliminate the

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

> We really do need precise descriptions of the problems so we can avoid them. Initialization of objects with static storage duration typically get a bad wrap for two main reasons: (1) each toolchain implements them differently (but typically by storing initialization thunks in a table that is wal

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

Hey Floris, On Mon, Jan 25, 2010 at 1:25 PM, Floris Bruynooghe wrote: > On Mon, Jan 25, 2010 at 10:14:35AM -0800, Collin Winter wrote: >> I'm working on a patch to completely remove all traces of C++ with >> configured with --without-llvm. It's a straightforward change, and >> should present no d

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

>> a) main() is not compiled with g++: static objects get not constructed >> b) code that gets linked into shared libraries (assuming the system >> supports them) does not get its initializers invoked. >> c) compilation of main() with a C++ compiler, but then linking with ld >> results in an un

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

On Mon, Jan 25, 2010 at 1:50 PM, "Martin v. Löwis" wrote: >> We really do need precise descriptions of the problems so we can avoid them. > > One family of problems is platform lack of initializer support in the > object file format; any system with traditional a.out (or b.out) is > vulnerable (al

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeffrey Yasskin wrote: > On Mon, Jan 25, 2010 at 10:44 AM, Tres Seaver wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Collin Winter wrote: >> >>> For reference, what are these "obscure platforms" where static >>> initializers cause p

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

Floris Bruynooghe wrote: > Since I was under the > impression that the JIT/LLVM can't emit machine code for the platforms > where these C++ problems would likely occur nothing would be lost. AFAICT, LLVM doesn't support Itanium or HPPA, and apparently not POWER, either (although they do support PP

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

> We really do need precise descriptions of the problems so we can avoid them. One family of problems is platform lack of initializer support in the object file format; any system with traditional a.out (or b.out) is vulnerable (also, COFF is, IIRC). The solution e.g. g++ came up with is to have

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

On Mon, Jan 25, 2010 at 11:48:56AM -0800, Jeffrey Yasskin wrote: > On Mon, Jan 25, 2010 at 10:44 AM, Tres Seaver wrote: > > Collin Winter wrote: > > > >> For reference, what are these "obscure platforms" where static > >> initializers cause problems? > > > > It's been a long while since I had to d

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

On Mon, Jan 25, 2010 at 10:14:35AM -0800, Collin Winter wrote: > I'm working on a patch to completely remove all traces of C++ with > configured with --without-llvm. It's a straightforward change, and > should present no difficulties. Great to hear that, thanks for caring. > For reference, what a

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

On Mon, Jan 25, 2010 at 10:44 AM, Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Collin Winter wrote: > >> For reference, what are these "obscure platforms" where static >> initializers cause problems? > > It's been a long while since I had to deal with it, but the "usual

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

Hi Cesare, On Sat, Jan 23, 2010 at 1:09 PM, Cesare Di Mauro wrote: > Hi Collin > > IMO it'll be better to make Unladen Swallow project a module, to be > installed and used if needed, so demanding to users the choice of having it > or not. The same way psyco does, indeed. > Nowadays it requires to

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Collin Winter wrote: > For reference, what are these "obscure platforms" where static > initializers cause problems? It's been a long while since I had to deal with it, but the "usual suspets" back in the day were HP-UX, AIX, and Solaris with non-GCC

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

Hi Floris, On Sun, Jan 24, 2010 at 3:40 AM, Floris Bruynooghe wrote: > On Sat, Jan 23, 2010 at 10:09:14PM +0100, Cesare Di Mauro wrote: >> Introducing C++ is a big step, also. Aside the problems it can bring on some >> platforms, it means that C++ can now be used by CPython developers. It >> does

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

2010/1/24 Floris Bruynooghe > Introducing C++ is a big step, but I disagree that it means C++ should > be allowed in the other CPython code. C++ can be problematic on more > obscure platforms (certainly when static initialisers are used) and > being able to build a python without C++ (no JIT/LLV

  1   2   >