10:55 <lukakovacic> Hello

10:56 <lukakovacic> I have a question regarding the potential use of the Python 3 typing module in PyPy JIT or perhaps even RPython

10:57 <lukakovacic> Would it be possible to use type hints to "speed up" the interpreter?

10:58 <lukakovacic> or even skip the interpreter completely (using RPython)?

11:01 <lukakovacic> I am aware of https://typing.readthedocs.io/en/latest/source/typing_anti_pitch.html

11:02 <lukakovacic> and I know that the CPython runtime does not enforce the type annotations

11:05 <nimaje> they are hints, if they are enforced you have some other language, not python

11:08 <lukakovacic> The question is really: Is it possible to find some middle ground between Python being a dynamically typed language and a statically typed language, by using types, where you want to? In the sense that you would not need to do any runtime checking inside a function, which is "fully statically typed"?

11:30 <nimaje> there was the idea to use those hints as a first guess in the jit, but no idea if anyone worked on it in any way

11:32 <lukakovacic> Yes, this is what I am thinking about, also PEP 484 mentions the potential for use in the JIT.

11:36 <nimaje> RPython is a statically typed language and came before python 3 and type hints, so it has its own way to tell the compiler types, afaik it is python 2, so no way to integrate the hints there; if/when RPython supports python 3, someone could think about integrating those hints in the other typing stuff RPython has

11:37 <xorAxAx> the PyPy jit doesnt need type hints to figure out the types

11:37 <xorAxAx> on the python level

11:38 <xorAxAx> but you can use jit hints i think

11:39 <lukakovacic> xorAxAx: do you think there could be a performance benefit from using these hints in the JIT (once implemented)?

11:45 <xorAxAx> lukakovacic: no need to implement them in the JIT, you can do it completely at application level

11:46 <xorAxAx> lukakovacic: by e.g. generating isinstance guards into the functions in an import hook

11:46 <xorAxAx> that will magically speed up certain types of python apps on pypy

11:47 <lukakovacic> so that is already an optimization done by the JIT?

11:47 <xorAxAx> its done automatically, yes

11:48 <xorAxAx> if you bring the type hints into code flow. i am not sure it would work automatically without the suggested transformation

11:50 <lukakovacic> yes, I was asking more about the possibility of improving the JIT to recognize these types, so an optimization could be made.

11:51 <lukakovacic> i am looking at how to improve python to utilize gruadual typing a bit more, if that makes sense

11:55 <lukakovacic> i understand that type hints themselves should not enforce a certain type (like isinstance would for example)

11:56 <xorAxAx> lukakovacic: note that the suggested transformation changes the semantics for the average program and would crash most programs with type annotations

11:56 <xorAxAx> for obvious reasons: type annotations without using mypy are often wrong

11:58 <lukakovacic> yes, I understand. Type hints must be hints

11:58 <lukakovacic> not enforced

11:59 <xorAxAx> thats automatically used already by the jit

11:59 <lukakovacic> but, what about using a decorator, which would tell RPython or the JIT that type hints should be enforced for a certain function?

11:59 <xorAxAx> thats not a pypy question but a python question

12:00 <xorAxAx> i.e. the decorator would change semantics on all interpreters (for good)

12:00 <lukakovacic> yes, I know this question is more for the Python implementation itself, but I am asking to see, whether this is viable at all

12:00 <xorAxAx> and speed up on pypy because of the introduced isinstance branch

12:01 <nimaje> xorAxAx: the question was about using the type hint as a first guess in the type analysis of the jit and as said, the idea was already there, but I don't know if anything further happend

12:06 <nimaje> but you don't want to pessimize, because the hint was completely wrong, so I expect it to be hard to integrate those hints in the jit

12:06 <xorAxAx> lukakovacic: its nearly trivial

12:06 <xorAxAx> nimaje: ah, thats probably harder to implement on the python level

12:07 <xorAxAx> not sure there are primitives in pypyjit to support that, maybe cfbolz knows

12:11 <nimaje> lukakovacic: ah, yeah, if you do a decorator, then adding assert isinstance(…) at the start of the function should help, not sure what to do with variables inside the function, but you can probably let the jit handle these itself

12:43 <lukakovacic> Thank you both. What I am aiming at is having the produced binary be as simple as possible, without too much runtime overhead, where it is not necessary. I will look further into RPython, it seems interesting.

13:24 <cfbolz> I think Cinder (meta's CPython fork) has a bunch of features like this

13:44 <xorAxAx> is it faster than pypy? :)

15:14 <cfbolz> clear "maybe"

15:14 <xorAxAx> hehe