Hi,
I implemented a variant of the CPython VM on top of Gforth's Vmgen; this made
it fairly straightforward to add direct threaded code and superinstructions for
the various permutations of LOAD_CONST, LOAD_FAST, and most of the two-argument
VM instructions.
Sources:
2008/10/22 J. Sievers [EMAIL PROTECTED]:
I implemented a variant of the CPython VM on top of Gforth's Vmgen; this made
it fairly straightforward to add direct threaded code and superinstructions
for
the various permutations of LOAD_CONST, LOAD_FAST, and most of the
two-argument
VM
On 2008-10-22 14:16, J. Sievers wrote:
Hi,
I implemented a variant of the CPython VM on top of Gforth's Vmgen; this made
it fairly straightforward to add direct threaded code and superinstructions
for
the various permutations of LOAD_CONST, LOAD_FAST, and most of the
two-argument
VM
[EMAIL PROTECTED] wrote:
I checked in the contents of my multiprocessing.tar file and opened issues
#1 and #2.
I added a setup.py, disabled recv_bytes_into for now and fixed lots of
naming issues. The multiprocessing code is using the new names of the
threading module (current_thread, is_alive
Maybe we should backport those handy pep8 threading names ... ... Ok maybe
not.
On Oct 22, 2008 9:02am, Christian Heimes [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
I checked in the contents of my multiprocessing.tar file and opened issues
#1 and #2.
I added a setup.py, disabled
On Oct 22, 2008, at 10:16 AM, J. Sievers wrote:
Hi,
I implemented a variant of the CPython VM on top of Gforth's Vmgen;
this made
it fairly straightforward to add direct threaded code and
superinstructions for
the various permutations of LOAD_CONST, LOAD_FAST, and most of the
Hello there.
I was surprised to find recently that the heapq module is still a pure python
implementation.
A few years ago we wrote our own in C for use in Eve-online, and we usually do a
import blue.heapq as heapq.
Having a python implementation of it almost completely negates any benefit of
Kristján Valur Jónsson kristjan at ccpgames.com writes:
timeit.Timer((l.sort(), l[-1]),
s).timeit(1000)
0.29406761513791935
This is clearly wrong. l.sort() will sort the list in place when it is first
invoked, and therefore will be very fast in subsequent calls.
Compare with:
Ooops, you are right.
Silly error on my part.
Still, my comment about heapq still stands,
and
[hack, slash]
0.39713821814841893 (old)
0.35184029691278162 (hakced, for special list treatment)
So, there is a 12% performance boost to be had by specializing for lists.
How about it?
K
Ok. And sorry, I missed your part about heapq now having a c implementation.
This is indeed good, I was misled by the presence of heapq.py.
However, our own heapify() implementation is some 10% faster on a 1 element
list of floats than the _heapq.heapify() version.
I'll investigate the
Christian I just implemented the recv_bytes_into function with the old
Christian buffer protocol. All tests are passing on my Linux box
Christian (Ubuntu 8.04 with gcc 4.2, AMD64 processor).
Using Python v 2.6? So I don't need to horse around making
test_multiprocessing.py API
Kristján Valur Jónsson kristjan at ccpgames.com writes:
0.39713821814841893 (old)
0.35184029691278162 (hakced, for special list treatment)
So, there is a 12% performance boost to be had by specializing for lists.
How about it?
It depends on the added code complexity. In any case, you
[EMAIL PROTECTED] wrote:
Using Python v 2.6? So I don't need to horse around making
test_multiprocessing.py API compatible with processing 0.52?
With Python 2.5.2 and 2.6.0 all tests are passing with any error. With
Python 2.4.5 seven tests are failing because 2.4 doesn't support mmap
with
I have submitted a patch for min() and max():
http://bugs.python.org/issue4174
-Original Message-
It depends on the added code complexity. In any case, you should open
an entry
on the tracker and post your patch there.
___
J I implemented a variant of the CPython VM on top of Gforth's Vmgen; this
made
J it fairly straightforward to add direct threaded code and
superinstructions for
J the various permutations of LOAD_CONST, LOAD_FAST, and most of the
two-argument
J VM instructions.
J Sources:
Kristján Valur Jónsson wrote:
Ok. And sorry, I missed your part about heapq now having a c implementation.
This is indeed good, I was misled by the presence of heapq.py.
Duplicate Python/C code will probably become more common. Even if the
Python is not used for prototyping (which I believe
J I implemented a variant of the CPython VM on top of Gforth's Vmgen;
J this made it fairly straightforward to add direct threaded code and
J superinstructions for the various permutations of LOAD_CONST,
J LOAD_FAST, and most of the two-argument VM instructions.
Skip Trying to
[EMAIL PROTECTED] wrote:
Using Python v 2.6? So I don't need to horse around making
test_multiprocessing.py API compatible with processing 0.52?
I've backported the Python 2.5 svn version of mmap to 2.4 and added it
as multiprocessing._mmap25. The port is just a proof of concept and most
I
Kt just occurred to me:
Even though l.sort() is sorting a presorted array, it still must be doing
1-1 RichCompares minimum, just like max. So how do we explain the
large difference?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf
Of Antoine Pitrou
I think this should be taken off of python-dev until
you have some quality measurements,
know what's going on, and have an actionable idea.
Aside from list specialization versus a general iterator
protocol, there is no fat in the min/max implementation.
It loops, it compares, it returns.
If we
Raymond Hettinger python at rcn.com writes:
If we wanted to go the distance and type specialize,
it is possible to use the same ideas that used in
Py2.6's builtin sum() to speed-up compares for particular types.
Would it be useful to create a macro that packs some of the optimizations in
On Wed, Oct 22, 2008 at 3:51 PM, Raymond Hettinger [EMAIL PROTECTED] wrote:
Aside from list specialization versus a general iterator
protocol, there is no fat in the min/max implementation.
It loops, it compares, it returns.
Also, a primary use case for min/max is with just two inputs.
We
The latest svn version is now working with Python 2.4.4, Python 2.5.2
and Python 2.6.0 on Linux (Ubuntu AMD64, Debian i386) and Windows XP. On
Windows the multiprocessing module requires ctypes and pywin32 under
Python 2.4.4.
Some of the examples aren't working correctly under 2.4 and 2.5.
Feedback is, of course, very welcome and it'd be great to have some pybench
results from different machines.
My results are very similar to Jakob's.
Gentoo Linux, 32-bit x86, Athlon 6400+ underclocked to 3.0 GHz.
make test:
282 tests OK.
5 tests failed:
test_doctest test_hotshot
In version of Python prior to 2.5, it would appear that deepcopying
compiled regular expressions worked by accident:
2.4:
copy.deepcopy(re.compile(''))
_sre.SRE_Pattern object at 0xb7d53ef0
2.5:
copy.deepcopy(re.compile(''))
Traceback (most recent call last):
File
David Ripton wrote:
Feedback is, of course, very welcome and it'd be great to have some pybench
results from different machines.
My results are very similar to Jakob's.
From looking thru the vmgen manual, there are two things it is doing
that CPython is not. 1. gcc-specific threaded code;
26 matches
Mail list logo
