Hi Haael, Cool that you want to work on PyPy!
haael <ha...@interia.pl> wrote: >> >> Why would it reduce the size of the binary? > > >That is my poor understanding, I might be wrong. > >In the current approach in a binary there is a compiled machine code, >the flow >graph representation and the JIT compiler. I think we could get rid of >(most) >compiled machine code, leaving only some startup code to spawn the JIT >compiler. Then, each code path would be compiled by JIT and executed. >Loops >would run as fast as usual. Non-loop code would run slower, but I think >this >would be a minor slowdown. Most importantly, as I understand, the >binary >contains many versions of the same code paths specialized for different >types. >If we throw it out, the binary would be smaller. > >This is not a proposal. It is just a try at understanding things. > Will just reply to this part, typing on the phone is annoying. What you write above is actually a good proposal. We have discussed the viability of related schemes in the past. There are two problem that I see with it. 1. While the speed of your proposed system would eventually be the same, it would suffer from much slower warmup, because after startup you would have to generate a lot of machine code before executing the user's code. 2. More fundamentally (and this is where I think you have missed a detail about the JIT so far) the JIT ist trace-based. The JIT backends cannot deal with arbitrary control flow, only with linear traces. Therefore it would not be straightforward to use the same JIT backends to bootstrap parts of the interpreter as runtime. As for tasks you could work on: would you maybe because interested in helping with the ARM JIT backend? Cheers, Carl Friedrich _______________________________________________ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev
