On 29/06/13 20:06, Nathan Hurst wrote:
> I don't actually see any difference between that code and normal
> python. What makes it rpython?
Being RPython is mostly a contextual property. It does nothing "too
dynamic", so it is RPython.
>> The main changes I did from your version was generalize i
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 quadratic, it's easy to come up with a spli
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
> faster-str-of-bigint branch.
Do
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 quadratic, it's easy to come up with a splitting
algorithm:
FWIW, I started turning this code into RPython code on the
f
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
faster-str-of-bigint branch.
Cheers,
Carl Friedrich
___
pypy-dev ma
Hi Nathan,
On Fri, May 31, 2013 at 5:48 PM, Nathan Hurst wrote:
> For what it's worth, the time for str(long) / time for recursive
> algorithm does decrease steadily for increasing input lengths. But
> it's not n^2 / n log n. Perhaps we need to implement a faster divmod?
Actually I found an ol
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
Hi Carl Friedrich,
On Fri, May 31, 2013 at 12:01 PM, Carl Friedrich Bolz wrote:
> I have only glanced at the code, but isn't the right argument of the divmod
> always a power of two? So it can be replaced by a shift and a mask, giving
> the right complexity.
It's a power of 10.
A bientôt,
Arm
Hi Bengt,
On Fri, May 31, 2013 at 3:01 PM, Bengt Richter wrote:
> [PyPy 1.5.0-alpha0 with GCC 4.4.3] on linux2
>
> ... Hm, wonder why your factorial was slower on pypy .. prob due to old
> version?
Another benchmark that completely misses the point, yay! This one
shows that we improved quite a
On 05/30/2013 06:41 PM Nathan Hurst wrote:
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 *
Hi Armin,
I have only glanced at the code, but isn't the right argument of the divmod
always a power of two? So it can be replaced by a shift and a mask, giving the
right complexity.
Cheers,
Carl Friedrich
Armin Rigo wrote:
>Hi Nathan,
>
>On Thu, May 30, 2013 at 6:41 PM, Nathan Hurst wr
Hi Nathan,
On Thu, May 30, 2013 at 6:41 PM, Nathan Hurst wrote:
> It doesn't have to be quadratic, it's easy to come up with a splitting
> algorithm:
I believe that you're right on one point and wrong on another. You're
right in that this gives a faster algo for str(). You're wrong in
that it'
2013/5/30 Nathan Hurst
> > Does it still make sense to add programs like this to our benchmarks?
> > So far, our benchmarks are "real-life" examples. The benchmarks like
> > above are completely missing the point of PyPy, as they don't stress
> > at all the Python interpreter part. There are al
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
On 30/05/13 11:23, Armin Rigo wrote:
... There are also other cases where
PyPy's performance is very bad, like cpyext on an extension module
with lots of small C API calls. I believe that it would still make
sense to list such cases in the official benchmark, and have the
descriptions of the b
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 factorial(25000)
It may not be completely obvious a priori, but this is as bogus as
16 matches
Mail list logo
