According to this:
IronPython (Python for .Net) is faster than regular Python (cPython) on the same machine. Why is this? I would think compiled C code would always be faster than the equivalent CLI bytecode.
+26
A:
Python code doesn't get compiled to C, Python itself is written in C and interprets Python bytecode. CIL gets compiled to machine code, which is why you see better performance when using IronPython.
Cody Brocious
2009-02-02 20:23:27
u r super fast <bravo>
01
2009-02-02 20:23:57
+2
A:
Could it be explained by this notation on the page you linked to:
Due to site caching in the Dynamic Language Runtime, IronPython performs better with more PyStone passes than the default value
Abtin Forouzandeh
2009-02-02 20:26:06
Without knowing what site caching is (a very complex concept only really explained in a video series on Channel9), this tells you nothing. In addition, IPy1 (which was pre-DLR) also had better performance than CPython. It all comes down to CIL compilation.
Cody Brocious
2009-02-02 20:27:39
+6
A:
You're right, C is a lot faster. That's why in those results CPython is twice as fast when it comes to dictionaries, which are almost pure C. On the other hand, Python code is not compiled, it's interpreted. Function calls in CPython are terribly slow. But on the other hand:
TryRaiseExcept: +4478.9%
Now, there's where IronPython get is horribly wrong.
And then, there is this PyPy project, with one of the objectives being Just-In-Time compiler. There is even subset of Python, called RPython (Reduced Python) which can be statically compiled. Which of course is a lot faster.
vartec
2009-02-03 12:49:08
I've always wondered why RPython hasn't been promoted more. It's sufficiently dynamic to be useful, yet very speedy. If there was more documentation for it I'd surely use it.
Daishiman
2009-03-07 00:31:03
The PyPy team don't really want to encourage people to use RPython. They see it as an implementation detail of PyPy - it changes all the time, has poor documentation and terrible error reporting. They are concentrating on making the PyPy JIT fast enough that you don't *need* to use RPython to get speed...
fuzzyman
2009-10-05 14:27:58
+3
A:
I'm not sure exactly how you're drawing the conclusion that IronPython is faster than CPython. The link that you post seems to indicate that they're good at different things (like exceptions as has been pointed out).
Jason Baker
2009-03-07 00:21:05
+2
A:
Wandering off your question "Why?", to "Oh, really?" The "good at different things" (Jason Baker) is right on. For example, cpython beats IronPython hands down start up time.
c:\Python26\python.exe Hello.py
c:\IronPython\ipy.exe Hello.py
Cpython executes a basic hello world nearly instantly(<100ms), where IronPython has an startup overhead of 4 or 5 seconds. This annoys me, but not enough to keep me from using IronPython.
Precipitous
2009-05-06 17:59:51
That's not an advantage of CPython over IronPython for themselves. The 4 or 5 sconds are the startup time of the CLR, not of IronPython.
Rafa Castaneda
2010-03-10 20:26:15
It doesn't matter why it takes 4 or 5 seconds more to start up. It's faster once its running (partly do to the CLR) but slower to start (partly due to the CLR). Performance considerations have significance based on user impact. If the use case for a scripting language is many small scripts, this is a severe drawback.
Precipitous
2010-03-18 04:09:54
+1
A:
Ironpython is faster for certain types of operations, but slower on others. Overall, it is still a little bit slower on average.
Luis
2010-03-15 21:54:45