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; c
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):
Fil
> 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 test_in
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. Jes
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.
Raymond Hettinger 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
http://b
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 w
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 Pit
[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
l
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> Tryin
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; 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> Sour
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.
___
P
[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
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 c
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 differ
Kristján Valur Jónsson 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 shoul
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
> -Or
Kristján Valur Jónsson 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:
timeit.Timer("
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
usi
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
two-argumen
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
[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
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
>
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 i
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:
http://svirfneblin.org/stuf
26 matches
Mail list logo
