Strongly-Typed Python
Daniel Leuck
Python. If someone were to create a strongly typed version of Python
would there be anything preventing compiled code from executing at
Java/C++ -like speeds?
Guido, have you ever considered designing a lower-level language,
perhaps as a compliment to Python, that incorporated the appropriate
Python concepts?
--
Daniel Leuck
d...@pretium.com
William Tanksley
>I would sure like to have a more systems-level language compliment to
>Python. If someone were to create a strongly typed version of Python
>would there be anything preventing compiled code from executing at
>Java/C++ -like speeds?
There are several such languages -- play with Oberon, Eiffel, and Smalltalk.
None of them are Perfect, of course, but they're decent.
>Guido, have you ever considered designing a lower-level language,
>perhaps as a compliment to Python, that incorporated the appropriate
>Python concepts?
Interesting thought. I'd rather (personally) just keep Python and make it
faster, but that might be even more effective. Doesn't really matter --
Guido won't do it. You might take a look at Ruby; it's got a small enough
installed base to perhaps handle the changes involved.
>Daniel Leuck
--
-William "Billy" Tanksley
"How could [Y2K] be a problem in a country where we have Intel and Microsoft?"
-Al "Forrest" Gore
Yukihiro Matsumoto
wtan...@tursiops.escher.ml.org (William Tanksley) writes:
|Interesting thought. I'd rather (personally) just keep Python and make it
|faster, but that might be even more effective. Doesn't really matter --
|Guido won't do it. You might take a look at Ruby; it's got a small enough
|installed base to perhaps handle the changes involved.
Although the fact about far smaller install base comparing Python, I
don't believe Ruby to be fully strongly typed language in the future.
It's too drastic change to the used-by-handreds language. Maybe
optional type system like Lisp can be added to the language.
As for performance, Ruby tends to be 20 to 60% faster than Python most
of the case, mostly because its method cache. But Python has its
plenty library resources. Recently, we, Ruby folks developed
Ruby/Python extension to handle Python within Ruby, so that we can
steal -- well, utilize -- Python's library.
matz.
Evan Simpson
>On Sun, 17 Jan 1999 15:06:02 -1000, Daniel Leuck wrote:
>>I would sure like to have a more systems-level language compliment to
>>Python. If someone were to create a strongly typed version of Python
>>would there be anything preventing compiled code from executing at
>>Java/C++ -like speeds?
>
>>perhaps as a compliment to Python, that incorporated the appropriate
>>Python concepts?
>
>faster, but that might be even more effective. Doesn't really matter --
>Guido won't do it. You might take a look at Ruby; it's got a small enough
>installed base to perhaps handle the changes involved.
If I'm reading Daniel right, he's not suggesting doing away with or changing
Python in any way, nor is he interested in the existence of other nice
high-level optimizable languages. I'll specify what I've been dreaming of,
since I think it is somewhere in the general vicinity of what Daniel's
wishes:
1. I like Python's syntax and built-in data structures. A *lot*. Having
to write, read, or modify extensions written in C is painful. If the
extension is new code, not a link to existing code, it's positively
agonizing!
2. A great deal of what one does in an extension involves calls back into
Python's function libraries to manipulate, pack, and unpack Python data
structures. The remainder could often be expressed perfectly well in Python
itself, except that it would unnecessarily invoke the power, flexibility,
and overhead of the interpreter and object system for simple integer and
floating point calculations, C calls, and small loops.
3. There is a rather amorphous sentiment in the community that Python could
be made faster and better if we could just introduce stronger typing or
better type inference, or some such thing. This may be true, but I feel
that it the sort of thing that William was objecting to, and properly so.
Invisible performance enhancements, such as tweaking of the VM and
interpreter loop, is great, but even totally optional "pragma"-style
performance hints risk complicating Python in ways that obscure its
strengths.
4. Perhaps a separate-yet-complementary language could be valuable.
Something analagous to the Java/JavaScript pairing (though I suppose JPython
already has this, in a sense!). A language which looks and feels a lot like
Python, which can use Python objects directly by internally using the Python
API, but which can also use C-style data-structures and function libraries.
A glue language for the glue language.
I think that several other folks have approached this idea from various
directions. Chris Tismer(?I think?) spoke of generating the C code for
Python itself in Python, with a suitable code-generation module. With
careful design, I imagine, this Python-helper language could specify macros,
templates, and actual algorithms, all of which would be converted into C and
then compiled into an extension (or into Python itself!). Many of the
advantages of C++ over C might be gained, while chucking the bad parts of
both.
This may not appeal to those of you comfortable with C (including Guido, I
guess :-/), but for folks like myself who are only read/write with
Pascal/Delphi-style low-level languages, I think this would be a Godsend.
Mmmm... Python-helper
Evan Simpson
Daniel Leuck
a distinct lower level language that preserves as much of the flexibility of
Python as possible and serves as a nice complement to Python. The Java - JPython
mixture is great but Java's syntax and approach is quite disparate from that of
Python's in many regards. Java doesn't support pythonesque features such as
mutliple return values, keyword arguments, etc.
> There are several such languages -- play with Oberon, Eiffel, and Smalltalk.
> None of them are Perfect, of course, but they're decent.
I am aware of all the popular OO languages (but thank you anyway).
--
Daniel Leuck
d...@pretium.com
Jonathan Riehl
kind of optimizations and translations with Python. I don't know
when they'll put the conference proceedings on the website, but there
was a great deal of material presented on both static typing, and
translation of Python to C. Keep checking the website for the
papers...
I was working on one translator for Python to C, but I found out
I was one of three development efforts. I think Bill Tutt got further
along than I did before I had to hang up my guns. He is distributing
a translator, and moderates a mail list for his Python2C program.
(See http://www.pythonpros.com/maillists.html )
I know that Jim Hugunin also proposed static type extensions
for JPython, but has since worked on global type inference that
provides incredible speed ups without any type information at
all.
I think Guido (and he'll correct me if I am wrong) is taking
a wait and see approach, since the community may "grow"
typing extensions without him having to lift a finger (except to
wield his veto, if needed.)
-Jon
Evan Simpson wrote in message ...
>William Tanksley wrote in message ...
>>On Sun, 17 Jan 1999 15:06:02 -1000, Daniel Leuck wrote:
>>>I would sure like to have a more systems-level language compliment to
>>>Python. If someone were to create a strongly typed version of Python
>>>would there be anything preventing compiled code from executing at
>>>Java/C++ -like speeds?
>>
>>Interesting thought. I'd rather (personally) just keep Python and make it
>>faster, but that might be even more effective. Doesn't really matter --
>>Guido won't do it. You might take a look at Ruby; it's got a small enough
>>installed base to perhaps handle the changes involved.
>
>
>If I'm reading Daniel right, he's not suggesting doing away with or
changing
>Python in any way, nor is he interested in the existence of other nice
>high-level optimizable languages. I'll specify what I've been dreaming of,
>since I think it is somewhere in the general vicinity of what Daniel's
>wishes:
[deletia...]
Martijn Faassen
[discussion/wishlist for Python based lower level language snipped]
Hey, I've had some of the same ideas. I think Tim Peters or someone else
once called this idea (if I'm right) 'SPython', for 'static Python'.
Static Python would *not* be Python proper, it'd be a seperate but
related language.
I'll add one point to the wishlist. It was already implied, but it's
nice to spell it out:
* SPython should seamlessly integrate with Python proper. Python code
should be able to call SPython functions and methods seamlessly. The
other way around is more debatable, but the easier the better, of
course.
SPython would be far less dynamic than Python, but it would be possible
to do a relatively easy automatic translation of SPython code to
efficient C code. SPython would also miss quite a bit of Python
functionality. Added functionality would be some static typing.
Let's list a miss (as opposed to wish) list for SPython:
* Sequences are arrays of basic (C) types in SPython. They cannot
contain objects of a mixed type (no [1, "2", 3.0]), unless they're all
Python objects.
* SPython dictionaries are only indexable by string.
* class instances are constructed once and cannot be modified on the
fly. The structure of a class instance is determined by all assignments
to 'self.<something>' in the class definition (no matter if parts of
that code are actually never reached). Assignment of incompatible types
to the same variable is an error.
If we have Static Python, some of the need for static typing in Python
proper goes away. We tend to talk about how static typing in Python
proper allows us to optimize more, but Static Python would allow far
more optimization still, and it'd be far more easy as it's less dynamic.
The other reason for seperate typing is more robust/easy (possible
compile time) checking of function/method arguments, for large scale
projects. Interfaces might work for this.
Since this discussion probably also belongs on the types-sig, I'm
sending a copy there too.
Regards,
Martijn
Evan Simpson
> There are systems under development for performing these
>kind of optimizations and translations with Python. I don't know
>when they'll put the conference proceedings on the website, but there
>was a great deal of material presented on both static typing, and
>translation of Python to C. Keep checking the website for the
>papers...
> I was working on one translator for Python to C, but I found out
>I was one of three development efforts. I think Bill Tutt got further
>along than I did before I had to hang up my guns. He is distributing
>a translator, and moderates a mail list for his Python2C program.
>(See http://www.pythonpros.com/maillists.html )
D'oh! So I've "proposed" something that not only has work in progress, but
had *three* branches?? Is the Python2C mailing list the locale for
discussion of the systems you mention, or is there some more-general forum?
> I know that Jim Hugunin also proposed static type extensions
>for JPython, but has since worked on global type inference that
>provides incredible speed ups without any type information at
>all.
Nifty! I imagine SPython could take advantage of this work, and possibly
take it to the next level with restrictions on the allowable dynamics of
SPython data structures (eg. No namespace mutation, homogenous dicts and
seqs, etc).
Mmmm... type inference
Evan Simpson
Samuel A. Falvo II
>None of them are Perfect, of course, but they're decent.
I believe he's talking about a Python-like system level language, not a
Pascal, Dylan, or <god knows what>-like language, respectively.
For instance, in C, a typical message loop for AmigaOS will be:
done = FALSE;
while( !done )
{
sigsReceived = Wait( sigsWaitingFor );
if( sigsReceived & mySig_Window )
{
while( message = GetMsg( myWindow -> UserPort ) )
{
/* do something with message */
ReplyMsg( message );
}
}
}
Under a more Python-like language:
done = FALSE
while done == FALSE:
sigsReceived = Signals.Wait( sigsWaitingFor )
if sigsReceived and mySig_Window:
message = myWindow.GetMsg()
while message != none:
# do something with the message
# Hopefully this includes setting done to TRUE upon
# closing the window.
message.Reply()
message = myWindow.GetMsg()
>Guido won't do it. You might take a look at Ruby; it's got a small enough
>installed base to perhaps handle the changes involved.
And again, we're not talking about retrofitting Python to be used as a systems
level language. He's asking for a counter-part to Python -- that is, a whole
new language. With this in mind, Guido doesn't even need to do anything with
Python.
==========================================================================
KC5TJA/6 | -| TEAM DOLPHIN |-
DM13 | Samuel A. Falvo II
QRP-L #1447 | http://www.dolphin.openprojects.net:9673/
Oceanside, CA |......................................................
Christian Tismer
...
> I think that several other folks have approached this idea from various
> directions. Chris Tismer(?I think?) spoke of generating the C code for
> Python itself in Python, with a suitable code-generation module. With
> careful design, I imagine, this Python-helper language could specify macros,
> templates, and actual algorithms, all of which would be converted into C and
> then compiled into an extension (or into Python itself!). Many of the
> advantages of C++ over C might be gained, while chucking the bad parts of
> both.
Well, yes, I said that. I'm also thinking of a low-level interpreter
which can access the python API, from C's view, and let you build
extensions without involving a compiler at all.
On one hand, I want to lift the C language up to something more
expressive in terms of Python, less literate.
On the other hand, I want to break the static C source. Trying a new
construct which changes the basic Python structures is a nightmare
since you need to know all the dependencies. We need an abstraction
for that. I can't imagine anything better than Python structures
themselves for that.
The little problem is just - how do I do this the best?
> This may not appeal to those of you comfortable with C (including Guido, I
> guess :-/), but for folks like myself who are only read/write with
> Pascal/Delphi-style low-level languages, I think this would be a Godsend.
But who is the one to define that language?
I'm playing, but definately not the genius to invent that.
> A glue language for the glue language.
This sounds good. Very good.
--
Christian Tismer :^) <mailto:tis...@appliedbiometrics.com>
Applied Biometrics GmbH : Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101 : *Starship* http://starship.skyport.net
10553 Berlin : PGP key -> http://pgp.ai.mit.edu/
we're tired of banana software - shipped green, ripens at home
Evan Simpson
>Well, yes, I said that. I'm also thinking of a low-level interpreter
>which can access the python API, from C's view, and let you build
>extensions without involving a compiler at all.
Whoo. You mean a parallel interpreter loop, with different semantics on the
same/similar code, which gets control inside SPython code? Or something
else?
>On one hand, I want to lift the C language up to something more
>expressive in terms of Python, less literate.
>On the other hand, I want to break the static C source. Trying a new
>construct which changes the basic Python structures is a nightmare
>since you need to know all the dependencies. We need an abstraction
>for that. I can't imagine anything better than Python structures
>themselves for that.
>The little problem is just - how do I do this the best?
>
>But who is the one to define that language?
>I'm playing, but definately not the genius to invent that.
I've got ideas, but nowhere near enough knowlege or skills. Plus, my head
keeps exploding when I try to clarify my ideas. Still, there appear to be
folks trying (Python2C and some mysterious other systems).
Mmmm... blam!
Evan Simpson
Daniel Leuck
there are others who feel such a language would be of great utility and
that projects to develop such a language are already in full swing :-)
--
Daniel Leuck
d...@pretium.com
Christian Tismer
>
> From: Christian Tismer <tis...@appliedbiometrics.com>
>
> >Well, yes, I said that. I'm also thinking of a low-level interpreter
> >which can access the python API, from C's view, and let you build
> >extensions without involving a compiler at all.
>
> Whoo. You mean a parallel interpreter loop, with different semantics on the
> same/similar code, which gets control inside SPython code? Or something
> else?
Nearly, different, lemme tell you.
At the moment, I'm playing with an approach which is very low
level and might currently be much more difficult that
writing in C. I'm trying a machine which richt now has no idea
of Python objects at all. It knows only about machine words
and has a number of operations which it can perform. It has
of course access to the whole address space of the machine,
and it has access to every global symbol of the python exe
file. Therefore it is able to call any builtin function,
provided I tell it the correct parameters.
This is pretty much under construction. I still have not a
tenth of the instruction set ready. But I can of course
write Python modules which generate the simple code for
this simple machine and call it on demand.
The difficult thing is to get these Python classes
right, to make this easy to use.
As you can guess, I do think of generating C code in the future,
or maybe platform dependant machine code, but this is far away.
As long as I can keep with the little low level interpreter
which is machine independant, I have a better chance to
get users for this.
...
> I've got ideas, but nowhere near enough knowlege or skills. Plus, my head
> keeps exploding when I try to clarify my ideas. Still, there appear to be
> folks trying (Python2C and some mysterious other systems).
I have these explosions every day, and when it calms down, I try
to write something up quickly, in the hope it will stand
the next detonation.
Duck and cover - chris
Roberto Lupi
>Just to clarify - I wasn't suggesting changing Python. I was thinking in terms of
>a distinct lower level language that preserves as much of the flexibility of
>Python as possible and serves as a nice complement to Python. The Java - JPython
>mixture is great but Java's syntax and approach is quite disparate from that of
>Python's in many regards. Java doesn't support pythonesque features such as
>mutliple return values, keyword arguments, etc.
Lisp and Dylan do satisfy your requests.
BTW Has anyone developed a Lisp or Dylan binding for the Python API?
--
Roberto Lupi
Bryan VanDeVen
> I was working on one translator for Python to C, but I found out
> I was one of three development efforts. I think Bill Tutt got further
> along than I did before I had to hang up my guns.
Why? Did those punks at NASA make you stop? ;)
--
Bryan Ven de Ven
Applied Research Labs
Martijn Faassen
>
> Thank you for all of the valuable information. It is great to hear that
> there are others who feel such a language would be of great utility and
> that projects to develop such a language are already in full swing :-)
Hm, there should be somekind of summary of these efforts, and what
exactly they try to do. Some seem to be more optimization directed,
others want to introduce compile time typechecking and interfaces, yet
others want to do both. Some translate Python to C, others are more
focused on optimizing the current Python implementations, or are
implementing new virtual machine backends. One hears exciting rumors
about type inferencing and the resultant mega optimizations. One hears
about a hypothetical seperate SPython language that people might
actually be working on.
There should be a list of who is trying to do what and what info is
available where. Multiple projects is fine, as different people have
different ideas sometimes, but reinventing the wheel isn't everything
either. Besides, I'm curious. I want to know what's going on. :)
Perhaps a topic guide is in order. If someone at python.org gives me the
go ahead I'm willing to volunteer (uh oh). That is, I'll collect the
various information on who is doing what, where, and how (currently I
know little :) I'll try to whip up a topic guide for www.python.org.
*comes back from reading 'http://www.python.org/topics/#producing'* Ah.
I'll cc this to webm...@python.org, then, to see what they think. To
repeat my warning, I'm an interested bystander right now. I currently
know fairly little about the internals of the Python interpreter. If
someone else wants to volunteer who knows more than I do, I'll gladly
step aside.
I suppose this should be called the 'Compiler/Interpreter Hacking' topic
guide. :)
Regards,
Martijn
Hisao Suzuki
Yukihiro Matsumoto <ma...@netlab.co.jp> writes:
[snip]
> As for performance, Ruby tends to be 20 to 60% faster than Python most
> of the case, mostly because its method cache. But Python has its
Really?
Method caching is possible in the current version of Python, if
you dare do it explicitly, but it seems to help only a little,
actually. For example:
% cat sum1.py
class Foo:
def __init__(self):
pass
def calc(self, n):
if n == 0: return 1
else: return n + self.calc(n - 1)
def test():
a = Foo()
for i in xrange(1000): a.calc(i)
test()
% time python sum1.py
python sum1.py 10.05s user 0.24s system 99% cpu 10.298 total
%
% cat sum2.py
class Foo:
def __init__(self):
self.calc = self.calc # cache the method into self
def calc(self, n):
if n == 0: return 1
else: return n + self.calc(n - 1)
def test():
a = Foo()
for i in xrange(1000): a.calc(i)
test()
% time python sum2.py
python sum2.py 8.88s user 0.26s system 100% cpu 9.100 total
%
--
SUZUKI Hisao >>> def fib(n): return reduce(lambda x, y:
suz...@otsl.oki.co.jp ... [x[0] + x[1]] + x, [None]*n, [1L, 1L])
Yukihiro Matsumoto
Hisao Suzuki <suz...@otsl.oki.co.jp> writes:
|> As for performance, Ruby tends to be 20 to 60% faster than Python most
|> of the case, mostly because its method cache. But Python has its
|Really?
Well.. faster, yes. Mostly because of method cache, maybe, maybe not.
I didn't profile Python at all. I'm not sure about the reason. The
method cache is the reason I thought of first to explain performance.
|Method caching is possible in the current version of Python, if
|you dare do it explicitly, but it seems to help only a little,
|actually.
It depends on situation. I agree with explicit method cache did not
help your sample code, but it can help other's code sometimes. IMO,
saving method in local variable, which is not possible for your
example, helps performance better, I guess.
|% cat sum2.py
|class Foo:
| def __init__(self):
| self.calc = self.calc # cache the method into self
| def calc(self, n):
| if n == 0: return 1
| else: return n + self.calc(n - 1)
|
|def test():
| a = Foo()
| for i in xrange(1000): a.calc(i)
|test()
First, your code tries to recurse deeply, so it MAY be the bottleneck.
Second, your explicit cache still need to attribute access which Ruby's
cache does not require.
Concept of Ruby's cache is somthing similar to:
|global f
|class Foo:
| def __init__(self):
| global f
| f = self.calc # cache the method into self
| def calc(self, n):
| global f
| if n == 0: return 1
| else: return n + f(n - 1)
|
|def test():
| global f
| a = Foo()
| for i in xrange(1000): f(i)
|test()
But it didn't help neither, maybe because of relatively slow global
variable access.
Your example in Ruby should be:
-- sum1.rb
class Foo
def calc(n)
if n == 0
1
else
n + self.calc(n - 1)
end
end
end
def test()
a = Foo.new()
for i in 1..1000
a.calc(i)
end
end
test()
--
But, sadly, it raises runtime exception of too deep recursion. So I
recompiled it to relax the limit, then it appeared to be SLOWER than
Python. Grr..
I profiled Ruby for that program, 50% of the excution time was
consumed for stack handling, not method invoking. OK, Ruby is weaker
about deep recursion than Python. I should work on it someday.
I didn't claim Ruby is superior than Python. I just said faster in
most of the cases. Your example should be the exception, hopefully. :-)
And my intension is to provide information about method cache, to help
Python improved, maybe in Python 2.0 or later.
Regular expression routine may make the difference. For simple grep
like this runs several times faster in Ruby.
-- rubygrep.rb
for line in open("/usr/share/dict/words")
if /ruby/ =~ line
print line
break
end
end
--
0.54user 0.07system 0:00.68elapsed 89%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (183major+151minor)pagefaults 0swaps
-- rubygrep.py
import regex
f = open("/usr/share/dict/words", "r")
pat = regex.compile("ruby")
while 1:
line = f.readline()
if pat.match(line) >= 0:
print line
break
--
3.33user 0.03system 0:03.70elapsed 90%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (184major+78minor)pagefaults 0swaps
I know regex is obsolete. But using re, it went even slower.
--
import re
f = open("/usr/share/dict/words", "r")
pat = re.compile("ruby")
while 1:
line = f.readline()
if pat.match(line):
print line
break
--
6.61user 0.02system 0:07.28elapsed 91%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (194major+92minor)pagefaults 0swaps
I was using:
Python 1.5.1 (#1, Dec 17 1998, 20:58:15) [GCC 2.7.2.3] on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
matz.
p.s.
For info about Ruby, see http://www.netlab.co.jp/ruby/
M.-A. Lemburg
>
> In article <87yan1r...@ev.netlab.co.jp>,
> Yukihiro Matsumoto <ma...@netlab.co.jp> writes:
> [snip]
> > of the case, mostly because its method cache. But Python has its
>
> Really?
>
> Method caching is possible in the current version of Python, if
> you dare do it explicitly, but it seems to help only a little,
>
> % cat sum1.py
> class Foo:
> def __init__(self):
> pass
> if n == 0: return 1
> else: return n + self.calc(n - 1)
>
> def test():
> a = Foo()
> for i in xrange(1000): a.calc(i)
> test()
> python sum1.py 10.05s user 0.24s system 99% cpu 10.298 total
> %
> class Foo:
> def __init__(self):
> self.calc = self.calc # cache the method into self
> def calc(self, n):
> if n == 0: return 1
> else: return n + self.calc(n - 1)
>
> def test():
> a = Foo()
> for i in xrange(1000): a.calc(i)
> test()
> python sum2.py 8.88s user 0.26s system 100% cpu 9.100 total
> %
You should retime these using time.clock() from within
Python. Timing the python interpreter startup (including
recompilation of sumX.py into byte code) will not reveal
the true speedup:
>>> class Foo:
... def __init__(self):
... pass
... def calc(self, n):
... if n == 0: return 1
... else: return n + self.calc(n - 1)
...
>>> def test():
... a = Foo()
... for i in xrange(1000): a.calc(i)
...
>>> import hack
>>> hack.clock('test()')
8.893abs 5.940usr sec.
>>> class Foo:
... def __init__(self):
... self.calc = self.calc # cache the method into self
... def calc(self, n):
... if n == 0: return 1
... else: return n + self.calc(n - 1)
...
>>> def test():
... a = Foo()
... for i in xrange(1000): a.calc(i)
...
>>> hack.clock('test()')
8.063abs 5.400usr sec.
The used hack.py can be found under Software on my Python Pages.
--
Marc-Andre Lemburg Y2000: 345 days left
---------------------------------------------------------------------
: Python Pages >>> http://starship.skyport.net/~lemburg/ :
---------------------------------------------------------
Christian Tismer
>
> Hisao Suzuki <suz...@otsl.oki.co.jp> writes:
[on method caching]
...
> First, your code tries to recurse deeply, so it MAY be the bottleneck.
> Second, your explicit cache still need to attribute access which Ruby's
> cache does not require.
Now, here is a variant which avoids this.
But this is just for testing speed, since what I did here
is really not what people want :-)
Also real method caching is not easy with Python, since
this would vulnerate the current definition of method
lookup. Explicit caching is of course allowed, implicit
caching would require to detect when the method changes,
and I think this would cost more than the speedup.
----- cache.py -----
class Foo1:
def __init__(self):
pass
def calc(self, n):
if n == 0: return 1
else: return n + self.calc(n - 1)
class Foo2:
def __init__(self):
self.calc = self.calc # cache the method into self
def calc(self, n):
if n == 0: return 1
else: return n + self.calc(n - 1)
class Foo3:
def __init__(self):
calc = self.calc # cache the method into local variable
calc.im_func.func_defaults = (calc,)
def calc(self, n, calc=None):
if n == 0: return 1
else: return n + calc(n - 1)
def test(klass, n):
a = klass()
for i in xrange(n): a.calc(i)
from ptools import timing
for klass in (Foo1, Foo2, Foo3):
print klass.__name__, timing(test, (klass, 1000) )[0]
result="""
Foo1 3.46
Foo2 3.3
Foo3 3.08
"""
----- yp.ehcac -----
Markus Kohler
[deltia]
> >>> class Foo:
> ... def __init__(self):
> ... self.calc = self.calc # cache the method into self
> ... def calc(self, n):
> ... if n == 0: return 1
> ... else: return n + self.calc(n - 1)
> ...
> >>> def test():
> ... a = Foo()
> ... for i in xrange(1000): a.calc(i)
> ...
> >>> hack.clock('test()')
> 8.063abs 5.400usr sec.
>
> The used hack.py can be found under Software on my Python Pages.
>
Just to tell you how fast a byte code interpreter can be ...
Squeak 2.1 a free Smalltalk byte code interpreter
runs this test on my machine in 1.37 seconds, versus 6.156abs 6.100usr sec
for Python.
Squeak 2.3 is out now and should be again about 30% faster, also I have not
tried it yet.
Of course Squeak has a method cache ...
And completely crossplatform 'Jitter' which compiles to a more low level data
structure at runtime will be coming soon probably boosting performance by a
factor of two(at least that was the case for the first version of this
Jitter).
See http://squeak.cs.uiuc.edu/ for more information on squeak.
Markus
--
Markus Kohler mailto:markus...@hp.com
M.-A. Lemburg
>
> "M.-A. Lemburg" <m...@lemburg.com> writes:
>
> [deltia]
> > >>> class Foo:
> > ... def __init__(self):
> > ... self.calc = self.calc # cache the method into self
> > ... def calc(self, n):
> > ... if n == 0: return 1
> > ... else: return n + self.calc(n - 1)
> > ...
> > >>> def test():
> > ... a = Foo()
> > ... for i in xrange(1000): a.calc(i)
> > ...
> > >>> hack.clock('test()')
> > 8.063abs 5.400usr sec.
> >
> > The used hack.py can be found under Software on my Python Pages.
> >
> Just to tell you how fast a byte code interpreter can be ...
>
> Squeak 2.1 a free Smalltalk byte code interpreter
> runs this test on my machine in 1.37 seconds, versus 6.156abs 6.100usr sec
> for Python.
Actually, the overhead causing Python to be slower is the
function call -- not the lookup of the method (cached or not).
If someone really is interested in significant speedups of the
interpreter, that's the place to look... unfortunately there's
not a lot one can do without making incompatible changes, but
these could go into Python 2.0.
> Squeak 2.3 is out now and should be again about 30% faster, also I have not
> tried it yet.
>
> Of course Squeak has a method cache ...
> And completely crossplatform 'Jitter' which compiles to a more low level data
> structure at runtime will be coming soon probably boosting performance by a
> factor of two(at least that was the case for the first version of this
> Jitter).
You forgot to tell us how to compile Python using Squeak ;-) ...
> See http://squeak.cs.uiuc.edu/ for more information on squeak.
--
sk...@calendar.com
paper from the Python conference last November. His benchmark results
(measured in calls to functions involved in method lookup) looked pretty
good. The paper is available online at
http://www.foretec.com/python/workshops/1998-11/proceedings/papers/lowis/
in both HTML and PostScript.
--
Skip Montanaro
Mojam: http://www.mojam.com/
Musi-Cal: http://concerts.calendar.com/
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Yukihiro Matsumoto
Me <ma...@netlab.co.jp> wrote:
|-- rubygrep.py
|import regex
|
|f = open("/usr/share/dict/words", "r")
|pat = regex.compile("ruby")
|
|while 1:
| line = f.readline()
| if pat.match(line) >= 0:
| print line
| break
|--
|3.33user 0.03system 0:03.70elapsed 90%CPU (0avgtext+0avgdata 0maxresident)k
|0inputs+0outputs (184major+78minor)pagefaults 0swaps
Explicit method cache technique can be used for this script.
-- regruby2.py
import regex
f = open("/usr/share/dict/words", "r")
pat = regex.compile("ruby")
readline = f.readline
match = pat.match
while 1:
line = readline()
if match(line) >= 0:
print line
break
--
2.65user 0.06system 0:02.96elapsed 91%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (184major+78minor)pagefaults 0swaps
About 20% performance gain. I do not claim this to be precise
comparison. Just to show the concept.
matz.
Hisao Suzuki
> if n == 0: return 1
should be
if n == 0: return 0
for the `sum'-mation function, though this is not relevant to
the subject anyway.
Stefan Franke
> The paper is available online at
>
> http://www.foretec.com/python/workshops/1998-11/proceedings/papers/lowis/
>
>in both HTML and PostScript.
Hmm...Is there any path from www.python.org to these documents? In
some of the proceeding's HTML files are links titled "7th conderence",
but they lead to the homepage of the 6th.
Everything still under construction?
sk...@calendar.com
I'm not sure. I didn't spend a lot of time looking for a clickable path. I
noticed that there was a proceedings directory underneath the 1997 workshop
and guessed that there would be one for the 1998 workshop as well. Perhaps
this part of the web site is still under construction.
bwa...@python.org
>>>>> "SF" == Stefan Franke <spamf...@bigfoot.de> writes:
SF> Hmm...Is there any path from www.python.org to these
SF> documents?
There is now a link from the main conference page. Please use this
URL to read the proceedings:
<http://www.foretec.com/python/workshops/1998-11/proceedings.html>
Note that some of the links are broken, but we will be fixing them as
time permits.
-Barry
mva...@bbb.caltech.edu
the question of who will do the work (I know! Anyone but me! ;-) there are
a lot of issues that will have to be faced if anyone seriously wants to
pursue such a goal:
1) Should the language require explicit type declarations or do type
inferencing? I would favor an approach where explicit type declarations are
always allowed but never mandatory unless needed to disambiguate between
different possibilities (i.e. where the type inferencer fails).
2) There will need to be some support for generic collection objects, with all
the complexity that that invariably brings in.
3) Probably lots of other issues I haven't thought of.
My impression is that creating a new static language is quite a lot harder
than creating a new scripting language in most cases. Given this, I think it
might be more practical to work on interfacing python with languages that
*almost* support the python object system (or its static projection) such as
java and eiffel, rather than define a new language just for this purpose. As
an added bonus, whatever improvements are made to the static language are
yours for free. However, if anyone wants to work on this it's OK by me :-)
Static-is-as-static-does-ly yr's,
Mike
In article <HeIo2.78$u5....@news-dal.corridex.com>,
"Evan Simpson" <ev...@tokenexchange.com> wrote:
> William Tanksley wrote in message ...
> >On Sun, 17 Jan 1999 15:06:02 -1000, Daniel Leuck wrote:
> >>I would sure like to have a more systems-level language compliment to
> >>Python. If someone were to create a strongly typed version of Python
> >>would there be anything preventing compiled code from executing at
> >>Java/C++ -like speeds?
[snip]
>
> If I'm reading Daniel right, he's not suggesting doing away with or changing
> Python in any way, nor is he interested in the existence of other nice
> high-level optimizable languages. I'll specify what I've been dreaming of,
> since I think it is somewhere in the general vicinity of what Daniel's
> wishes:
>
> 1. I like Python's syntax and built-in data structures. A *lot*. Having
> to write, read, or modify extensions written in C is painful. If the
> extension is new code, not a link to existing code, it's positively
> agonizing!
>
> 2. A great deal of what one does in an extension involves calls back into
> Python's function libraries to manipulate, pack, and unpack Python data
> structures. The remainder could often be expressed perfectly well in Python
> itself, except that it would unnecessarily invoke the power, flexibility,
> and overhead of the interpreter and object system for simple integer and
> floating point calculations, C calls, and small loops.
>
> 3. There is a rather amorphous sentiment in the community that Python could
> be made faster and better if we could just introduce stronger typing or
> better type inference, or some such thing. This may be true, but I feel
> that it the sort of thing that William was objecting to, and properly so.
> Invisible performance enhancements, such as tweaking of the VM and
> interpreter loop, is great, but even totally optional "pragma"-style
> performance hints risk complicating Python in ways that obscure its
> strengths.
>
> 4. Perhaps a separate-yet-complementary language could be valuable.
> Something analagous to the Java/JavaScript pairing (though I suppose JPython
> already has this, in a sense!). A language which looks and feels a lot like
> Python, which can use Python objects directly by internally using the Python
> API, but which can also use C-style data-structures and function libraries.
> A glue language for the glue language.
>
> I think that several other folks have approached this idea from various
> directions. Chris Tismer(?I think?) spoke of generating the C code for
> Python itself in Python, with a suitable code-generation module. With
> careful design, I imagine, this Python-helper language could specify macros,
> templates, and actual algorithms, all of which would be converted into C and
> then compiled into an extension (or into Python itself!). Many of the
> advantages of C++ over C might be gained, while chucking the bad parts of
> both.
>
> This may not appeal to those of you comfortable with C (including Guido, I
> guess :-/), but for folks like myself who are only read/write with
> Pascal/Delphi-style low-level languages, I think this would be a Godsend.
>
> Mmmm... Python-helper
> Evan Simpson