Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SPy: An interpreter and compiler for a fast statically typed variant of Python

antocuni.eu

Post reply on HN
Print view View original

21–30 of 133 posts

Re: SPy: An interpreter and compiler for a fast statically typed variant of Python

#21

Post by pjmlp »

cardanome wrote: post #18

Common Lisp also allows you to redefine everything at runtime but doesn't suffer from the same performance issues that Python has, does it? Doe anyone have insight into this?

Just like Smalltalk and SELF, also Lisp Machines and Interlisp-D.

Usually comes down from a urban myth that Python is special and there was no other dynamic language before it came to be.

The JIT research on those platforms is what gave us leading JIT capabilities on modern runtimes, OpenJDK HotSpot traces back to Smalltalk and StrongTalk, while V8 traces back to SELF.

Especially in Smalltalk and SELF, you can change anything at any time across the whole image, and have the JIT pick up on that and re-optimize.

Granted what messes up Python, or better said CPython implemenation, is that C extensions are allowed to mess up with its internals thus making void many possible optimizations that would be otherwise available.

A reason why JVM, CLR, V8, ART make use of handles and have marshaling layers not allowing such kind of liberties with native extensions.

Re: SPy: An interpreter and compiler for a fast statically typed variant of Python

#22

Post by nickcw »

This looks like a very interesting approach bringing comptime to a static version of python. This version of comptime can then be used to define new types in the same way Zig does it.

I absolutely hate the terminology though red/blue redshifting etc. Why do blue functions disappear when redshifting? If you red shift blue then it goes down in frequency so you might get green or red. Perhaps my physics brain is just over thinking it!

> The other fundamental concept in SPy is redshifting.

> Each expression is given a color:

> blue expressions are those which can safely be evaluated ahead of time, because they don't have side effects and all operands are statically known.

> red expressions are those which needs to be evaluated at runtime.

> During redshifting we eagerly evaluate all the blue parts of the code: it's a form of partial evaluation. This process plays very well with the freezing that we discussed above, because a lot of operations on frozen data become automatically blue: for example, if we statically know the type of an object, the logic to look up a method inside the frozen class hierarchy is a blue operation and it's optimized away, leaving just a direct call as a result.

Please just rename it comptime then at least people who have learnt Zig will know what it means immediately.

In FORTH these would have been called IMMEDIATE words. Namely functions which run at "compile" time rather than run time.

Re: SPy: An interpreter and compiler for a fast statically typed variant of Python

#23

Post by a-french-anon »

cardanome wrote: post #18

Common Lisp also allows you to redefine everything at runtime but doesn't suffer from the same performance issues that Python has, does it? Doe anyone have insight into this?

Common Lisp doesn't use (expensive) CLOS dispatch in the core language, e.g. to add two numbers or find the right equality operator. That's one known pain point due to CLOS having been "bolted-on" rather than part of the language which makes the divide between internal (using typecase and similar) and external (generic functions) dispatch pretty ugly; and gave use the eql/equal/equalp/etc... hell.

Thing is that you need a complex JIT like Julia's or stuff like https://github.com/marcoheisig/fast-generic-functions to offset the cost of constant dynamic dispatch.

I actually had such a conversation on that comparison earlier this year: https://lwn.net/Articles/1032617/

Re: SPy: An interpreter and compiler for a fast statically typed variant of Python

#25

Post by sevensor »

Neat idea! Author’s ideas about different subsets of Python are worth the price of admission. What you can express in the type system, what performs well under JIT, what’s basically same and reasonable, may not be precisely specified, but are still useful and distinct ideas.

Re: SPy: An interpreter and compiler for a fast statically typed variant of Python

#26

Post by ForceBru »

AmazingTurtle wrote: post #24

> SPy is [...] a compiler > SPy is not a "compiler for Python" I think it's funny how it's confusing from the first paragraph

Reading the next sentence clears the confusion:

> SPy is not a "compiler for Python". There are features of the Python language which will never be supported by SPy by design. Don't expect to compile Django or FastAPI with SPy.

Re: SPy: An interpreter and compiler for a fast statically typed variant of Python

#28

Post by psychoslave »

a-french-anon wrote: post #23
cardanome wrote: post #18

Common Lisp also allows you to redefine everything at runtime but doesn't suffer from the same performance issues that Python has, does it? Doe anyone have insight into this?

Common Lisp doesn't use (expensive) CLOS dispatch in the core language, e.g. to add two numbers or find the right equality operator. That's one known pain point due to CLOS having been "bolted-on" rather than part of the language which makes the divide between internal (using typecase and similar) and external (generic functions) dispatch pretty ugly; and gave use the eql/equal/equalp/etc... hell. Thing is that you n…

What is CLOS in this context?

Re: SPy: An interpreter and compiler for a fast statically typed variant of Python

#29

Post by graemep »

The problem with this is that the main value of Python is its ecosystem. SPy aims to be able to import Python libraries, but also not implement all Python features. If you are not 100% compatible how can you reliably import libraries?

SPy seems most likely to be more likely to be appealing as a more Pythonic alternative to Cython rather than a Python replacement.

Re: SPy: An interpreter and compiler for a fast statically typed variant of Python

#30

Post by bradrn »

psychoslave wrote: post #28
a-french-anon wrote: post #23

Earlier quoted context omitted.

Common Lisp doesn't use (expensive) CLOS dispatch in the core language, e.g. to add two numbers or find the right equality operator. That's one known pain point due to CLOS having been "bolted-on" rather than part of the language which makes the divide between internal (using typecase and similar) and external (generic functions) dispatch pretty ugly; and gave use the eql/equal/equalp/etc... hell. Thing is that you n…

What is CLOS in this context?

The Common Lisp Object System: https://en.wikipedia.org/wiki/Common_Lisp_Object_System
Post reply on HN