2

I have some Python source code that manipulates lists of lists of numbers (say about 10,000 floating point numbers) and does various calculations on these numbers, including a lot of numpy.linalg.norm for example.

Run time had not been an issue until we recently started using this code from a C# UI (running this Python code from C# via IronPython). I extracted a set of function calls (doing things as described in the 1st paragraph) and found that this code takes about 4x longer to run in IronPython compared to Python 2.7 (and this is after excluding the startup/setup time in C#/IronPython). I'm using a C# stopwatch around the repeated IronPython calls from C# and using the timeit module around an execfile in Python 2.7 (so the Python time results include more operation like loading the file, creating the objects, ... whereas the C# doesn't). The former requires about 4.0 seconds while the latter takes about 0.9 seconds.

Would you expect this kind of difference? Any ideas how I might resolve this issue? Other comments?

Edit:

Here is a simple example of code that runs about 10x slower on IronPython on my machine (4 seconds in Python 2.7 and 40 seconds in IronPython):

n = 700
for i in range(n-1):
    for j in range(i, n):
        dist = np.linalg.norm(np.array([i, i, i]) - np.array([j, j, j]))
denfromufa
  • 5,610
  • 13
  • 81
  • 138
Mat
  • 275
  • 3
  • 12
  • Related Q on numpy/scipy support: http://stackoverflow.com/questions/12948061/the-definitive-method-to-use-numpy-and-scipy-from-ironpython – ivan_pozdeev Nov 10 '14 at 22:31
  • This may help on both platforms a bit, consider using `xrange` instead of `range` – Pawel Jasinski Nov 11 '14 at 05:55
  • the way to work with numpy and .NET at the same time is to use python.net bridge betweeb CPython and .NET, hence I updated tags. – denfromufa Sep 12 '15 at 00:04

1 Answers1

4

You're using NUMPY?! You're lucky it works in IronPython at all! The support is being added literally as we speak!

To be exact, there's a CPython-extension-to-IronPython interface project and there's a native CLR port or numpy. I dunno which one you're using but both ways are orders of magnitude slower that working with the C version in CPython.

UPDATE:

The Scipy for IronPython port by Enthought that you're apparently using looks abandoned: last commits in the repos linked are a few years old and it's missing from http://www.scipy.org/install.html, too. Judging by the article, it was a partial port with interface in .NET and core in C linked with a custom interface. The previous paragraph stands for it, too.

Using the information from Faster alternatives to numpy.argmax/argmin which is slow , you may get some speedup if you limit data passing back and forth between the CLR and the C core.

Community
  • 1
  • 1
ivan_pozdeev
  • 33,874
  • 19
  • 107
  • 152
  • In the example above, yes that was using numpy=np. When I downloaded IronPython (~March 2014) the link included numpy and I thought it was supported then. However, I tried had another test which just operates on some lists (no numpy) and it runs about 6x slower in IronPython: averages about 2.5 seconds in Python2.7 and 15 seconds in IronPython, but I think I heard this was to be expected for list operations. – Mat Nov 10 '14 at 22:18
  • There have been a whole bunch of efforts in that direction. Could you update the question with what exact flavor of "supported numpy" you use? – ivan_pozdeev Nov 10 '14 at 22:30
  • I'm not sure exactly. numpy.version.version gives 2.0.0 and I _think_ I downloaded it from enthought.com, again maybe March 2014 or so. – Mat Nov 10 '14 at 22:38
  • Hmm, https://enthought.com/products/canopy/package-index/ doesn't mention anything about IronPython. Didn't you confuse it with IPython? – ivan_pozdeev Nov 11 '14 at 05:43
  • I'm pretty sure the the link I was using was https://www.enthought.com/repo/.iron/ which is no longer there, I do remember that it disappeared a couple months after I downloaded it. – Mat Nov 12 '14 at 14:09
  • See the update. It's because of this, I cannot understand the big idea behind porting `numpy` to CLR. A VM is by definition times slower and fatter than native code, and `numpy` is all about performance and memory efficiency. – ivan_pozdeev Nov 12 '14 at 14:53
  • try pythonnet with numpy – denfromufa Sep 12 '15 at 00:05