[IronPython] 2 Basic question about IronPython and dyn. langs in general

Matthew Barnard m.stephen.barnard at gmail.com
Wed May 14 20:47:36 CEST 2008


First, I would like to ask anyone with more experience than myself (which is
not much) to comment on the validity of this test.
I'm sure there are multitudes of differences I am not aware of that would
make these results misleading.

2) IronPython Studio does indeed compile ipy code to MSIL, though I'm not
clear on how.
The executable generated by IPy Studio contains MUCH more code than the C#
exe.

Comparing a for loop between IPy and C# leads me to the following:
Because python's for loops are actually foreach loops (for i in list), I am
using a foreach loop in C# as well.
Also, because C# has no native type akin to a python list (list resembles a
List<> more than anything),
I am using List<int> for both, and iterating through it. I have initialized
each List<> outside of the test() method
and added [0,1] to both.

static void test()
{
    foreach (int i in lst)
    {
    }
}

def test():
    for i in lst:
        pass

The MSIL for the C# can be seen at
http://www.nomorepasting.com/getpaste.php?pasteid=15742&seen=true&numbered=on
and the MSIL for the IPy can be seen at
http://www.nomorepasting.com/getpaste.php?pasteid=15741&seen=true&numbered=on
both showing instructions only and with proper wrapping.

Counting instructions only, the IPy generated 14 instructions more than the
C# in order to achieve what, in a practical situation (as in, how you would
actually use each), is the same code.

Looking at the bigger picture, however, the difference in generated bytecode
between the C# application and the IPy application is VAST. Again, in a
practical sense, both are written in the same manner. That is, if you were
to write two applications to accomplish the same task, this is typically how
it would be accomplished. It is clear to see that the standard bare-bones C#
application produces far less bytecode than the standard bare-bones IPy
application.

Please, correct me if I'm wrong. This is the extent of my knowledge.




On Wed, May 14, 2008 at 8:56 AM, Ben Hall <ben2004uk at googlemail.com> wrote:

> I'll try to do my best to answer this.
>
> 1) Because a large is dynamically typed, doesn't mean you can't do any
> verification on the code. Michael Foord told me about PyFlakes
> (http://divmod.org/projects/pyflakes) and PyLint
> (http://pypi.python.org/pypi/pylint) which can do static analysis on
> the code to identity protential problems.
>
> 2) If by native code you mean something like C++, then I expect so.
> Most languages are slower than C++,  and it comes down to CPU cycles
> vs Developer Cycles. I'm sure developers are much more productive in
> Python than C++.  Guess it depends on your application, but Python is
> running on lots of high performance systems so I don't really think
> its a problem.
>
> 3) Not sure if I understand your question. You can compile Python into
> bytecode.  Compiled Python code are .pyc,
>
> http://www.network-theory.co.uk/docs/pytut/CompiledPythonfiles.html
>
> In 1.0, there was a sample of how to do this:
>
> http://www.codeplex.com/Release/ProjectReleases.aspx?ProjectName=IronPython&ReleaseId=423
>
> However, at the moment this is not supported in 2.0
> (
> http://lists.whatwg.org/pipermail/users-ironpython.com/2008-February/006507.html
> )
>
> Ben
>
>
>
> On Wed, May 14, 2008 at 4:13 PM, Ben Aurel <ben.aurel at gmail.com> wrote:
> > hi
> > I have two questions on two different subject but anyhow connected. Also
> I
> > have to admit that I could probably find the answers myself. But I'm
> quite
> > new to all that things and I have a lot to catch up to...
> >
> > If I understand correctly the are 2 main advantages when it comes to
> dynamic
> > languages:
> > + Objects doesn't have to be typed be the developer
> >   (saves time, makes code shorter and better readable code)
> > + Code is interpreted
> >   (no compilation step during development, source dont have to be
> compiled
> > for the target machines before deployment)
> >
> > which implies the 2 following disadvantages
> > - Writing a lot of tests to catch potential runtime errors (no compile
> time)
> > - Slower than native code
> >
> > Questions:
> >
> > 1. Why belong the terms "untyped" and "interpreted" somehow together? Why
> > can't the type inference that has to be done at runtime  not be done at
> > compiletime. I think the runtime interpreter has to compile the python
> > bytecode to native code somehow - no?
> > Why isn't there a possibility to *compile* python/ruby/perl/... code to
> > native code at the first place?
> >
> > 2. I've read about, that it is possible to compile Python Code to msil
> with
> > IronPython. Unfortunately I'm not yet at the point where this run on my
> > machine (macosx). So I do have to ask you: Is such a dll/exe the same as
> I
> > would compile it from c#? Does similar language constructs (eg. for loop,
> > class object creation) the same performance?
> >
> > Thanks in advance.
> > Ben
> >
> >
> >
> > One of the list members - Ben Hall - pointed me at one of his blog posts
> > [1].
> >
> >
> >
> >
> >
> >
> http://blog.benhall.me.uk/2008/05/ironpython-classes-within-separate.html
> >
> > _______________________________________________
> > Users mailing list
> > Users at lists.ironpython.com
> > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> >
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>



-- 
___________________________
Matthew Barnard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20080514/d884eec1/attachment.html>


More information about the Ironpython-users mailing list