Take the 2-minute tour ×
Stack Overflow is a question and answer site for professional and enthusiast programmers. It's 100% free, no registration required.

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]))
share|improve this question
    
Related Q on numpy/scipy support: stackoverflow.com/questions/12948061/… –  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 5:55

1 Answer 1

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.

share|improve this answer
    
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, 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 5:43
    
I'm pretty sure the the link I was using was 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

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.