Next steps in PyPy investigations
pierre-yves.david at ens-lyon.org
Thu Feb 11 20:33:22 EST 2016
On 02/11/2016 09:36 PM, Sean Farley wrote:
> Bryan O'Sullivan <bos at serpentine.com> writes:
>> On Thu, Feb 11, 2016 at 7:30 AM, Laurent Charignon <lcharignon at fb.com>
>>> I didn't really follow the discussions around pypy, when are we planning
>>> to support pypy?
>> Pierre-Yves has agreed with the PyPy development team on a contract, funded
>> by Facebook, to perform some more work on PyPy and Mercurial.
>> The scope to begin with is quite narrow:
>> Get the Mercurial test suite completely passing. A handful of
>> revset-related tests require some fixes to some bad assumptions that the
>> revset machinery makes.
>> See what easyish optimizations can be added or improved to further speed up
>> the performance of some core Mercurial commands. This may involve porting
>> some C extensions to work with cffi, which will imminently force us to
>> think harder about the question of C data structures.
>> Look at how to reduce or otherwise make invisible the PyPy JIT startup and
>> warmup time. Now that chg is about to arrive in core Mercurial, that will
>> presumably be the most obvious path to follow.
> This is all really, really awesome. Yuya demoed an example of this at
> the London sprint but warned that the forking model would need to be
> different. Do you think that will be hard to accomplish this go-round?
One of the idea currently in the air is to allow forks to share the
The chg server can "affort" to disable demande import and load all the
code upfront. From there, all working forks from this server will share
the same "code" object and could "easily" share Tracing/Jit data.
But to be more honest, this is a fairly complicated issue and this is
exactly why we are planning to pay domain expert to spend time coming
with serious proposal on this matters.
More information about the Mercurial-devel