Pyret is very slow

[edu5...@gmail.com]

I don't use Python because it is very slow, when compared to Scheme or Common Lisp. I hoped that Pyret would solve this problem, since it is written on top of Racket, which is pretty fast. Then I wrote a few numerical examples in Pyret, both for integer numbers and real numbers. It turns out that Pyret is 21 times slower than Python. On the other hand, Python is almost 10 times slower than Racket, when dealing with numbers. That makes Pyret  200 times slower than Racket.

My first guess was that  Pyret tries to work with exact numbers, whenever this is possible,   while Python works with IEEE754 floating point representation.  Therefore, I wrote a small function to force Pyret into IEEE754.

fun float(s):
  s*(pi/4).tan()
end

The function worked, in the sense that it forced Pyret into floating point numbers. However, even with IEEE754 number, Pyret is 20 times slower than Python.

I think that Pyret speed must increase, at least to Python standars. Idealy, Pyret should be as fast as Racket.

[Joe Gibbs Politz]

Thanks for trying it out!

You're totally right that the current implementation of Pyret is too
slow for some things. We been trying to avoid decisions that preclude
a faster implementation, and we simply haven't put the engineering
focus into making things fast yet. We've been aiming for a flexible
implementation that we can change quickly to experiment with new
features rather than a streamlined and optimized runtime, and you're
seeing the result of that (there's a lot of boxing and unboxing going
on, for example, because we haven't optimized the values in our
runtime much).

Expect this to get better over the winter and into the spring as we
move towards stabilizing features and settling down our implementation
and runtime.

> --
> You received this message because you are subscribed to the Google Groups
> "Pyret Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to pyret-discus...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[Shriram Krishnamurthi]

Thanks for the feedback. We agree, though we have multiple
implementations, which further complicates any benchmarking.

But the goal was never to be benchmarking-ready this semester: we need
to get all the basic functionality in place. Long term, however, it is
totally not okay to be slow. In fact, several subtle decisions have
been made in the language to ensure compilation for performance.

We actually have multiple groups working on actual compilers for the
language. We want to be at least as fast as Racket, and hopefully
faster when we're typed.

Wait for early spring, and then we'll talk performance. Racket and
Python have had about 20 years head start on us. (-:

Shriram

[edu5...@gmail.com]

Thank you for your prompt answer. However, there is one thing that you could do, that can make Pyret almost as fast as Python. You could  offer us an easy method of inputting  floating point numbers into Pyret. For instance, if I write the following line on the IDE:

> 40.exp()
2.3538526683702045e+17

I get a floating point representation of a number. However, I cannot use this representation in my sources. For example:

#lang pyret

fun float(s):
  s*(pi/2).sin()
end

one = 1.0e+1
two = 2.0e+1

one+two

#====================
07:44 |~/lsp/pyret/testes# time racket tofloat.pyret
indentation: Expected to find one statement per line, but found multiple statements on this line.

However, if I had a representation for 64 bit integers and IEEE754 floating point constants, Pyret would work correctly:

#lang pyret

fun float(s):
  s*(pi/2).sin()
end

one = float(1)
two = float(1)

one+two

#==================
07:46 |~/lsp/pyret/testes# time racket tofloat.pyret
2.0

real    0m1.941s
user    0m1.764s
sys    0m0.184s

If I introduce the floating point constants into the benchmarks, Pyret is almost as fast as Python. If the compiler accepts the floating point constants, and prints them, it should also read them. I suppose that fixing the reader to accept floating point constant is not difficult.