On Sat, Feb 13, 2010 at 12:12 AM, Maciej Fijalkowski fij...@gmail.com 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,
Hey Maciej,
On Thu, Feb 11, 2010 at 6:39 AM, Maciej Fijalkowski fij...@gmail.com 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
Collin Winter wrote:
Hey Maciej,
On Thu, Feb 11, 2010 at 6:39 AM, Maciej Fijalkowski fij...@gmail.com 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
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,
On Tue, Feb 9, 2010 at 14:47, Collin Winter collinwin...@google.com wrote:
To follow up on some of the open issues:
On Wed, Jan 20, 2010 at 2:27 PM, Collin Winter collinwin...@google.com
wrote:
[snip]
Open Issues
===
- *Code review policy for the ``py3k-jit`` branch.* How does
To follow up on some of the open issues:
On Wed, Jan 20, 2010 at 2:27 PM, Collin Winter collinwin...@google.com 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
Hi Craig,
On Tue, Feb 2, 2010 at 4:42 PM, Craig Citro craigci...@gmail.com 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
Reid Kleckner wrote:
On Tue, Feb 2, 2010 at 8:57 PM, Collin Winter collinwin...@google.com 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
On Wed, Feb 3, 2010 at 6:51 AM, M.-A. Lemburg m...@egenix.com 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
Collin Winter wrote:
On Mon, Feb 1, 2010 at 11:17 AM, M.-A. Lemburg m...@egenix.com 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
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
Hey Dirkjan,
[Circling back to this part of the thread]
On Thu, Jan 21, 2010 at 1:37 PM, Dirkjan Ochtman dirk...@ochtman.nl wrote:
On Thu, Jan 21, 2010 at 21:14, Collin Winter collinwin...@google.com wrote:
[snip]
My quick take on Cython and Shedskin is that they are
useful-but-limited
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 out of
Hey MA,
On Fri, Jan 29, 2010 at 11:14 AM, M.-A. Lemburg m...@egenix.com 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
On Tue, Feb 2, 2010 at 8:57 PM, Collin Winter collinwin...@google.com 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
On Tue, Feb 2, 2010 at 23:54, Collin Winter collinwin...@google.com 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
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. If you
Hey MA,
On Mon, Feb 1, 2010 at 9:58 AM, M.-A. Lemburg m...@egenix.com 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
Collin Winter wrote:
Hey MA,
On Mon, Feb 1, 2010 at 9:58 AM, M.-A. Lemburg m...@egenix.com 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
On Mon, Feb 1, 2010 at 11:17 AM, M.-A. Lemburg m...@egenix.com 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,
On 2/1/2010 1:32 PM, Collin Winter wrote:
Hey MA,
On Mon, Feb 1, 2010 at 9:58 AM, M.-A. Lemburgm...@egenix.com 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
2010/2/1 Collin Winter collinwin...@google.com
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
On 29 January 2010 23:45, Martin v. Löwis mar...@v.loewis.de 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
I'm back with some tests that I made with the U-S test suite.
2010/1/30 Scott Dial
scott+python-...@scottdial.comscott%2bpython-...@scottdial.com
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
On Fri, Jan 29, 2010 at 15:04, exar...@twistedmatrix.com 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 Coghlanncogh...@gmail.com wrote:
Agreed. We originally switched Unladen Swallow to wordcode in our
2009Q1
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:
2010/1/29 s...@pobox.com
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
Cesare ... (you can find the wpython 1.0 final here
Cesare http://code.google.com/p/wpython2/downloads/list).
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 is
On 29/01/2010 13:24, s...@pobox.com wrote:
Cesare ... (you can find the wpython 1.0 final here
Cesare http://code.google.com/p/wpython2/downloads/list).
I tried downloading it. Something about wpython10.7z and wpython10_fix.7z.
What's a 7z file? What tool on my Mac will unpack
2010/1/29 s...@pobox.com
Cesare ... (you can find the wpython 1.0 final here
Cesare http://code.google.com/p/wpython2/downloads/list).
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
Cesare Di Mauro cesare.di.mauro at 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
Cesare You can find 7-Zip tools here
Cesare http://www.7-zip.org/download.html.
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 to
2010/1/29 Antoine Pitrou solip...@pitrou.net
Cesare Di Mauro cesare.di.mauro at 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
2010/1/29 s...@pobox.com
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
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
Nick Coghlan ncoghlan at 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
2010/1/29 Nick Coghlan ncogh...@gmail.com
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
2010/1/29 Antoine Pitrou solip...@pitrou.net
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
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 better
On Fri, Jan 29, 2010 at 7:22 AM, Nick Coghlan ncogh...@gmail.com 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
On 1/29/2010 4:19 PM, Collin Winter wrote:
On Fri, Jan 29, 2010 at 7:22 AM, Nick Coghlanncogh...@gmail.com 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
Hey Terry,
On Fri, Jan 29, 2010 at 2:47 PM, Terry Reedy tjre...@udel.edu wrote:
On 1/29/2010 4:19 PM, Collin Winter wrote:
On Fri, Jan 29, 2010 at 7:22 AM, Nick Coghlanncogh...@gmail.com wrote:
Agreed. We originally switched Unladen Swallow to wordcode in our
2009Q1 release, and saw a
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 Coghlanncogh...@gmail.com
wrote:
Agreed. We originally switched Unladen Swallow to wordcode in our
2009Q1 release, and saw a performance improvement from this across the
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
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
On 1/29/2010 5:55 PM, Collin Winter wrote:
Hey Terry,
On Fri, Jan 29, 2010 at 2:47 PM, Terry Reedytjre...@udel.edu 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
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
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 has
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, greater
2010/1/30 exar...@twistedmatrix.com
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
2010/1/30 Scott Dial
scott+python-...@scottdial.comscott%2bpython-...@scottdial.com
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
On Wed, 2010-01-27 at 10:25 -0800, Collin Winter wrote:
On Wed, Jan 27, 2010 at 7:26 AM, William Dode w...@flibuste.net 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
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
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'
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
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 or
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 would
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 install (or
On 28 January 2010 12:58, Daniel Fetchinson fetchin...@googlemail.com 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?
On Thu, Jan 28, 2010 at 1:14 PM, Paul Moore p.f.mo...@gmail.com 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
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
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
On Thu, 2010-01-21 at 14:46 -0800, Jeffrey Yasskin wrote:
On Thu, Jan 21, 2010 at 10:09 AM, Hanno Schlichting ha...@hannosch.eu 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
Hi William,
On Wed, Jan 27, 2010 at 7:26 AM, William Dode w...@flibuste.net 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
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
On 27-01-2010, Collin Winter wrote:
Hi William,
On Wed, Jan 27, 2010 at 7:26 AM, William Dode w...@flibuste.net 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
Hi David,
On Wed, Jan 27, 2010 at 8:37 AM, David Malcolm dmalc...@redhat.com 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
Hi William,
On Wed, Jan 27, 2010 at 11:02 AM, William Dode w...@flibuste.net 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
On Wed, Jan 27, 2010 at 11:16 AM, Collin Winter collinwin...@google.com 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
On Wed, 2010-01-27 at 11:34 -0800, Jeffrey Yasskin wrote:
On Wed, Jan 27, 2010 at 11:16 AM, Collin Winter collinwin...@google.com
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
On 27 January 2010 08:37, David Malcolm dmalc...@redhat.com wrote:
On Thu, 2010-01-21 at 14:46 -0800, Jeffrey Yasskin wrote:
On Thu, Jan 21, 2010 at 10:09 AM, Hanno Schlichting ha...@hannosch.eu
wrote:
I'm a relative outsider to core development (I'm just a Plone release
manager),
Hi Collin,
2010/1/25 Collin Winter collinwin...@google.com
Hi Cesare,
On Sat, Jan 23, 2010 at 1:09 PM, Cesare Di Mauro
cesare.di.ma...@gmail.com 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
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
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
floris.bruynoo...@gmail.com 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
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
Hi Skip
For relatively stable code I talk about recent years.
My experience with CPython is limited, of course.
Cesare
2010/1/26 s...@pobox.com
Cesare ... but ceval.c has a relatively stable code ...
I believe you are mistaken on several counts:
* The names of the functions in
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 this
Hi Cesare,
On Tue, Jan 26, 2010 at 12:29 AM, Cesare Di Mauro
cesare.di.ma...@gmail.com 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
Hey Martin,
On Thu, Jan 21, 2010 at 2:25 PM, Martin v. Löwis mar...@v.loewis.de wrote:
Reid Kleckner wrote:
On Thu, Jan 21, 2010 at 4:34 PM, Martin v. Löwis mar...@v.loewis.de
wrote:
How large is the LLVM shared library? One surprising data point is that the
binary is much larger than some
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
Hi Floris,
On Sun, Jan 24, 2010 at 3:40 AM, Floris Bruynooghe
floris.bruynoo...@gmail.com 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
-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
Hi Cesare,
On Sat, Jan 23, 2010 at 1:09 PM, Cesare Di Mauro
cesare.di.ma...@gmail.com 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.
On Mon, Jan 25, 2010 at 10:44 AM, Tres Seaver tsea...@palladion.com 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
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 are
On Mon, Jan 25, 2010 at 11:48:56AM -0800, Jeffrey Yasskin wrote:
On Mon, Jan 25, 2010 at 10:44 AM, Tres Seaver tsea...@palladion.com 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
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
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 PPC
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jeffrey Yasskin wrote:
On Mon, Jan 25, 2010 at 10:44 AM, Tres Seaver tsea...@palladion.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Collin Winter wrote:
For reference, what are these obscure platforms where static
initializers
On Mon, Jan 25, 2010 at 1:50 PM, Martin v. Löwis mar...@v.loewis.de 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
Hey Floris,
On Mon, Jan 25, 2010 at 1:25 PM, Floris Bruynooghe
floris.bruynoo...@gmail.com 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
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
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
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 down.
On Mon, Jan 25, 2010 at 9:05 PM, Meador Inge mead...@gmail.com 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
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 systems,
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
doesn't make sense to force people use C for everything but the JIT part. In
the
2010/1/24 Floris Bruynooghe floris.bruynoo...@gmail.com
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
On Fri, Jan 22, 2010 at 11:07 AM, Collin Winter collinwin...@google.com wrote:
Hey Jake,
On Thu, Jan 21, 2010 at 10:48 AM, Jake McGuire mcgu...@google.com wrote:
On Thu, Jan 21, 2010 at 10:19 AM, Reid Kleckner r...@mit.edu wrote:
On Thu, Jan 21, 2010 at 12:27 PM, Jake McGuire
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 too much memory, longer loading time, and fat binaries
for not-so-great
1 - 100 of 193 matches
Mail list logo
