Python IS slow ! [was] Re: Python too slow for real world

[Markus Kohler]

>>>>> "William" == William Tanksley <wtanksle at dolphin.openprojects.net> writes:

[deletia]
    >> Agreed. The main problem with todays statically typed languages
    >> is that they are too restrictive and to complicated.

    William> I'm not sure that they're _too_ restrictive; they work in
    William> their domains.  The problem is that we don't want to
    William> loose Python's greatest strength: it's friendly.

    William> Let me expand a little on the dangers of C++.

    William> - virtual functions.  It shouldn't be my job to tell the
    William> compiler when virtual lookups are the only thing to do;
    William> the compiler ought to be able to tell.  For performance
    William> gurus, a way to hint to the compiler that virtual lookups
    William> were _not_ needed might be useful -- but what if the
    William> programmer was wrong?

    >> True, SmallEiffel inlines most of the virtual function calls
    >> automatically.  This is the way to go.

    William> Inlines virtual functions?  I think you got your wires
    William> crossed ;-).  Virtual functions, by definition, can't be
    William> inlined.  Inlining is where you place the routine's
    William> source code directly into the code of the calling
    William> routine.

No I'm serious. Even most C++ compilers cannot inline virtual functions,
 that doesn't mean it is not possible ;-)

A virtual function call can be inlined if you know all subtypes of a type:

Assume you have a class "A" and classes "AA" and "AB" that are subclasses of 
A. 

Given

       A  thing;
       thing = createFromFactory();/* it's not known here at compile whether thing is
				   of type A, AA or AB */
       thing.doSomething();

Then the a call A.doSomething() can be inlined ( translated to pseudo-C (tm)). 

       A thing
       thing = createFromFactory();
       
       if (thing.type)==AA
	{
	  doSomething__AA(thing);
	}
	elseif (thing.type)==AC
	{
	   doSomething__AB(thing);
	}
	elseif (thing.type)==A
	{
	   doSomething__A(thing);
	}
	else
	{
	  performHashBasedSlowCall(thing, doSomething)
	}


Nobody says that one has to use vtables like C++ does ;-)

SmallEiffel does exactly this. They used have a paper about their technique
on their web side: http://SmallEiffel.loria.fr/index.html

Self a smalltalk successor did the same without static type information
years ago : http://self.smli.com/
Sun's new HotSpot Java compiler is based on this technology. 

Another way to speed up calling polymorphic functions is to use 
a cache of the latest (or the first) type together with the functions called for
this type. This works very well for Smalltalk and should be a good thing in python too. 

    William> - GC -- hard to add after the fact.  No worry with
    William> Python, but what if there are other issues like it?

    >> I'm not sure if I understand this sentence. Do you mean GC is
    >> hard to add to python without breaking existing code ?  I would
    >> agree with that. And why do you say "no worry" Do you mean GC
    >> is not worth the effort ?

    William> Guido seems to think so.  Anyone who disagrees is free to
    William> contribute and work on porting GC code (I would like to
    William> see it).


    William> I think that worrying about the other issues is FAR more
    William> rewarding -- RC is not only hard to replace with GC, but
    William> the rewards for doing so are relatively small (in
    William> comparison to the other things we can think about).

I would guess it's a lot of work to replace the RC with a GC, because a good
GC needs a way to know if something is a pointer or not and this would require
changing object layouts. Also all the reference counting calls would need to be
removed. OK it might be possible to replace this code with macros that just do nothing. 

But the main problem would be that a lot of  external (C) code would break with a decent GC 
because the GC would move objects around at runtime. 

    William> I don't want to stop anyone from trying, though.  The
    William> nice thing about free software is that even if everyone
    William> disagrees with you or thinks it's not worth it you can
    William> still get it done.

    William> So what other issues are worth thinking about?  I don't
    William> know.

    >> You may have a look at Strongtalk a Smalltalk with static
    >> (optional) type checking.

    William> Found it using Google.com (a GOOD search engine for
    William> technical matters).
    William> http://java.sun.com/people/gbracha/nwst.html

    William> I'll be spending some time reading it.  My initial
    William> impression: _very_ good.  This would fit well, I think.

Nice to hear that ... 	


Markus
-- 
Markus Kohler  mailto:markus_kohler at hp.com