Re: pyvm -- faster python

Hi Michael [...] > > Releasing open source means that people *may* fix their own bugs, or > abandon the code. [...] I agree with all the points made. Moreover let me add that "code is one expression of a set of good ideas", and ideas want to be free! ;) I've decided to release the source code

Re: pyvm -- faster python

Stelios Xanthakis wrote: ... >- It's incompatible with CPython. Not all programs run. ... > - The demo is an x86/linux binary only. You shouldn't trust binaries, >run it in a chrooted environment not as root! > > Hope it works! Whatever the merits of a system like this, a closed system with b

Re: pyvm -- faster python

I have read about parrot. How is that progressing? Stelios Xanthakis wrote: > Hi. > > pyvm is a program which can run python 2.4 bytecode (the .pyc files). > A demo pre-release is available at: > http://students.ceid.upatras.gr/~sxanth/pyvm/ > > > Facts about pyvm: > - It's FAST. According

Re: pyvm -- faster python

"Stelios Xanthakis" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Also, for the other part of the thread, I think that bytecode may > be in fact faster than machine code JIT. Here is a theory: >Suppose that for each algorithm there is the "ideal implementation" >which executes

Re: pyvm -- faster python

Armin Steinhoff wrote: >>> Is there a working version of lwc ??? >>> >> >> pyvm is written in lwc-2.0 which is not yet released because >> nobody's using it. > > > As you mentioned it ... lwc-2.0 is used for pyvm. So it is used :) > > Do you have an idea when lwc-2.0 will be releast ? > > Ever

Re: pyvm -- faster python

Stelios Xanthakis wrote: > Armin Steinhoff wrote: > >>> >>> pyvm has that. A big part of it is written in "lightweight C++" [1]. >> >> >> >> Realy ? I have downloaded the lwc distribution and checked it out. >> It was a surprise that none of the examples are working. >> I'm using SuSE 9.0 with g

Re: pyvm -- faster python

Stelios Xanthakis wrote: > > Also, for the other part of the thread, I think that bytecode may > be in fact faster than machine code JIT. Forgot to add: It depends of course on how good is the bytecode. IMO Python's bytecode is pretty good for its purpose which is executing a dynamic language w

Re: pyvm -- faster python

Armin Steinhoff wrote: >> >> pyvm has that. A big part of it is written in "lightweight C++" [1]. > > > Realy ? I have downloaded the lwc distribution and checked it out. > It was a surprise that none of the examples are working. > I'm using SuSE 9.0 with gcc 3.3.1 ... > :( > Is there a work

Re: pyvm -- faster python

Stelios Xanthakis wrote: > Kay Schluehr wrote: > >> >> Yes. What we are seeking for and this may be the meaning of Armins >> intentiously provocative statement about the speed of running HLLs is a >> successor of the C-language and not just another VM interpreter that is >> written in C and limits

Re: pyvm -- faster python

Hi, Kay Schluehr wrote: > > Why this? eval() consumes a string, produces a code object and executes > it. Wether the code-object is bytecode or a chunk of machine code makes > a difference in the runtime but does not alter the high level > behavioural description of eval(). In either way the comp

Re: pyvm -- faster python

Paul Rubin writes: > Andrew Dalke <[EMAIL PROTECTED]> writes: > >> Years ago, presented at one of the Python conferences, was a program >> to generate C code from the byte code The conclusion I recall >> was that it wasn't faster - at best a few percent - and there

Re: pyvm -- faster python

Rocco Moretti <[EMAIL PROTECTED]> writes: > Python, as a procedural language, makes extensive use of globals & > mutable variables IIUC, in Lisp, as a functional language, "all > politics is local." Global-like variables are much rarer, and > mutability is severely limited. Some people write

Re: pyvm -- faster python

Paul Rubin wrote: > Despite the shrieks of the "Python is not Lisp!" crowd, Python > semantics and Lisp semantics aren't THAT different, and yet compiled > Lisp implementations com completely beat the pants off of interpreted > Python in terms of performance. I know little about Lisp compilatio

Re: pyvm -- faster python

[Paul Rubin] > François Pinard <[EMAIL PROTECTED]> writes: > > > Deep down, why or how not having a [traditional, to-native-code] > > compiler is a deficiency for CPython? We already know that such a > > beast would not increase speed so significantly, while using much > > more memory. > I'd say

Re: pyvm -- faster python

> I don't think Python can ever beat > carefully coded C for running speed, but it can and should aim for > parity with compiled Lisp. But common lisp compilers often beat C compilers in speed for similar tasks of moderate complexity. In particular, CMUCL beats GCC in numerical computations. Davi

Re: pyvm -- faster python

Andrew Dalke <[EMAIL PROTECTED]> writes: > Years ago, presented at one of the Python conferences, was a program > to generate C code from the byte code The conclusion I recall > was that it wasn't faster - at best a few percent - and there was a > big memory hit because of all the duplicated

Re: pyvm -- faster python

François Pinard <[EMAIL PROTECTED]> writes: > Deep down, why or how not having a [traditional, to-native-code] > compiler is a deficiency for CPython? We already know that such a beast > would not increase speed so significantly, while using much more memory. I'd say the opposite. The 4x speedup

Re: pyvm -- faster python

Stelios Xanthakis wrote: > Kay Schluehr wrote: > > > > > Yes. What we are seeking for and this may be the meaning of Armins > > intentiously provocative statement about the speed of running HLLs is a > > successor of the C-language and not just another VM interpreter that is > > written in C and li

Re: pyvm -- faster python

Paul Rubin wrote: > Yes, there are several Python compilers already ... > It's true that CPython doesn't have a compiler and that's a serious > deficiency. A lot of Python language features don't play that well > with compilation, and that's often unnecessary. So I hope the baseline > implem

Re: pyvm -- faster python

[Paul Rubin] > It's true that CPython doesn't have a compiler and that's > a serious deficiency. Hi, Paul. I did not closely follow all of the thread, so maybe my remark below, only repeats what others might have said and I missed? Deep down, why or how not having a [traditional, to-native-code

Re: pyvm -- faster python

>> - hacking SWIG. Shouldn't be too hard and will instantly give >> us access to wx, qt, etc. Mike> You can't assume that because some package is a C/C++ library Mike> wrapped for Python that it uses SWIG. pyqt, for example, doesn't Mike> use SWIG at all. It uses SIP, which i

Re: pyvm -- faster python

Kay Schluehr wrote: > > Yes. What we are seeking for and this may be the meaning of Armins > intentiously provocative statement about the speed of running HLLs is a > successor of the C-language and not just another VM interpreter that is > written in C and limits all efforts to extend it in a fl

Re: pyvm -- faster python

On 11 May 2005 19:48:42 -0700, Paul Rubin wrote: >Stelios Xanthakis <[EMAIL PROTECTED]> writes: >> I didn't know much about PyPy. It seems that pyvm is *exactly* what >> pypy needs to boost its performance. Does pypy has the vm in python >> as well? Does pypy have a c

Re: pyvm -- faster python

Paul Rubin wrote: > "Kay Schluehr" <[EMAIL PROTECTED]> writes: > > Delete the "standard" and You still obtain huge librarys for .Net, Java > > and Python. I also regret that Prothon starved in infancy but it might > > be exeggerated to demand that each language designer or one of his > > apostels

Re: pyvm -- faster python

Greg Ewing <[EMAIL PROTECTED]> writes: > > PyPy looks like the best vehicle for that so far. See > >http://catb.org/~esr/jargon/html/M/MFTL.html > > for the canonical remark about languages that can't be used to > > implement their own compilers. > > Which makes it clear that the remark is on

Re: pyvm -- faster python

Paul Rubin wrote: > PyPy looks like the best vehicle for that so far. See > >http://catb.org/~esr/jargon/html/M/MFTL.html > > for the canonical remark about languages that can't be used to > implement their own compilers. Which makes it clear that the remark is only intended to apply to *co

Re: pyvm -- faster python

Stelios Xanthakis <[EMAIL PROTECTED]> writes: > - hacking SWIG. Shouldn't be too hard and will instantly give > us access to wx, qt, etc. You can't assume that because some package is a C/C++ library wrapped for Python that it uses SWIG. pyqt, for example, doesn't use SWIG at all. It

Re: pyvm -- faster python

Stelios Xanthakis <[EMAIL PROTECTED]> writes: > I didn't know much about PyPy. It seems that pyvm is *exactly* what > pypy needs to boost its performance. Does pypy has the vm in python > as well? Does pypy have a compiler that produces 2.4 bytecodes? Pypy makes native machine code, not bytecod

Re: pyvm -- faster python

Stelios Xanthakis wrote: > There are two kinds of C modules: those that do have a knowledge > of the C API (like sre, tkinter, etc) and those that are just C/C++ > libraries which are simply wrapped as modules. For the latter there > are two solutions besides adding a wrapper which makes pyvm app

Re: pyvm -- faster python

"Stelios Xanthakis" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] >> - hacking SWIG. Shouldn't be too hard and will instantly give >> us access to wx, qt, etc. Have you ever written a non-trivial extension using Swig? It isn't as simple as you would think. There are a lot of lit

Re: pyvm -- faster python

In article <[EMAIL PROTECTED]>, Roger Binns <[EMAIL PROTECTED]> wrote: >> could You tell us a bit more about Your motivation to create an >> alternative C-Python interpreter? > >I'd also be curious to know if the performance gains would remain >once it gets fleshed out with things like closures, lo

Re: pyvm -- faster python

Paul Rubin wrote: > > I hope that PyPy will replace CPython once it's solid enough. Trying > to stay backwards compatible with the legacy C API doesn't seem to me > to be that important a goal. Redoing the library may take more work > than the Prothon guy was willing to do for Prothon, but PyPy

Re: pyvm -- faster python

Roger Binns wrote: >>I am not very interested on C compatibility. > > > That will rule out all the gui frameworks, SSL, cryptography > and numerous other packages. Have a look at what happened to > Prothon. What ultimately killed it was the problem of having > a decent library. You don't have

Re: pyvm -- faster python

"Roger Binns" <[EMAIL PROTECTED]> writes: > Some examples are gui toolkits (eg wxPython), SSL (eg M2Crypto, pyopenssl) > and database (pysqlite, APSW). These aren't in the shipped with Python > library but are widely used. M2Crypto is a straightforward SWIG wrapper around OpenSSL, I thought. I do

Re: pyvm -- faster python

"Kay Schluehr" <[EMAIL PROTECTED]> writes: > Delete the "standard" and You still obtain huge librarys for .Net, Java > and Python. I also regret that Prothon starved in infancy but it might > be exeggerated to demand that each language designer or one of his > apostels should manage a huge communit

Re: pyvm -- faster python

"Paul Rubin" wrote in message news:[EMAIL PROTECTED] > "Roger Binns" <[EMAIL PROTECTED]> writes: > What kind of stuff is in the existing Python C library that couldn't > be reimplemented or retargeted pretty easily? Most of it is either > wrappers for standard C functio

Re: pyvm -- faster python

Paul Rubin wrote: > "Roger Binns" <[EMAIL PROTECTED]> writes: > > Err, you proved my point! Prothon was fine at the VM level. The > > author couldn't figure out how to get a decent sized "standard" > > library, and ultimately ended up abandoning his VM for .Net since > > that gets you a large st

Re: pyvm -- faster python

"Roger Binns" <[EMAIL PROTECTED]> writes: > Err, you proved my point! Prothon was fine at the VM level. The > author couldn't figure out how to get a decent sized "standard" > library, and ultimately ended up abandoning his VM for .Net since > that gets you a large standard library. Jython also

Re: pyvm -- faster python

"Paul Rubin" wrote in message news:[EMAIL PROTECTED] > "Roger Binns" <[EMAIL PROTECTED]> writes: >> That will rule out all the gui frameworks, SSL, cryptography >> and numerous other packages. Have a look at what happened to >> Prothon. > > I think it would be enough to

Re: pyvm -- faster python

Paul Rubin wrote: > "Roger Binns" <[EMAIL PROTECTED]> writes: > >>That will rule out all the gui frameworks, SSL, cryptography >>and numerous other packages. Have a look at what happened to >>Prothon. > > > I think it would be enough to retarget SWIG. > > >>What ultimately killed it was the

Re: pyvm -- faster python

"Roger Binns" <[EMAIL PROTECTED]> writes: > That will rule out all the gui frameworks, SSL, cryptography > and numerous other packages. Have a look at what happened to > Prothon. I think it would be enough to retarget SWIG. > What ultimately killed it was the problem of having a decent > libra

Re: pyvm -- faster python

> I am not very interested on C compatibility. That will rule out all the gui frameworks, SSL, cryptography and numerous other packages. Have a look at what happened to Prothon. What ultimately killed it was the problem of having a decent library. You don't have to make the C library compatibil

Re: pyvm -- faster python

"Stelios Xanthakis" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] >> Maybe you can explain us why it is so fast, and/or maybe you can work >> with the other developers to improve the speed of the normal CPython, >> this can require equal or less work for you, and it can produce more

Re: pyvm -- faster python

[Stelios Xanthakis] > I'm afraid this may end up dead before unborn too. So it depends what > people want. If nobody cares, [...] People might not care so much about what could be done about your project, unless you give them proper and complete means for evaluating the state of affairs. Your p

Re: pyvm -- faster python

Roger Binns wrote: >>could You tell us a bit more about Your motivation to create an >>alternative C-Python interpreter? > > > I'd also be curious to know if the performance gains would remain > once it gets fleshed out with things like closures, long numbers, > new style classes and a C library

Re: pyvm -- faster python

[EMAIL PROTECTED] wrote: > This project is probably a LOT of work; maybe people can tell us about > such efforts *before* doing so much work, so we can discuss it, and > avoid wasting time. > It is a lot of work indeed. Usually, when people announce "we shall create X", it doesn't happen. And yo

Re: pyvm -- faster python

Kay Schluehr wrote: > > could You tell us a bit more about Your motivation to create an > alternative C-Python interpreter? There is AFAIK no such ambitious > project that has ever survived. The last one I remember died shortly > after it was born: > The motivation is that I just needed some byt

Re: pyvm -- faster python

djw <[EMAIL PROTECTED]> writes: > Paul Rubin wrote: >> Stelios Xanthakis <[EMAIL PROTECTED]> writes: >> >>>- The demo is an x86/linux binary only. You shouldn't trust binaries, >>> run it in a chrooted environment not as root! >> >> >> Are you going to release the source? If not, it's a lot

Re: pyvm -- faster python

Paul Rubin wrote: > Stelios Xanthakis <[EMAIL PROTECTED]> writes: > >>- The demo is an x86/linux binary only. You shouldn't trust binaries, >> run it in a chrooted environment not as root! > > > Are you going to release the source? If not, it's a lot less interesting. From the website: "..

Re: pyvm -- faster python

Stelios Xanthakis <[EMAIL PROTECTED]> writes: > - The demo is an x86/linux binary only. You shouldn't trust binaries, >run it in a chrooted environment not as root! Are you going to release the source? If not, it's a lot less interesting. -- http://mail.python.org/mailman/listinfo/python-lis

Re: pyvm -- faster python

> could You tell us a bit more about Your motivation to create an > alternative C-Python interpreter? I'd also be curious to know if the performance gains would remain once it gets fleshed out with things like closures, long numbers, new style classes and a C library compatibility shim. Roger

Re: pyvm -- faster python

Kay Schluehr wrote: > Stelios Xanthakis wrote: >>pyvm is a program which can run python 2.4 bytecode (the .pyc files). >>A demo pre-release is available at: >> http://students.ceid.upatras.gr/~sxanth/pyvm/ > > could You tell us a bit more about Your motivation to create an > alternative C-Pyt

Re: pyvm -- faster python

I've seen the benchmarks, they look quite interesting. This project is probably a LOT of work; maybe people can tell us about such efforts *before* doing so much work, so we can discuss it, and avoid wasting time. Maybe you can explain us why it is so fast, and/or maybe you can work with the othe

Re: pyvm -- faster python

Stelios Xanthakis wrote: > Hi. > > pyvm is a program which can run python 2.4 bytecode (the .pyc files). > A demo pre-release is available at: > http://students.ceid.upatras.gr/~sxanth/pyvm/ > > > Facts about pyvm: > - It's FAST. According to the "cooked-bench" benchmark suite it finishes >

pyvm -- faster python

Hi. pyvm is a program which can run python 2.4 bytecode (the .pyc files). A demo pre-release is available at: http://students.ceid.upatras.gr/~sxanth/pyvm/ Facts about pyvm: - It's FAST. According to the "cooked-bench" benchmark suite it finishes in 55% of the time python takes;) - It