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

A tail calling interpreter for Python (already landed in CPython)

blog.reverberate.org

Post reply on HN
Print view View original

51–60 of 93 posts

Re: A tail calling interpreter for Python (already landed in CPython)

#51

Post by noelwelsh »

riffraff wrote: post #28

How does this differ from direct threading interpreters? It seems like it solves the same problem (saving the function call overhead) and has the same downsides (requires non-standard compiler extensions) EDIT: it seems the answer is that compilers do not play well with direct-threaded interpreters and they are able to perform more/better optimizations when looking at normal-sized functions rather than massive blocks…

Unfortunately, most discussion of direct threaded interpreters confuses the implementation techniques (e.g. computed gotos) with the concepts (tail calls, or duality between calls and returns and data and codata, depending on your point of view). What is presented here is conceptually a direct threaded interpreter. It's just implemented in a way that is more amenable to optimization by the compiler technology in use.

(More here: https://noelwelsh.com/posts/understanding-vm-dispatch/)

Re: A tail calling interpreter for Python (already landed in CPython)

#52

Post by nine_k »

saidinesh5 wrote: post #12

Recent discussion: https://news.ycombinator.com/item?id=42999672 Do check out the articles in the top most comment.. about how tail call optimization gets you faster interpreters. It completely eliminates the overhead of function calls in the generated machine code while you still your code modularly using functions.

I think this technique is known since 1970s as "direct threaded code".

Re: A tail calling interpreter for Python (already landed in CPython)

#53

Post by kryptiskt »

hathawsh wrote: post #47
pinoy420 wrote: post #36

Earlier quoted context omitted.

Amazing it can do that. How does it work? That definitely does seem to change its semantics to me. I am not a c expert but this surely has problems the previous one doesn’t?

It does change the semantics if n is negative or large enough to cause an overflow. The challenge for the compiler is to somehow prove that neither of those things can happen.

It doesn't have to prove absence of overflow since that is undefined behavior in C and thus modern compilers assume it can never happen.

Re: A tail calling interpreter for Python (already landed in CPython)

#54

Post by coldtea »

riffraff wrote: post #28

How does this differ from direct threading interpreters? It seems like it solves the same problem (saving the function call overhead) and has the same downsides (requires non-standard compiler extensions) EDIT: it seems the answer is that compilers do not play well with direct-threaded interpreters and they are able to perform more/better optimizations when looking at normal-sized functions rather than massive blocks…

>and has the same downsides (requires non-standard compiler extensions)

It's not a downside if:

(a) you have those non-standard compiler extensions in the platforms you target

(c) for the rest, you can ifdef an alternative that doesn't require them

Re: A tail calling interpreter for Python (already landed in CPython)

#55

Post by pjmlp »

flakes wrote: post #25
throwaway81523 wrote: post #6

Earlier quoted context omitted.

Python has always been unashamedly imperative, with some functional features entering by slipping through the cracks. The pattern matching thing seemed ok to me when I tried it, but I haven't used it except briefly, since I'm still mostly on Python 3.9. Interestingly, Python has been losing users to Rust. I don't entirely understand that, other than everyone saying how Rust's tooling is so much better.

> Python has been losing users to Rust. I don't entirely understand that, other than everyone saying how Rust's tooling is so much better. Not to rust, but to Go and C++ for myself. The biggest motivating factor is deployment ease. It is so difficult to offer a nice client install process when large virtual environments are involved. Static executables solve so many painpoints for me in this arena. Rust would probabl…

As someone that always kept a foot on C++ land, dispite mostly working on managed languages, I would that by C++17 (moreso now in C++23), dispite all its quirks and warts, C++ has become good enough that I can write Python like code with it.

Maybe it is only a thing to those of us already damaged with C++, and with enough years experience using it, but there are still plenty of such folks around to matter, specially to GPU vendors, and compiler writers.

Re: A tail calling interpreter for Python (already landed in CPython)

#57

Post by coldtea »

beagle3 wrote: post #43
dragonwriter wrote: post #26

Earlier quoted context omitted.

By that standard, any optimization that changes scaling in any dimension changes semantics, which, well, I’m not saying its wrong, but I would say it is exactly what people looking for optimization want.

I disagree. An optimization that speeds a program by x2 has the same effect as running on a faster CPU. An optimization that packs things tighter into memory has the same effect as using more memory. Program semantics are usually referred to as “all output given all input, for any input configuration” but ignoring memory use or CPU time, provided they are both finite (but not limited). TCE easily converts a program t…

>I probably won’t argue that a change that reduces an O(n^5) space/time requirement to an O(1) requirement is a change in semantics, even though it practically is a huge change

Space/time requirements aren't language semantics though, are they?

Re: A tail calling interpreter for Python (already landed in CPython)

#58

Post by coldtea »

throwaway81523 wrote: post #6
rpcope1 wrote: post #3

Earlier quoted context omitted.

That's probably one of the more frustrating things about Python. Each release it gets all sorts of questionable new syntax (including the very strange pattern matching "feature" that kind of sucks compared to something like Erlang or Scala), but we never get real useful quality of life improvements for basic functional programming like TCO or multi line lambdas

Python has always been unashamedly imperative, with some functional features entering by slipping through the cracks. The pattern matching thing seemed ok to me when I tried it, but I haven't used it except briefly, since I'm still mostly on Python 3.9. Interestingly, Python has been losing users to Rust. I don't entirely understand that, other than everyone saying how Rust's tooling is so much better.

>Python has been losing users to Rust

Not really.

Re: A tail calling interpreter for Python (already landed in CPython)

#59

Post by rcxdude »

podunkPDX wrote: post #23
IgorPartola wrote: post #11

Earlier quoted context omitted.

Python is fast enough for a whole set of problems AND it is a pretty, easy to read and write language. I do think it can probably hit pause on adding more syntax but at least everything it adds is backwards compatible. You won’t be writing a 3D FPS game engine in Python but you definitely can do a whole lot of real time data processing, batch processing, scientific computing, web and native applications, etc. before…

> You won’t be writing a 3D FPS game engine in Python While Eve Online isn’t an FPS, it is an MMORPG written in stackless Python, and seems to be doing OK.

They do continuously struggle with CPU load and by all accounts have a mountain range of technical debt from that decision, though.

Re: A tail calling interpreter for Python (already landed in CPython)

#60

Post by raverbashing »

guappa wrote: post #39
kqr wrote: post #31

Earlier quoted context omitted.

I think this is a change longer in the making than that. Back when I started working with Python in the mid--late 2000s, the Zen was holy and it seemed very unlikely to ever see multiple ways to do "one thing". The Python community has since matured and realised that what they previously thought of as "one thing" were actually multiple different things with small nuances and it makes sense to support several of them…

One way to do the things. That's why there's 5000 ways to install a module.

And 4900 "wrong ways" that will hurt you one way or another
Post reply on HN