This sounds good to me, Armin. I've always felt that a JIT that can't
learn from previous executions is never going to be able to make deep
optimisations. And all mainstream jits have this problem, they get to
a certain level of optimisation technology and stagnate. So I think
this is a really g
On Sun, Mar 30, 2014 at 03:36:08PM +0300, anatoly techtonik wrote:
> On Sun, Mar 30, 2014 at 2:40 PM, Kenny Lasse Hoff Levinsen
> wrote:
> > Okay, just to get things right: What you want is an only-ABI solution,
> > which abstracts completely away from technical details, in a nice pythonic
> > w
On Thu, Jan 23, 2014 at 10:45:25PM +0200, Elefterios Stamatogiannakis wrote:
> >But having said all this, I know that using UTF-8 internally for strings
> >is quite common (e.g. Haskell does it, without even an index cache, and
> >documents that indexing operations can be slow). CPython's FSR has
>
Is there a nicer way to pass python long ints (bigint) into C
efficiently? I'm currently cutting the value up into 64 bit chunks in
python and passing in as an unsigned long*:
cdef("int bigInt(int n, unsigned long* x);")
x = sum(1 << i for i in [100,200,123])
xs = []
while x > 0:
xs.append(x
On Thu, Oct 24, 2013 at 11:27:05AM -0700, Andrew Francis wrote:
> The University of Chicago/Microsoft Research paper "Scalable Join
> Patterns" (http://www.mpi-sws.org/~turon/scalable-joins.pdf)
> outlines an approach for implementing join patterns using
> essentially lock-free bags, optimistic lo
. (OT: does anyone recommend a better IDE than
pydev+eclipse?)
njh
On Tue, Jul 30, 2013 at 11:01:30AM +0200, Maciej Fijalkowski wrote:
> This sounds odd. My PyPy does not leak memory in this example. Can you
> please double check?
>
> On Tue, Jul 30, 2013 at 2:43 AM, Nathan Hurst
Is there a way to call special operators such as __builtin_popcount
from within pypy?
regards,
njh
___
pypy-dev mailing list
pypy-dev@python.org
http://mail.python.org/mailman/listinfo/pypy-dev
I was playing with this simple function to compute uint/3. It does
not (afaict) directly allocate any memory, but when run it rapidly
consumes all memory (32GB):
def divu3(n):
q = (n >> 2) + (n >> 4) # q = n*0.0101 (approx).
q = q + (q >> 4) # q = n*0.01010101.
q = q + (q >> 8) # q
On Mon, Jul 22, 2013 at 09:06:51AM +0200, Maciej Fijalkowski wrote:
> On Mon, Jul 22, 2013 at 8:18 AM, Nathan Hurst wrote:
> > On Sun, Jul 21, 2013 at 08:25:46PM -0700, Alex Gaynor wrote:
> >> No, there currently isn't a way to parallelize building.
> >
> > O
On Sun, Jul 21, 2013 at 08:25:46PM -0700, Alex Gaynor wrote:
> No, there currently isn't a way to parallelize building.
Ok. Is it hard or just low priority?
> Alex
>
> PS: Attentive readers will note that technically the very last phase of
> compilation is parallelized.
Yes, and I guess if it
Dear mailing list,
I have looked around the web and through the various makefiles and
pypy/goal/targetpypystandalone.py and I can't work out how to make
pypy build using more cores. I have plenty of RAM (64GB) but the
build is only using a single core. Is it possible?
njh
___
On Fri, Jul 05, 2013 at 11:17:15PM +0200, Armin Rigo wrote:
> Hi Sean,
>
> On Fri, Jul 5, 2013 at 8:30 PM, Sean Fisk wrote:
> > For my internship, I am working on implementing a solver for partial
> > differential equations in RPython. I am investigating the possibility of
> > parallelizing the c
On Sat, Jun 29, 2013 at 04:27:02PM +0200, Carl Friedrich Bolz wrote:
> On 29.06.2013 16:19, Nathan Hurst wrote:
> >On Wed, Jun 26, 2013 at 09:06:01AM +0200, Carl Friedrich Bolz wrote:
> >>On 30.05.2013 18:41, Nathan Hurst wrote:
> >>>It doesn't have to be qua
On Wed, Jun 26, 2013 at 09:06:01AM +0200, Carl Friedrich Bolz wrote:
> On 30.05.2013 18:41, Nathan Hurst wrote:
> >It doesn't have to be quadratic, it's easy to come up with a splitting
> >algorithm:
>
> FWIW, I started turning this code into RPython code on the
>
On Wed, Jun 05, 2013 at 04:32:39AM +, cuitao wrote:
> hello, can you consider adding the blist support in pypy ?
> blist: a list-like type with better asymptotic performance and similar
> performance on small lists
blist is written in C though, and pypy is written in python. Perhaps
you woul
Sent to Carl only by mistake, I'm still getting the hang of this
newfangled email thing...
Carl said
> Armin said
> >No, precisely my point: this argument is bogus. The proof that it's
> >wrong is that CPython gets very similar timing results! Your pure
> >Python version outperforms the C str(lo
On Thu, May 30, 2013 at 10:23:17AM +0200, Armin Rigo wrote:
> Hi all,
>
> Some people learn about PyPy, and the first program they try to
> measure speed with is something like this:
>
> def factorial(n):
> res = 1
> for i in range(1, n + 1):
> res *= i
> return res
> print fa
17 matches
Mail list logo
