On 14/02/2021 23:00, Christian Gollwitzer wrote:
Am 14.02.21 um 11:12 schrieb Paul Rubin:
Christian Gollwitzer <aurio...@gmx.de> writes:
He wants that neoGFX is scriptable in Python, but instead of linking
with CPython, he will write his own Python implementation instead,
because CPython is slow/not clean/ whatever. He doesn't seem to
understand that this is an enormous task on its own, because the
interesting part of a scripting language is the standard library with
many decade-years of work.
I wonder how big an issue the stdlib really is. Lots of it is written
in Python and can port to another interpreter. Lots more is CPython C
API bindings to external C libraries (e.g. OpenSSL) so porting those
would be a matter of rebinding those libraries to libffi in the cases
where that hasn't been done already.
I'm not saying that it is unfeasible or very difficult. I'm saying that it is a lot of work, and for a single
developer who has this as a side project / support for his graphics engine and who wants to beat existing
implementations wrt. speed, I'm saying it is going to take a lot of time. It'definitely impossible by
"defining a few JSON schema files", as Leigh claims with his "universal compiler". There
definitely IS a lot of stuff in a baseline CPython interpreter - a (seemingly) simple thing like
"print" will have an implementation of 1000 lines in C with all the formatting library, file I/O
etc. Arbitrary precision integers - another library, networking - yet another and so on.
There will only be one schema file and it is will be a relatively small task which certainly isn't
"impossible": I should have a working implementation by the summer. As far as arbitrary
precision integers are concerned I am well on the way to completing the "neonumeral"
library (which also has arbitrary precision floats).
As far as the standard library is concerned: that is already in Python so I
should be able to support it with little effort; the only thing requiring more
work would be the built-ins.
CPython really is pretty slow, maybe because it uses so much boxed data,
derps around with refcounts all the time, suffers memory fragmentation
from not having a relocating GC, etc. And that is before we even
mention the GIL.
I don't argue with that. CPython is slow. But I'm arguing that you can't make
it faster by multiple orders of magnitude unless you change the language. For
numerical code, straight-forward C is usually 100x to 1000x faster than Python,
and you can reach the same performance by giving up dynamic typing - Cython
demonstrates this quite convincingly. If you don't want static typing (with
types close to the machine like fixed-width integers) than you'll have to
resort to a LOT of black magic to even come close (PyPy, modern JS engines,
....)
I believe PyPy is only 4x faster than CPython on average and comes nowhere near
close to JS JIT engines performance-wise.
/Flibble
--
😎
--
https://mail.python.org/mailman/listinfo/python-list
