Copyright 1998-2024, Southern California OS/2 User Group.
ALL RIGHTS RESERVED.
SCOUG, Warp Expo West, and Warpfest are trademarks of the
Southern California OS/2 User Group.
OS/2, Workplace Shell, and IBM are registered trademarks of
International Business Machines Corporation.
All other trademarks remain the property of their respective owners.
This PyPy thing seems to have a minor subset of the features we are trying get by creating SL1. For
instance:
1) Transparent proxies: allow the customization of both application and
builtin objects from application level code.
2) Since the JIT is
automatically generated out of the Python interpreter it should deal
with any sort of language changes rather well. Whether that is true in
practice remains to be seen, but this is one of the reason why PyPy was
started in the first place.
3) "Technically, PyPy is both a Python interpreter implementation and an
advanced compiler, or more precisely a framework for implementing dynamic
languages and generating virtual machines for them.
"The framework allows for alternative frontends and for alternative
backends, currently C, LLVM and .NET. For our main target "C", we can
can "mix in" different garbage collectors and threading models,
including micro-threads aka "Stackless". The inherent complexity that
arises from this ambitious approach is mostly kept away from the Python
interpreter implementation, our main frontend.
"PyPy is now also a Just-In-Time compiler generator. The translation
framework contains the now-integrated JIT generation technology. This
depends only on a few hints added to the interpreter source and should
be able to cope with the changes to the interpreter and be generally
applicable to other interpreters written using the framework."
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =
PyPy 1.0: JIT compilers for free and more =3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Welcome to the PyPy 1.0 release - =
a milestone integrating the results of four years of research, engin=
eering, management and sprinting efforts, concluding the 28 months p=
hase of EU co-funding!
Although still not mature enough for gener=
al use, PyPy 1.0 materializes for the first time the full extent of =
our original vision:
- A flexible Python interpreter, written in =
"RPython":
- Mostly unaware of threading, =
memory and lower-level target platform aspects. =
- Showcasing advanced interpreter features and prototyp=
es. - Passing core CPython regression tests, translatab=
le to C, LLVM and .NET.
- An advanced framework to translate=
such interpreters and programs:
- That performs who=
le type-inference on RPython programs. - Can weave in t=
hreading, memory and target platform aspects. - Has low=
level (C, LLVM) and high level (CLI, Java, JavaScript) backends.
- A **Just-In-Time Compiler generator** able to **automatically** <=
br> enhance the low level versions of our Python interpreter=
, leading to run-time machine code that runs algorithmi=
c examples at speeds typical of JITs!
Previous =
releases, particularly the 0.99.0 release from February, already hig=
hlighted features of our Python implementation and the abilities of =
our translation approach but the **new JIT generator** clearly marks=
a major research result and gives weight to our vision that one can=
generate efficient interpreter implementations, starting from a des=
cription in a high level language.
We have prepared several entry=
points to help you get started:
* The main entry point for JIT d=
ocumentation and status:
In th=
e next few months we are going to discuss the goals and form of the =
next stage of development - now more than ever depending on your fee=
dback and contributions - and we hope you appreciate PyPy 1.0 as an =
interesting basis for greater things to come, as much as we do ourse=
lves!
have fun,
the PyPy release team=
, Samuele Pedroni, Armin Rigo, Holger Krekel, Mi=
chael Hudson, Carl Friedrich Bolz, Antonio Cuni,=
Anders Chrigstroem, Guido Wesdorp Maciej Fijalk=
owski, Alexandre Fayolle
What is PyPy? =3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
Technically, PyPy is both a Python interpreter imple=
mentation and an advanced compiler, or more precisely a framework fo=
r implementing dynamic languages and generating virtual machines for=
them.
The framework allows for alternative frontends and for alt=
ernative backends, currently C, LLVM and .NET. For our main ta=
rget "C", we can can "mix in" different garbage =
collectors and threading models, including micro-threads aka "S=
tackless". The inherent complexity that arises from this =
ambitious approach is mostly kept away from the Python interpreter i=
mplementation, our main frontend.
PyPy is now also a Just-In-Time=
compiler generator. The translation framework contains the no=
w-integrated JIT generation technology. This depends only on a=
few hints added to the interpreter source and should be able to cop=
e with the changes to the interpreter and be generally applicable to=
other interpreters written using the framework.
Socially, PyPy i=
s a collaborative effort of many individuals working together in a d=
istributed and sprint-driven way since 2003. PyPy would not ha=
ve gotten as far as it has without the coding, feedback and general =
support from numerous people.
Formally, many of the current devel=
opers were involved in executing an EU contract with the goal of exp=
loring and researching new approaches to language and compiler devel=
opment and software engineering. This contract's duration is a=
bout to end this month (March 2007) and we are working and preparing=
the according final review which is scheduled for May 2007. For the future, we are in the process of setting up structures to help <=
br> maintain conceptual integrity of the project and to discuss and deal =
with funding opportunities related to further PyPy sprinting and developments. See here for results of the discussion so far:
- More Python interp=
reter optimizations (a CALL_METHOD bytecode, a method c=
ache, rope-based strings), now running benchmarks at around half of =
CPython's speed (without the JIT):
- The JavaScript backend has evolved to a point where it can be u=
sed to write AJAX web applications with it. This is sti=
ll an experimental technique, though. For demo applicat=
ions which also showcase various generated Python and P=
ROLOG interpreters, see:
- Proxying object spaces and features of our Python interpre=
ter:
- Tainting: a 270-line proxy object space track=
ing and boxing sensitive information within an a=
pplication.
- Transparent proxies: allow the customi=
zation of both application and builtin objects f=
rom application level code. Now featuring an &nb=
sp;initial support module (tputil.py) for working with transparent &=
nbsp; proxies.
For a detailed description and discus=
sion of high level backends and Python interpreter features, please =
see our extensive "D12" report:
Funding pa=
rtners and organisations =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
PyPy development and acti=
vities happen as an open source project and with the support of a co=
nsortium partially funded by a 28 month European Union IST research =
grant for the period from December 2004 to March 2007. The full part=
ners of that consortium are:
Heinrich-Heine U=
niversity (Germany), Open End (Sweden) merlinux =
GmbH (Germany), tismerysoft GmbH (Germany) Logil=
ab Paris (France), DFKI GmbH (Germany) ChangeMak=
er (Sweden), Impara (Germany)
Carl> Welcome to the PyPy 1.0 re=
lease... ... Carl> - A **Just-In=
-Time Compiler generator** able to **automatically** C=
arl> enhance the low level versions of our Python interpreter, =
Carl> leading to run-time machine code that =
runs algorithmic examples Carl> at speeds ty=
pical of JITs!
> In the next few months we are going to discuss the goals and f=
orm of > the next stage of development - now more than ever depen=
ding on your > feedback and contributions - and we hope you appre=
ciate PyPy 1.0 as an > interesting basis for greater things to co=
me, as much as we do > ourselves!
> have fun,
=
> the PyPy release team, > &=
nbsp;Samuele Pedroni, Armin Rigo, Holger Krekel, Michael Hudson, >=
; Carl Friedrich Bolz, Antonio Cuni, Anders Chrigstro=
em, Guido Wesdorp > Maciej Fijalkowski, Alexa=
ndre Fayolle
> What is PyPy? >=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D
> Technically, PyPy is both a Python =
interpreter implementation and an > advanced compiler, or more pr=
ecisely a framework for implementing dynamic > languages and gene=
rating virtual machines for them.
> The framework allows for a=
lternative frontends and for alternative > backends, currently C,=
LLVM and .NET. For our main target "C", we can >=
can "mix in" different garbage collectors and threading models=
, > including micro-threads aka "Stackless". The =
inherent complexity that > arises from this ambitious approach is=
mostly kept away from the Python > interpreter implementation, o=
ur main frontend.
> PyPy is now also a Just-In-Time compiler g=
enerator. The translation > framework contains the now-inte=
grated JIT generation technology. This > depends only on a =
few hints added to the interpreter source and should > be able to=
cope with the changes to the interpreter and be generally > appl=
icable to other interpreters written using the framework.
> So=
cially, PyPy is a collaborative effort of many individuals working &=
gt; together in a distributed and sprint-driven way since 2003. PyP=
y would > not have gotten as far as it has without the coding, fe=
edback and > general support from numerous people.
> F=
ormally, many of the current developers were involved in executing an > EU contract with the goal of exploring and researching new approac=
hes > to language and compiler development and software engineeri=
ng. This > contract's duration is about to end this month (=
March 2007) and we are > working and preparing the according fina=
l review which is scheduled > for May 2007.
> For the =
future, we are in the process of setting up structures to help > =
maintain conceptual integrity of the project and to discuss and deal =
> with funding opportunities related to further PyPy sprinting and > developments. See here for results of the discussion so far: =
> - More Python interpreter optimizations (a CALL=
_METHOD bytecode, a method > cache, rope-based strin=
gs), now running benchmarks at around half of > CPyt=
hon's speed (without the JIT):
> - The JavaScript backend has evol=
ved to a point where it can be used to > write AJAX =
web applications with it. This is still an experimental > =
technique, though. For demo applications which also showcase variou=
s > generated Python and PROLOG interpreters, see: <=
br>
> - =
Proxying object spaces and features of our Python interpreter:
&g=
t; - Tainting: a 270-line proxy object space tracking and bo=
xing > sensitive information within an applic=
ation.
> - Transparent proxies: allow the customi=
zation of both application and > builtin obje=
cts from application level code. Now featuring an > =
initial support module (tputil.py) for working with transpar=
ent > proxies.
> Funding partners and organisations > =3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
> PyPy development and activities happen as an open sou=
rce project and > with the support of a consortium partially fund=
ed by a 28 month > European Union IST research grant for the peri=
od from December 2004 to > March 2007. The full partners of that =
consortium are:
> Heinrich-Heine Universit=
y (Germany), Open End (Sweden) > merlinux Gmb=
H (Germany), tismerysoft GmbH (Germany) > Log=
ilab Paris (France), DFKI GmbH (Germany) > Ch=
angeMaker (Sweden), Impara (Germany)
Congratulations! =
I just have a couple of questions:
Attempting to execute pypy-c.=
exe (precompiled binary for Windows), raise an error message indicat=
ing that it cannot find gc_pypy.dll. Have you missed something or I'=
m doing something wrong?
Regarding the jit integration, do you ha=
ve any rough idea of when will it speed up arbitrary code, other tha=
n integer aritmethic?
> =3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > PyPy 1.0: JIT compilers=
for free and more > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
> Welcome to the PyPy 1.0 release - a milestone integra=
ting the > results of four years of research, engineering, manage=
ment and > sprinting efforts, concluding the 28 months phase of E=
U co-funding!
Fabulous! Congratulations to all who contrib=
uted to getting PyPy to this significant milestone.
Here's t=
o all the cool new things people will be doing with PyPy!
-- =
\ "If nothing changes, ever=
ything will remain the same." -- | `\ =
; &=
nbsp; &nbs=
p; Barne's Law | _o__) &nb=
sp; =
&n=
bsp; | =
Ben Finney
> =3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > PyPy 1.0: JIT compilers for free=
and more > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =
> Welcome to the PyPy 1.0 release - a milestone integrating th=
e results > of four years of research, engineering, management an=
d sprinting > efforts
=
> Carl Friedrich Bolz wrote: >> =3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> PyPy 1.0: JIT compiler=
s for free and more >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D [snip] > > =
;> Congratulations!
Thanks :-)
> I just have =
a couple of questions: > > Attempting to exec=
ute pypy-c.exe (precompiled binary for Windows), > raise an=
error message indicating that it cannot find gc_pypy.dll. >=
; Have you missed something or I'm doing something wrong?
Brain e=
rror on our side: the gc_pypy.dll is the dll of the Boehm garbage co=
llector, which you would need to compile yourself (which makes preco=
mpiled binaries a bit useless :-) ). We updated the zip file, would =
you mind checking whether it works better now?
> Regardi=
ng the jit integration, do you have any rough idea of when will &nbs=
p;> it speed up arbitrary code, other than integer aritmethic? Relatively soon. The hard bits of that are done, the JIT compiler g=
enerator is in a pretty good shape, we need to apply it to more parts of the PyPy Python interpreter. There are some non-coding related =
reasons why we are not doing it _right_ now: we still need to write some =
EU-reports (about the JIT for example) then we will need a while to =
recover from the EU project.
=
> Carl Friedrich Bolz wrote: >> =3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> PyPy 1.0: JIT compiler=
s for free and more >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D [snip] > > =
;> Congratulations!
Thanks :-)
> I just have =
a couple of questions: > > Attempting to exec=
ute pypy-c.exe (precompiled binary for Windows), > raise an=
error message indicating that it cannot find gc_pypy.dll. >=
; Have you missed something or I'm doing something wrong?
Brain e=
rror on our side: the gc_pypy.dll is the dll of the Boehm garbage co=
llector, which you would need to compile yourself (which makes preco=
mpiled binaries a bit useless :-) ). We updated the zip file, would =
you mind checking whether it works better now?
> Regardi=
ng the jit integration, do you have any rough idea of when will &nbs=
p;> it speed up arbitrary code, other than integer aritmethic? Relatively soon. The hard bits of that are done, the JIT compiler g=
enerator is in a pretty good shape, we need to apply it to more parts of the PyPy Python interpreter. There are some non-coding related =
reasons why we are not doing it _right_ now: we still need to write some =
EU-reports (about the JIT for example) then we will need a while to =
recover from the EU project.
> In the next few months we =
are going to discuss the goals and form of > the next stage of de=
velopment - now more than ever depending on your > feedback and c=
ontributions - and we hope you appreciate PyPy 1.0 as an > intere=
sting basis for greater things to come, as much as we do > oursel=
ves!
> have fun,
> the PyPy rel=
ease team, > Samuele Pedroni, Armin Rigo, Hol=
ger Krekel, Michael Hudson, > Carl Friedrich =
Bolz, Antonio Cuni, Anders Chrigstroem, Guido Wesdorp > &n=
bsp; Maciej Fijalkowski, Alexandre Fayolle
> What is PyPy? > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=
Technically, PyPy is both a Python interpreter implementation and an > advanced compiler, or more precisely a framework for implementing =
dynamic > languages and generating virtual machines for them.
> The framework allows for alternative frontends and for alternat=
ive > backends, currently C, LLVM and .NET. For our main ta=
rget "C", we can > can "mix in" different gar=
bage collectors and threading models, > including micro-threads a=
ka "Stackless". The inherent complexity that > ar=
ises from this ambitious approach is mostly kept away from the Python > interpreter implementation, our main frontend.
> PyPy i=
s now also a Just-In-Time compiler generator. The translation =
> framework contains the now-integrated JIT generation technology. &nb=
sp;This > depends only on a few hints added to the interpreter so=
urce and should > be able to cope with the changes to the interpr=
eter and be generally > applicable to other interpreters written =
using the framework.
> Socially, PyPy is a collaborative effor=
t of many individuals working > together in a distributed and spr=
int-driven way since 2003. PyPy would > not have gotten as =
far as it has without the coding, feedback and > general support =
from numerous people.
> Formally, many of the current develope=
rs were involved in executing an > EU contract with the goal of e=
xploring and researching new approaches > to language and compile=
r development and software engineering. This > contract's d=
uration is about to end this month (March 2007) and we are > work=
ing and preparing the according final review which is scheduled >=
for May 2007.
> For the future, we are in the process of sett=
ing up structures to help > maintain conceptual integrity of the =
project and to discuss and deal > with funding opportunities rela=
ted to further PyPy sprinting and > developments. See here for re=
sults of the discussion so far:
> - More Python =
interpreter optimizations (a CALL_METHOD bytecode, a method > &nb=
sp; cache, rope-based strings), now running benchmarks at around ha=
lf of > CPython's speed (without the JIT):
> - The JavaScript backend has evolved =
to a point where it can be used to > write AJAX web =
applications with it. This is still an experimental > &nbs=
p;technique, though. For demo applications which also showcase various > generated Python and PROLOG interpreters, see: =
> - Proxy=
ing object spaces and features of our Python interpreter:
> &n=
bsp; - Tainting: a 270-line proxy object space tracking and boxing =
> sensitive information within an application=
=2E
> - Transparent proxies: allow the customizat=
ion of both application and > builtin objects=
from application level code. Now featuring an > &nb=
sp; initial support module (tputil.py) for working with transparent=
> proxies.
> For a detailed descr=
iption and discussion of high level backends and > Python interpr=
eter features, please see our extensive "D12" report:
> Funding pa=
rtners and organisations > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> PyPy developme=
nt and activities happen as an open source project and > with the=
support of a consortium partially funded by a 28 month > Europea=
n Union IST research grant for the period from December 2004 to >=
March 2007. The full partners of that consortium are:
> =
; Heinrich-Heine University (Germany), Open End (Sweden) > merlinux GmbH (Germany), tismerysoft GmbH (Ger=
many) > Logilab Paris (France), DFKI GmbH (Ge=
rmany) > ChangeMaker (Sweden), Impara (German=
y)
Nice to read that things are going on. I've still a PyP=
y 0.7 version on my notebook. I guess I will upgrade :)
A so=
mewhat unrelated question. With Py3K Python gets optional type annot=
ations. Are you already architecting an annotation handler that can =
process these annotations? This feature is somewhat competitive to a=
ll the complicated type inference and jitting you have been worked o=
ut so I don't know how it fits well into the current PyPy architectu=
re?
"Kay Schluehr" <kay.schlu...@gmx.net> writes: &g=
t; A somewhat unrelated question. With Py3K Python gets optional type > annotations. Are you already architecting an annotation handler th=
at > can process these annotations? This feature is somewhat comp=
etitive to > all the complicated type inference and jitting you h=
ave been worked > out so I don't know how it fits well into the c=
urrent PyPy > architecture?
What's the nature of t=
he conflict between annotations and inference? Haskell for example h=
as both.
On 28.03.2007, at 10:38, Carl Friedrich Bolz wrot=
e:
>=
Brain error on our side: the gc_pypy.dll is the dll of the Boehm =
> garbage > collector, which you would need to compile yo=
urself (which makes > precompiled binaries a bit useless :-) ). W=
e updated the zip file, > would > you mind checkin=
g whether it works better now?
Why can't we provide a pre-=
compiled binary? Is this a license issue?
You are right. The feature is more situated on a syntacti=
cal / interface level. The semantical level has to be specified by <=
br> annotation handlers. Among them there will also be those that deal with type annotations. I have little doubts that one of them will make=
it into the stdlib sooner or later and might also influence co=
mpilation.
> I seem to > recall that some of the PyPy people weren't i=
nterested in static > analysis [1], so I'm skeptical about whethe=
r type annotations are > their kind of thing, either.
That's why I asked the question with regard to Py3K style annotations=
and not static analysis in Py2X which I consider intractible. The J=
IT measures types at runtime and optimizes code using this informati=
on but doing things in this style global optimizations are hardly tractible as well. My main interest is in an intermediate level, given=
type measurements as a byproduct of UTs and code coverage. This methodology is process-oriented and non interferent.
> That said, I imagine=
that the handling of > metadata (including type details) is an e=
lement in the way RPython > works, but I also imagine that things=
get more complicated as such > metadata diverges from plain type=
information and into arbitrary > "observations" about =
other aspects of program behaviour.
RPython is heuristical=
ly defined as a subset of Python "static enough to be translata=
ble to C". So it is actually static analysis that is done here,=
not on a local scale but on a simpler sublanguage. It is not clear =
to me whether for a sufficiently annotated Py3K program the inequati=
on RPython !=3D Python still holds?
Christian Tismer wrote: > On 28.03.20=
07, at 10:38, Carl Friedrich Bolz wrote:
>> Brain error on =
our side: the gc_pypy.dll is the dll of the Boehm >> ga=
rbage >> collector, which you would need to compile yourself (=
which makes >> precompiled binaries a bit useless :-) ). We up=
dated the zip file, >> would >> you mind che=
cking whether it works better now?
> Why can't we provide a pr=
e-compiled binary? > Is this a license issue?
Christian Tismer wrote: > On 28.03.20=
07, at 10:38, Carl Friedrich Bolz wrote:
>> Brain error on =
our side: the gc_pypy.dll is the dll of the Boehm >> ga=
rbage >> collector, which you would need to compile yourself (=
which makes >> precompiled binaries a bit useless :-) ). We up=
dated the zip file, >> would >> you mind che=
cking whether it works better now?
> Why can't we provide a pr=
e-compiled binary? > Is this a license issue?
On Mar 28, 4:34 pm, Paul Rubin <http://phr...@NOSPAM.=
invalid> wrote:
> "Kay Schluehr" <kay.schlu...@gmx.net> writes=
: > > A somewhat unrelated question. With Py3K Python gets opt=
ional type > > annotations. Are you already architecting an an=
notation handler that > > can process these annotations? This =
feature is somewhat competitive to > > all the complicated typ=
e inference and jitting you have been worked > > out so I don'=
t know how it fits well into the current PyPy > > architecture=
?
> What's the nature of the conflict between annotations and =
inference? > Haskell for example has both.
There i=
s no conflict in Haskell because Haskell has a type system by defaul=
t. But Python has none and so one had to define RPython, a subset of=
Python *viewed* as static enough to be translatable to C ( RPython =
is of course as polymorphic as any other Python code and can be fed =
with arbitrary types. Only the context makes it special ). RPython i=
s an approximation to Python on which static type inference is feasi=
ble. RPython is yet defined heuristically and this heuristics might =
be changed when RPython can be defined by the power of a type system=
defined *formally*. So it might be just a matter of reason to defin=
e a typesystem for interpreter/jit level Python code.
> RPython is heuristically defined as a su=
bset of Python "static enough > to be translatable to C"=
;. So it is actually static analysis that is > done here, not on =
a local scale but on a simpler sublanguage. It is > not clear to =
me whether for a sufficiently annotated Py3K program the > inequa=
tion RPython !=3D Python still holds?
You may also take a =
very good look at ShedSkin, it's already able to compile a decent pa=
rt of Python, and that part is slowly growing still. I'd like t=
o see a comparison of SSPython and RPython (width-wise and running s=
peed wise too) :-)
Hi! Suppose I have a py-written module. Is=
it possible somehow run PyPy on the whole module? I didn't find it =
in documentation. And if yes (or if just run in every module func) w=
hat will be after computer restart? Should I restart PyPy=
on the module once again? And are there any chances/intends for &nb=
sp;PyPy to be included into Python core? Thx, D.
On Mar=
28, 12:48 am, Carl Friedrich Bolz <cfb...@gmx.de> wrote:
> =3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DPyPy1.0: JIT compilers for free=
and more > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =
> Welcome to thePyPy1.0 release - a milestone integrating the =
results > of four years of research, engineering, management and =
sprinting > efforts, concluding the 28 months phase of EU co-fund=
ing!
> Although still not mature enough for general use,PyPy1.=
0 materializes > for the first time the full extent of our origin=
al vision:
> - A flexible Python interpreter, written in "=
;RPython":
> - Mostly unaware of threading, =
memory and lower-level target platform > aspe=
cts. > - Showcasing advanced interpreter features an=
d prototypes. > - Passing core CPython regression te=
sts, translatable to C, LLVM and > .NET.
> - An advanc=
ed framework to translate such interpreters and programs:
> &n=
bsp; - That performs whole type-inference on RPython programs. =
> - Can weave in threading, memory and target platform a=
spects. > - Has low level (C, LLVM) and high level (=
CLI, Java, JavaScript) > backends.
> - A **Just-In-Tim=
e Compiler generator** able to **automatically** > e=
nhance the low level versions of our Python interpreter, leading to =
> run-time machine code that runs algorithmic examples at=
speeds typical > of JITs!
> Previous rel=
eases, particularly the 0.99.0 release from February, > already h=
ighlighted features of our Python implementation and the > abilit=
ies of our translation approach but the **new JIT generator** > c=
learly marks a major research result and gives weight to our vision =
> that one can generate efficient interpreter implementations, startin=
g > from a description in a high level language.
> We =
have prepared several entry points to help you get started:
> =
* The main entry point for JIT documentation and status:
> I=
n the next few months we are going to discuss the goals and form of =
> the next stage of development - now more than ever depending on your=
> feedback and contributions - and we hope you appreciatePyPy1.0=
as an > interesting basis for greater things to come, as much as=
we do > ourselves!
> have fun,
> &n=
bsp; thePyPyrelease team, > Samuele Ped=
roni, Armin Rigo, Holger Krekel, Michael Hudson, > =
Carl Friedrich Bolz, Antonio Cuni, Anders Chrigstroem, Guido Wesdor=
p > Maciej Fijalkowski, Alexandre Fayolle
> What isPyPy? > =3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
> Technically,PyPyis both a Python interpreter implementat=
ion and an > advanced compiler, or more precisely a framework for=
implementing dynamic > languages and generating virtual machines=
for them.
> The framework allows for alternative frontends an=
d for alternative > backends, currently C, LLVM and .NET. F=
or our main target "C", we can > can "mix in"=
different garbage collectors and threading models, > including m=
icro-threads aka "Stackless". The inherent complexity tha=
t > arises from this ambitious approach is mostly kept away from =
the Python > interpreter implementation, our main frontend. =
> PyPyis now also a Just-In-Time compiler generator. The tran=
slation > framework contains the now-integrated JIT generation te=
chnology. This > depends only on a few hints added to the i=
nterpreter source and should > be able to cope with the changes t=
o the interpreter and be generally > applicable to other interpre=
ters written using the framework.
> Socially,PyPyis a collabor=
ative effort of many individuals working > together in a distribu=
ted and sprint-driven way since 2003. PyPywould > not have =
gotten as far as it has without the coding, feedback and > genera=
l support from numerous people.
> Formally, many of the curren=
t developers were involved in executing an > EU contract with the=
goal of exploring and researching new approaches > to language a=
nd compiler development and software engineering. This > co=
ntract's duration is about to end this month (March 2007) and we are =
> working and preparing the according final review which is scheduled=
> for May 2007.
> For the future, we are in the proce=
ss of setting up structures to help > maintain conceptual integri=
ty of the project and to discuss and deal > with funding opportun=
ities related to furtherPyPysprinting and > developments. See her=
e for results of the discussion so far:
> - More Pyt=
hon interpreter optimizations (a CALL_METHOD bytecode, a method >=
cache, rope-based strings), now running benchmarks at aroun=
d half of > CPython's speed (without the JIT): =
> - The JavaScript backend has =
evolved to a point where it can be used to > write A=
JAX web applications with it. This is still an experimental > &nb=
sp; technique, though. For demo applications which also showcase va=
rious > generated Python and PROLOG interpreters, se=
e:
>=
- Proxying object spaces and features of our Python interpreter: > - Tainting: a 270-line proxy object space tracking and=
boxing > sensitive information within an app=
lication.
> - Transparent proxies: allow the cust=
omization of both application and > builtin o=
bjects from application level code. Now featuring an > &nbs=
p; initial support module (tputil.py) for working with trans=
parent > proxies.
> For a detailed=
description and discussion of high level backends and > Python i=
nterpreter features, please see our extensive "D12" report:
> Fund=
ing partners and organisations > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> PyPydeve=
lopment and activities happen as an open source project and > wit=
h the support of a consortium partially funded by a 28 month > Eu=
ropean Union IST research grant for the period from December 2004 to =
> March 2007. The full partners of that consortium are:
> =
Heinrich-Heine University (Germany), Open End (Sweden=
) > merlinux GmbH (Germany), tismerysoft GmbH=
(Germany) > Logilab Paris (France), DFKI Gmb=
H (Germany) > ChangeMaker (Sweden), Impara (G=
ermany)
dmitrey wrote: > Hi! > Suppose I have a=
py-written module. > Is it possible somehow run PyPy on the whol=
e module? > I didn't find it in documentation. > And if y=
es (or if just run in every module func) what will be after > com=
puter restart? > Should I restart PyPy on the module once a=
gain? > And are there any chances/intends for PyPy to be in=
cluded into Python > core?
PyPy contains a full Py=
thon interpreter (which can include a JIT compiler) and thus replace=
s the "Python core". PyPy can never really be integrated i=
nto CPython.
dmitrey wrote: > Hi! > Suppose I have a=
py-written module. > Is it possible somehow run PyPy on the whol=
e module? > I didn't find it in documentation. > And if y=
es (or if just run in every module func) what will be after > com=
puter restart? > Should I restart PyPy on the module once a=
gain? > And are there any chances/intends for PyPy to be in=
cluded into Python > core?
PyPy contains a full Py=
thon interpreter (which can include a JIT compiler) and thus replace=
s the "Python core". PyPy can never really be integrated i=
nto CPython.
> Welcome to the Py=
Py 1.0 release - a milestone integrating the results > of four ye=
ars of research, engineering, management and sprinting > efforts,=
concluding the 28 months phase of EU co-funding!
So it to=
ok 4 yars of work and over 2 yaers of consumption of EU funds, yeah,=
great.
Could anybody explain, what this gives to Python and its =
users? Would we, eventually, get GIL-free VM, that is capable to con=
sume all available power of multicore processors? Or, maybe, we'll g=
et something special, I am unable to dream of? Or is it purely acade=
mic project to create Python VM in Python?
> Nice to read that thi=
ngs are going on. I've still a PyPy 0.7 version > on my not=
ebook. I guess I will upgrade :) > > A somewh=
at unrelated question. With Py3K Python gets optional type >=
; annotations. Are you already architecting an annotation handler that > can process these annotations? This feature is somewhat com=
petitive to > all the complicated type inference and jittin=
g you have been worked > out so I don't know how it fits we=
ll into the current PyPy > architecture?
I don't se=
e at all why type annotations are competitive to the type inference =
that PyPy's translation toolchain is doing. The type inference of Py=
Py is an artefact of the way we are implementing our interpreter (na=
mely in RPython). You also wouldn't say that the static typing of C =
is competitive to type annotations because CPython is written in C, =
right?
The JIT (which is completely independent from our type inf=
erence engine) will hopefully deal well with the eventual addition o=
f type annotations (it's not clear to me how soon we will start supp=
orting Py3k features, we are not even fully supporting Python 2.5 ye=
t). Since the JIT is automatically generated out of the Python inter=
preter it should deal with any sort of language changes rather well.=
Whether that is true in practice remains to be seen, but this is on=
e of the reason why PyPy was started in the first place.
Als=
o, I fail to see how type annotations can have a huge speed-advantage versus what our JIT and Psyco are doing. Imagine you have a function that is nicely algorithmic, takes only integers as arguments and only =
does some calculations with them. If you have a Psyco-like scheme, t=
he JIT will note that you are using it mostly with ints, generate relatively efficient assembly for the whole function (at least after i=
t has been called several times). If you call that functions, the arguments are checked whether they are integers and then the fast =
assembly code is used without any further type checks. How can you =
improve on this with type annotations? If the type annotations say that <=
br> your arguments have to be ints, you _still_ have to check whether thi=
s is true. So it is not faster than what Psyco is doing and has the =
disadvantage that it only works with ints -- good bye, duck typing. =
Psyco on the other hand will be perfectly happy with you using a cus=
tom class that looks mostly like an int and generate assembly optimi=
zed for this situation.
> Nice to read that thi=
ngs are going on. I've still a PyPy 0.7 version > on my not=
ebook. I guess I will upgrade :) > > A somewh=
at unrelated question. With Py3K Python gets optional type >=
; annotations. Are you already architecting an annotation handler that > can process these annotations? This feature is somewhat com=
petitive to > all the complicated type inference and jittin=
g you have been worked > out so I don't know how it fits we=
ll into the current PyPy > architecture?
I don't se=
e at all why type annotations are competitive to the type inference =
that PyPy's translation toolchain is doing. The type inference of Py=
Py is an artefact of the way we are implementing our interpreter (na=
mely in RPython). You also wouldn't say that the static typing of C =
is competitive to type annotations because CPython is written in C, =
right?
The JIT (which is completely independent from our type inf=
erence engine) will hopefully deal well with the eventual addition o=
f type annotations (it's not clear to me how soon we will start supp=
orting Py3k features, we are not even fully supporting Python 2.5 ye=
t). Since the JIT is automatically generated out of the Python inter=
preter it should deal with any sort of language changes rather well.=
Whether that is true in practice remains to be seen, but this is on=
e of the reason why PyPy was started in the first place.
Als=
o, I fail to see how type annotations can have a huge speed-advantage versus what our JIT and Psyco are doing. Imagine you have a function that is nicely algorithmic, takes only integers as arguments and only =
does some calculations with them. If you have a Psyco-like scheme, t=
he JIT will note that you are using it mostly with ints, generate relatively efficient assembly for the whole function (at least after i=
t has been called several times). If you call that functions, the arguments are checked whether they are integers and then the fast =
assembly code is used without any further type checks. How can you =
improve on this with type annotations? If the type annotations say that <=
br> your arguments have to be ints, you _still_ have to check whether thi=
s is true. So it is not faster than what Psyco is doing and has the =
disadvantage that it only works with ints -- good bye, duck typing. =
Psyco on the other hand will be perfectly happy with you using a cus=
tom class that looks mostly like an int and generate assembly optimi=
zed for this situation.
>> Welcome to the PyPy 1.0 re=
lease - a milestone integrating the results >> of four years o=
f research, engineering, management and sprinting >> efforts, =
concluding the 28 months phase of EU co-funding!
> So it took =
4 yars of work and over 2 yaers of consumption of EU funds, > yea=
h, great.
> Could anybody explain, what this gives to Python a=
nd its users? Would > we, eventually, get GIL-free VM, that is ca=
pable to consume all > available power of multicore processors? O=
r, maybe, we'll get > something > special, I am un=
able to dream of? Or is it purely academic project to > create Py=
thon VM in Python?
It will eventually give you a GIL-free =
VM, and it already gives you a lot more than you have dreamt of.
There is one feature missing that is probably hard to add. Hand=
ling the 'posters who are not willing to read before they post' syndrome.
>> something >&g=
t; special, I am unable to dream of? Or is it purely academic project to =
>> create Python VM in Python?
> It will eventually=
give you a GIL-free VM, and it already gives you > a lot more th=
an you have dreamt of.
> There is one feature missing that is =
probably hard to add. > Handling the 'posters who are not willing=
to read before they post' > syndrome.
....=
=2E..
I come from an academic background (sadly not in computer s=
cience) so I understand the need to promote the abstract advances th=
at are being made here.
However, I am a bit confused about the ap=
plicability of pypy. All the talk of backends, annotation object spa=
ces etc etc may make some sense to really interested parties, but I =
would like to know what I can do in real terms with the new interpre=
ters?
The demo javascript stuff seems a bit fake since others hav=
e already done some work in that direction already using ordinary py=
thon. RPython may be larger or smaller than those subsets, but that'=
s not clear.
I would be interested to know if it's possible to po=
int a tool at an existing python-2.4 module and wrap it into a much =
faster extension that can be used by my CPython stuff. I know there =
is preliminary work in that direction.
I am hugely encouraged by =
this
C:\Python\devel\pypy-1.0.0>\python24\python \python\lib\t=
est\pystone.py Pystone(1.1) time for 50000 passes =3D 1.49586 T=
his machine benchmarks at 33425.6 pystones/second
C:\Python\devel=
\pypy-1.0.0>.\pypy-c.exe \python\lib\test\pystone.py Pystone(1.1)=
time for 50000 passes =3D 2.16123e-005 This machine benchmarks at 2=
=2E3135e+009 pystones/second
To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-programming".
For problems, contact the list owner at
"postmaster@scoug.com".
The Southern California OS/2 User Group P.O. Box 26904
Santa Ana, CA 92799-6904, USA
Copyright 2001 the Southern California OS/2 User Group. ALL RIGHTS
RESERVED.
SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group.
OS/2, Workplace Shell, and IBM are registered trademarks of International
Business Machines Corporation.
All other trademarks remain the property of their respective owners.
![](3D"/groups/img/watched_n.gif" "3D\"Click")
![3D"flag"](3D"/groups/img/pushpin.gif")
![](3D"/groups/img/dot_clear.gif"){kind=spacer}
![](3D"/groups/img/clear_bg_yellow_star_on.gif"){kind=spacer}