Re: Python-on-guile
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: > https://foss.heptapod.net/pypy/pypy/-/tree/branch/default/pypy/module/micronumpy > ) I think it would be wiser to use guile arrays to implement the same things as numpy.
Re: Python-on-guile
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 hard time to compete with that. But for math Guile is quite a bit faster than Python :-) (next frontier: compete with math that’s implemented via numpy — you can find RPython implementations of the basics of numpy in the pypy-sources: https://foss.heptapod.net/pypy/pypy/-/tree/branch/default/pypy/module/micronumpy ) Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken signature.asc Description: PGP signature
Re: Python-on-guile
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 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 then fastest python-on-guile which is 2x faster then >> python3 Cpython >> >> attached is a guile corresponding program. >> >> On Sat, Apr 24, 2021 at 4:41 PM Stefan Israelsson Tampe < >> stefan.ita...@gmail.com> wrote: >> >>> To note is that 'continue' is killing performance for python-on-guile >>> programs, so by changing the >>> code to not use continue lead to python-on-guile running twice the speed >>> of python3. The reason is that >>> the while loop is used as >>> (while (...) >>>(let/ec continue >>> ...)) >>> >>> And the let/ec is probably not optimally compiled. Python-on-guile will >>> check the loop for continue usage and if not then it will skip the let/ec. >>> >>> I attached the code not using continue >>> >>> On Sat, Apr 24, 2021 at 2:59 PM Stefan Israelsson Tampe < >>> stefan.ita...@gmail.com> wrote: >>> Actually changing in (language python compile), (define (letec f) (let/ec x (f x To (define-syntax-rule (letec f) (let/ec x (f x Actually lead to similar speeds as python3. On Sat, Apr 24, 2021 at 1:26 PM Stefan Israelsson Tampe < stefan.ita...@gmail.com> wrote: > Pro tip, when running this on guile the scheme code that it compilse > to is located in log.txt. > If you ,opt the resulting code in a guile session you might be able to > pinpoint issues that > delays the code execution. > > On Sat, Apr 24, 2021 at 12:04 PM Mikael Djurfeldt < > mik...@djurfeldt.com> wrote: > >> (I should perhaps add that my script doesn't benchmark the object >> system but rather loops, conditionals and integer arithmetic.) >> >> Den fre 23 apr. 2021 17:00Mikael Djurfeldt >> skrev: >> >>> Hi, >>> >>> Yesterday, Andy committed new code to the compiler, some of which >>> concerned skipping some arity checking. >>> >>> Also, Stefan meanwhile committed something called "reworked object >>> system" to his python-on-guile. >>> >>> Sorry for coming with unspecific information (don't have time to >>> track down the details) but I noticed that my benchmark script written >>> in >>> Python, and which computes the 20:th Ramanujan number, now runs 60% >>> faster >>> than before these changes. >>> >>> This means that python-on-guile running on guile3 master executes >>> python code only 2.6 times slower than the CPython python3 interpreter >>> itself. :-) >>> >>> Have a nice weekend all, >>> Mikael >>> >>>
Re: Python-on-guile
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 something called "reworked object system" > to his python-on-guile. > > Sorry for coming with unspecific information (don't have time to track > down the details) but I noticed that my benchmark script written in Python, > and which computes the 20:th Ramanujan number, now runs 60% faster than > before these changes. > > This means that python-on-guile running on guile3 master executes python > code only 2.6 times slower than the CPython python3 interpreter itself. :-) > > Have a nice weekend all, > Mikael > >
Re: Python-on-guile
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 for 3x speedwise, but it may hinder optimisations that may yield a speedup of that factor. On Sat, Apr 24, 2021 at 5:19 PM Stefan Israelsson Tampe < stefan.ita...@gmail.com> wrote: > Guile is 3x faster then fastest python-on-guile which is 2x faster then > python3 Cpython > > attached is a guile corresponding program. > > On Sat, Apr 24, 2021 at 4:41 PM Stefan Israelsson Tampe < > stefan.ita...@gmail.com> wrote: > >> To note is that 'continue' is killing performance for python-on-guile >> programs, so by changing the >> code to not use continue lead to python-on-guile running twice the speed >> of python3. The reason is that >> the while loop is used as >> (while (...) >>(let/ec continue >> ...)) >> >> And the let/ec is probably not optimally compiled. Python-on-guile will >> check the loop for continue usage and if not then it will skip the let/ec. >> >> I attached the code not using continue >> >> On Sat, Apr 24, 2021 at 2:59 PM Stefan Israelsson Tampe < >> stefan.ita...@gmail.com> wrote: >> >>> Actually changing in (language python compile), >>> >>> (define (letec f) >>> (let/ec x (f x >>> >>> To >>> >>> (define-syntax-rule (letec f) >>> (let/ec x (f x >>> >>> Actually lead to similar speeds as python3. >>> >>> >>> >>> On Sat, Apr 24, 2021 at 1:26 PM Stefan Israelsson Tampe < >>> stefan.ita...@gmail.com> wrote: >>> Pro tip, when running this on guile the scheme code that it compilse to is located in log.txt. If you ,opt the resulting code in a guile session you might be able to pinpoint issues that delays the code execution. On Sat, Apr 24, 2021 at 12:04 PM Mikael Djurfeldt wrote: > (I should perhaps add that my script doesn't benchmark the object > system but rather loops, conditionals and integer arithmetic.) > > Den fre 23 apr. 2021 17:00Mikael Djurfeldt > skrev: > >> Hi, >> >> Yesterday, Andy committed new code to the compiler, some of which >> concerned skipping some arity checking. >> >> Also, Stefan meanwhile committed something called "reworked object >> system" to his python-on-guile. >> >> Sorry for coming with unspecific information (don't have time to >> track down the details) but I noticed that my benchmark script written in >> Python, and which computes the 20:th Ramanujan number, now runs 60% >> faster >> than before these changes. >> >> This means that python-on-guile running on guile3 master executes >> python code only 2.6 times slower than the CPython python3 interpreter >> itself. :-) >> >> Have a nice weekend all, >> Mikael >> >>
Re: Python-on-guile
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 then fastest python-on-guile which is 2x faster then > python3 Cpython > > attached is a guile corresponding program. > > On Sat, Apr 24, 2021 at 4:41 PM Stefan Israelsson Tampe < > stefan.ita...@gmail.com> wrote: > >> To note is that 'continue' is killing performance for python-on-guile >> programs, so by changing the >> code to not use continue lead to python-on-guile running twice the speed >> of python3. The reason is that >> the while loop is used as >> (while (...) >>(let/ec continue >> ...)) >> >> And the let/ec is probably not optimally compiled. Python-on-guile will >> check the loop for continue usage and if not then it will skip the let/ec. >> >> I attached the code not using continue >> >> On Sat, Apr 24, 2021 at 2:59 PM Stefan Israelsson Tampe < >> stefan.ita...@gmail.com> wrote: >> >>> Actually changing in (language python compile), >>> >>> (define (letec f) >>> (let/ec x (f x >>> >>> To >>> >>> (define-syntax-rule (letec f) >>> (let/ec x (f x >>> >>> Actually lead to similar speeds as python3. >>> >>> >>> >>> On Sat, Apr 24, 2021 at 1:26 PM Stefan Israelsson Tampe < >>> stefan.ita...@gmail.com> wrote: >>> Pro tip, when running this on guile the scheme code that it compilse to is located in log.txt. If you ,opt the resulting code in a guile session you might be able to pinpoint issues that delays the code execution. On Sat, Apr 24, 2021 at 12:04 PM Mikael Djurfeldt wrote: > (I should perhaps add that my script doesn't benchmark the object > system but rather loops, conditionals and integer arithmetic.) > > Den fre 23 apr. 2021 17:00Mikael Djurfeldt > skrev: > >> Hi, >> >> Yesterday, Andy committed new code to the compiler, some of which >> concerned skipping some arity checking. >> >> Also, Stefan meanwhile committed something called "reworked object >> system" to his python-on-guile. >> >> Sorry for coming with unspecific information (don't have time to >> track down the details) but I noticed that my benchmark script written in >> Python, and which computes the 20:th Ramanujan number, now runs 60% >> faster >> than before these changes. >> >> This means that python-on-guile running on guile3 master executes >> python code only 2.6 times slower than the CPython python3 interpreter >> itself. :-) >> >> Have a nice weekend all, >> Mikael >> >>
