On Tue, Jun 10, 2014 at 4:03 PM, Markus Schaber <m.scha...@codesys.com> wrote:
> Hi, Jeff, > > Von: Jeff Hardy > > On Tue, Jun 3, 2014 at 1:39 PM, Doug Blank <doug.bl...@gmail.com> wrote: > >> 2) A pure-Python version would be a lot of work (perhaps building on > PyPy's RPython version and converting their C) and be slow, but would be > little maintenance as most of the details for the current version of numpy > would be static. Requires generic Python skills to develop (a large group > of people have these skills; any generic Python implementation could use). > > > Anything that we can share with the PyPy/Jython teams will be a huge > advantage. Having a pure-Python implementation would at least allow it to > work, even if it wouldn't be fast (except on PyPy). It might also be a huge > amount of work, but if it's shared between three smallish communities it > might not be too bad. > > I think one of the problems is to avoid the boxing of doubles to objects > when they're stored in arrays / vectors. > That's an improvement I would like to see in general. I think IP tries to do that sometimes, but not in the general case. It should be possible for range(10) to return a IList<int> and have it be transparently switched to a IList<object> is something else is added. PyPy does something similar, assuming lists (and dicts IIRC) are homogeneous until proven otherwise. Or maybe it's a case of having the algorithms in Python and the data structures in C#. > > > I just don't know enough about the architecture of numpy to say for sure > - which parts are Python, which are Cython, and which are hand-written > CPython modules. If they're going to depend on Cython, it's worth investing > in a C# backend for that (unless we can generate cross-platform C++, but > .NET Native might make that irrelevant anyway). It would also enable the > wonderful Pandas library, hopefully. Getting an idea from the numpy team > where they're headed would be a good idea before investing too much work in > any case. > > As far as I can see, IronPython is JITted after being translated by the > DLR. Maybe we could enhance that process to involve some type inference > (similar to RPython) where possible, and to use Cython style type hints. > > With the appropriate type mappings (and possibly some hints), this could > allow an "pure" Python version to get full .NET speed (e. G. by using .NET > arrays of .NET double instead of python arrays). > That's what I'd prefer to see as well. It's more engineering work but I think the payoff would be bigger in general. It also allows to start with a slow-but-API-compatible Python version and increase performance later. Still, I'm just providing my opinion - I don't have the time to work on this directly, so the final decision will come down to whoever does the actual work. - Jeff
_______________________________________________ Ironpython-users mailing list Ironpython-users@python.org https://mail.python.org/mailman/listinfo/ironpython-users
