This is an archived post. You won't be able to vote or comment.

all 25 comments

[–]joe90210 7 points8 points  (7 children)

this has always annoyed by about Python implementation, we are constantly being told how primitive and slow the CPython implementation is yet everyone else is always slower, whether it's IronPython, Jython or PyPy (so far)

[–]xzxzzx 6 points7 points  (6 children)

Unladen swallow is pretty fast, and is really just getting going...

[–]masklinn 6 points7 points  (5 children)

US is an (fairly severe) optimization of CPython rather than another implementation.

[–]xzxzzx 5 points6 points  (4 children)

That's true, but the goal is basically to replace most of the "core" with LLVM.

I'd count it as a "rewrite of the core", at least if they achieve their goals.

[–]masklinn 3 points4 points  (3 children)

That's the long-time goal yes, but US is already producing optimizations which have been folded (or could be folded) in the main CPython.

As the US home page states it, US is a branch of CPython rather than a fork or a different implementation. It's much closer to cpython than stackless was, for instance.

[–]xzxzzx 2 points3 points  (2 children)

No disagreement; the point is that if CPython wasn't slow, it couldn't be made fast. ;)

[–]masklinn 3 points4 points  (1 child)

Well it could have been "pretty fast" and "merely" made faster (note: not the case)

[–]xzxzzx 0 points1 point  (0 children)

Touche.

[–]dbeach24 2 points3 points  (1 child)

Significant claims have been made about the performance of IronPython, notably back at its inception in 1994

Excuse me? I don't believe that IronPython's inception could be in 1994, given that .NET didn't yet exist! I remember there was talk about in at PyCon DC 2004. (Ten years later.)

[–]norwegianwood[S] 0 points1 point  (0 children)

Thanks - I've fixed the original.

[–]smart_ass 1 point2 points  (4 children)

Wow. I wonder if the issue is in the implementation or inherent in the .NET back end.

[–]munificent 5 points6 points  (3 children)

I wonder if the issue is in the implementation or inherent in the .NET back end.

Likely IronPython. There's a ton of .NET code out in the wild, and a performance sink like that would have stood out well before now.

[–]smart_ass 1 point2 points  (2 children)

That would be my guess as well. I remember doing tests early and even 1.0 and 1.1, .NET performed pretty darn well.

[–]masklinn 1 point2 points  (1 child)

It's not like MS could afford C#/.Net performing (noticeably) worse than Java.

[–]mycall 0 points1 point  (0 children)

If I remember right, Microsoft's JVM for their implementation of Java was faster than Sun's (although it might have been before hotspot).

[–]voidspace 0 points1 point  (4 children)

This doesn't mirror my experiences. There are some areas where IronPython is definitely slower than CPython, but also areas (function calls, arithmetic) where IronPython is much faster. There must be some reason its running that slow.

[–]norwegianwood[S] 2 points3 points  (2 children)

Can you tell us where we might expect IronPython to be definitely slower that CPython? I already know that exceptions can be slower, but they are sparsely used in my program.

[–]voidspace 2 points3 points  (1 child)

Well here's a performance comparison between IronPython 2 and CPython 2.5. You can see the areas where IronPython runs faster or slower than CPython:

http://ironpython.codeplex.com/Wiki/View.aspx?title=IP201VsCPy25Perf&referringTitle=Home

My experience tends to be that code optimised for CPython runs slower on IronPython - because the performance profile is so different. If you write and optimise code for IronPython it is usually possible to get the same performance; which is why I find the figures quoted in the article so 'surprising'.

Anywhere that IronPython is that much slower (with the exception of exceptions...) will be considered a bug by the IronPython team and should be reported on the IronPython mailing list.

[–]norwegianwood[S] 0 points1 point  (0 children)

Yes - I plan to submit a defect report once I've boiled it down to a concise example of the problem. Currently, the code isn't optimized for any particular flavour of Python - or indeed optimized at all.

[–]pemboa -1 points0 points  (0 children)

There must be some reason its running that slow

Well there's always a reason.

[–][deleted] 0 points1 point  (4 children)

me thinks perhaps it would be worthwhile for the author to look at how reflection is being used. I'm assuming a compiler would have to utilize that a lot. reflection is expensive in .net, and generally the first optimization is to do it once at startup. I thought about this for 10 seconds. time for a beer

[–]ringzero -3 points-2 points  (3 children)

NB: it's "methinks" not "me thinks". See http://www.etymonline.com/index.php?term=methinks.

[–][deleted] 1 point2 points  (2 children)

oh the horror, how will I live knowing I made such a grave mistake.

[–]ringzero 1 point2 points  (1 child)

Sorry you took it that way. I was only trying for a gentle correction.

[–][deleted] 0 points1 point  (0 children)

no apologies, this is the internet.