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

Charles Mason cemasoniv at gmail.com
Wed May 14 22:18:27 CEST 2008


I think the reason for the size increase (like Dino mentioned) is to handle
the dynamicity of the language.

"for i in lst" is not exactly foreach( int i in lst )

The equivelent code is something more along the lines of:

iterator = lst.__iter__()
while (i = iterator.next()) doesn't raise exception StopIteration:
   use i

There's probably other checks that go on to make sure the iterator returned
is proper and all that.

C

On Wed, May 14, 2008 at 2:47 PM, Matthew Barnard <
m.stephen.barnard at gmail.com> wrote:

> 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
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20080514/146ab4cc/attachment.html>


More information about the Ironpython-users mailing list