Hello,
Le dimanche 25 avril 2021 à 12:54 +0200, Dr. Arne Babenhauserheide a
écrit :
> (next frontier: compete with math that’s implemented via numpy — you
> can find RPython implementations of the basics of numpy in the
> pypy-sources:
>
Stefan Israelsson Tampe writes:
> (define-syntax-rule (letec f)
> (let/ec x (f x
>
> Actually lead to similar speeds as python3.
Please keep in mind that this is math. There are parts of Python that
are heavily optimized, for example reading strings from disk. Guile will
likely have a
It is not the break let/ex that slows it down. But for wha it's worth we do
not do a let/ec if no break is used. Now.
On Sun, 25 Apr 2021, 10:20 Mikael Djurfeldt wrote:
> Nice!
>
> I guess it would be nice if "continue" *could* be compiled efficiently.
> And, as you indicate, perhaps that would
Python List lookup is 2x slower now than cpython. Tuple lookup is slightly
faster.
On Fri, 23 Apr 2021, 17:01 Mikael Djurfeldt wrote:
> Hi,
>
> Yesterday, Andy committed new code to the compiler, some of which
> concerned skipping some arity checking.
>
> Also, Stefan meanwhile committed
The remaining 3x between guile and python can be to either the extensive
usage of set! in python or if the number of runs in the inner loop is small
because there is a let/ec for the break and according to the standard
a catch to support the raising of StopIteration. Set! probably cannot
account
Nice!
I guess it would be nice if "continue" *could* be compiled efficiently.
And, as you indicate, perhaps that would amount to efficiently compiling
let/ec.
Best regards,
Mikael
On Sat, Apr 24, 2021 at 5:19 PM Stefan Israelsson Tampe <
stefan.ita...@gmail.com> wrote:
> Guile is 3x faster
