New Python implementation

[Mr Flibble]

On 14/02/2021 23:00, Christian Gollwitzer wrote:
> Am 14.02.21 um 11:12 schrieb Paul Rubin:
>> Christian Gollwitzer <auriocus at 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

-- 
😎