Hi, I've been trying for some time now to translate python code into C. After playing around with the pypy interactive translator shell and worked just fine. But the I tried to translate the pypy benchmarks from speed.pypy.orginto C code, but I seem to be running into all kinds of trouble. So far I've tried with bm_ai.py which seems to fail because it uses closures(or so i'm told by the translator), and bm_threading.py seems to fail while processing threading.py. Is there something I'm doing wrong? P.S.: I'm simply running the translator.py script with -s option on slightly modified versions of the above mentioned files(adding an entry point). -- Sincerely, Razvan Ghitulete Universitatea Politehnica Bucuresti
Hi, Why are you trying to do this? The translator doesn't handle random Python, only RPython. Alex On Sun, Feb 24, 2013 at 8:48 AM, Ghitulete Razvan < razvan.ghitulete@gmail.com> wrote:
-- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero
On Sun, Feb 24, 2013 at 6:58 PM, Alex Gaynor <alex.gaynor@gmail.com> wrote:
I am working on a research project to run python on a baremetal system. So I basically need a way of translating python code into something that can run on baremetal, hence C. After that I want to see whether it is worth it or not, and this is why I am trying to translate the benchmarks(as to have a common denominator). Is there any way I can get threading work with the translator. That is, are there any threading implementations available in RPython code? -- Sincerely, Razvan Ghitulete Universitatea Politehnica Bucuresti
On Sun, Feb 24, 2013 at 7:29 PM, Ghitulete Razvan <razvan.ghitulete@gmail.com> wrote:
Hi There is some support for threading in RPython, see rlib.rthread. RPython might not be your good buddy here. The executables built are rather large and the GC (at least on default settings) will not be that interesting for bare metal. What sort of parameters are you looking at? Also, using RPython is really tedious, you have been warned (it's *not* Python).
On Sun, Feb 24, 2013 at 7:37 PM, Maciej Fijalkowski <fijall@gmail.com>wrote:
Well, I don't seem to have much of a choice as I basically need source code out of python and not a binary. Also from what I see there is no translator that successfully translates full Python code into C/C++. As for parameters I don't care that much about the binary as I am not running in a resource restricted environment. I am actually running the baremetal binary on a x86_64 workstation. -- Sincerely, Razvan Ghitulete Universitatea Politehnica Bucuresti
On 24 February 2013 18:54, Douwe Osinga <douwe@triposo.com> wrote:
Have you tried cython?
Another possibility is Shedskin: "an *experimental* compiler, that can translate pure, but *implicitly statically typed* Python (2.4-2.6) programs into optimized C++. It can generate stand-alone programs or *extension modules* that can be imported and used in larger Python programs." https://code.google.com/p/shedskin/ It (intentionally) does not support type annotation, because they want to know how far they can go without it. David.
On Sun, Feb 24, 2013 at 7:58 PM, Ronny Pfannschmidt < Ronny.Pfannschmidt@gmx.de> wrote:
are you trying to write an operating system in "python"?
No, I actually want to see how fast can python code go. Writing an operating system in python would be quite crazy, and I am still rather sane. Maybe in the future though. On Sun, Feb 24, 2013 at 7:54 PM, Douwe Osinga <douwe@triposo.com> wrote:
Have you tried cython?
Actually I haven't. I remember of reading their front page, but it doesn't say anything explicitly there about converting to C code. Now that I've taken a better look, it seems interesting enough. I'll try and check it out. -- Sincerely, Razvan Ghitulete Universitatea Politehnica Bucuresti
What you are doing will not generate any information about how fast Python can be. It will show you the speed of RPython or Cython on baremetal, these are *NOT* python. Alex On Sun, Feb 24, 2013 at 10:44 AM, Ghitulete Razvan < razvan.ghitulete@gmail.com> wrote:
-- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero
On Sun, Feb 24, 2013 at 3:44 PM, Ghitulete Razvan < razvan.ghitulete@gmail.com> wrote:
So what I think you need is a pypy binary that can run without an os... the pypy binary needs a libc to access stuff, if you have one that you are using with other C software in your project maybe you can port pypy to it... probably a pthreads library will also be needed. What you need is to define a new platform and port the whole pypy to it... probably cross compiling from linux. I think that is how the arm port works and should be doable. -- Leonardo Santagada
Hi Ghitulete, So are you saying that you don't want to use CPython because it's C, and you want to try C-less alternatives, or at least things that don't use libc? Then look elsewhere. An RPython program (which is definitely something different than a Python program) is translated to C code that uses libc. Changing this would be possible, but certainly not less work than, say, changing CPython to not use the libc. Which, I seem to recall, has been done long ago in an experiment of "booting CPython". Either way, I'm rather sure that this has nothing to do with seeing how fast Python runs. Using a regular PyPy is more or less the fastest known way to run full pure Python code, so far. If you're rather interested in restricted subsets of Python or other Python-ish languages, then yes, RPython is one of them, and others have been mentioned in this thread. A bientôt, Armin.
On Sun, Feb 24, 2013 at 8:47 PM, Alex Gaynor <alex.gaynor@gmail.com> wrote:
I really disapprove of this language purity stuff. If it compiles, it works. If it runs it's perfect. The idea behind this attempt is to see what can be done if one removes all possible overhead. So I would not like to go down that rabbit hole. On Sun, Feb 24, 2013 at 11:14 PM, Armin Rigo <arigo@tunes.org> wrote:
I have never said I want to try C-less alternatives, but as to my knowledge the only common ground between CPython and C, si that part of CPython is written in C, as opposed to generating C code. What I need is to get the equivalent C code of a python program. CPython on the other hand would need to have a VM to run the bytecode in, which I not plan on doing. On Sun, Feb 24, 2013 at 9:17 PM, Leonardo Santagada <santagada@gmail.com> wrote:
I have pondered on doing that, but even though it is doable, it would require quite an effort as it would need a more complete environment than what I already have. Also, by porting pypy I would yet again get another layer between python code and hardware. -- Sincerely, Razvan Ghitulete Universitatea Politehnica Bucuresti
Hi, On Mon, Feb 25, 2013 at 9:13 AM, Ghitulete Razvan <razvan.ghitulete@gmail.com> wrote:
The point that Alex tried to make is that if you take a random medium-sized Python program, like any of the benchmarks you wanted to use, then it is very unlikely that just by chance they happen to also be valid RPython or Cython code. In order to take a Python program that was not meant to be RPython, and turn it into RPython, for example, then you need to review and fix it completely --- it is quite an endeavour. I wouldn't call it "language purity stuff" at all. If you don't think what I'm saying here makes sense, just try. A bientôt, Armin.
Hi, On Mon, Feb 25, 2013 at 10:43 AM, Armin Rigo <arigo@tunes.org> wrote:
It's not that I don't think it makes sense and I am pretty sure it will prove to be an ordeal. Also, the reason I said that I don't want to go into language purity arguments is that it is actually pretty obvious that unless you get an actual VM you cannot say that the end result is pure python as some features of the language are really hard to get when you are using a direct translation. Though I am curious as to why there isn't any `full` python code translator. -- Sincerely, Razvan Ghitulete Universitatea Politehnica Bucuresti
Hi, Why are you trying to do this? The translator doesn't handle random Python, only RPython. Alex On Sun, Feb 24, 2013 at 8:48 AM, Ghitulete Razvan < razvan.ghitulete@gmail.com> wrote:
-- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero
On Sun, Feb 24, 2013 at 6:58 PM, Alex Gaynor <alex.gaynor@gmail.com> wrote:
I am working on a research project to run python on a baremetal system. So I basically need a way of translating python code into something that can run on baremetal, hence C. After that I want to see whether it is worth it or not, and this is why I am trying to translate the benchmarks(as to have a common denominator). Is there any way I can get threading work with the translator. That is, are there any threading implementations available in RPython code? -- Sincerely, Razvan Ghitulete Universitatea Politehnica Bucuresti
On Sun, Feb 24, 2013 at 7:29 PM, Ghitulete Razvan <razvan.ghitulete@gmail.com> wrote:
Hi There is some support for threading in RPython, see rlib.rthread. RPython might not be your good buddy here. The executables built are rather large and the GC (at least on default settings) will not be that interesting for bare metal. What sort of parameters are you looking at? Also, using RPython is really tedious, you have been warned (it's *not* Python).
On Sun, Feb 24, 2013 at 7:37 PM, Maciej Fijalkowski <fijall@gmail.com>wrote:
Well, I don't seem to have much of a choice as I basically need source code out of python and not a binary. Also from what I see there is no translator that successfully translates full Python code into C/C++. As for parameters I don't care that much about the binary as I am not running in a resource restricted environment. I am actually running the baremetal binary on a x86_64 workstation. -- Sincerely, Razvan Ghitulete Universitatea Politehnica Bucuresti
On 24 February 2013 18:54, Douwe Osinga <douwe@triposo.com> wrote:
Have you tried cython?
Another possibility is Shedskin: "an *experimental* compiler, that can translate pure, but *implicitly statically typed* Python (2.4-2.6) programs into optimized C++. It can generate stand-alone programs or *extension modules* that can be imported and used in larger Python programs." https://code.google.com/p/shedskin/ It (intentionally) does not support type annotation, because they want to know how far they can go without it. David.
On Sun, Feb 24, 2013 at 7:58 PM, Ronny Pfannschmidt < Ronny.Pfannschmidt@gmx.de> wrote:
are you trying to write an operating system in "python"?
No, I actually want to see how fast can python code go. Writing an operating system in python would be quite crazy, and I am still rather sane. Maybe in the future though. On Sun, Feb 24, 2013 at 7:54 PM, Douwe Osinga <douwe@triposo.com> wrote:
Have you tried cython?
Actually I haven't. I remember of reading their front page, but it doesn't say anything explicitly there about converting to C code. Now that I've taken a better look, it seems interesting enough. I'll try and check it out. -- Sincerely, Razvan Ghitulete Universitatea Politehnica Bucuresti
What you are doing will not generate any information about how fast Python can be. It will show you the speed of RPython or Cython on baremetal, these are *NOT* python. Alex On Sun, Feb 24, 2013 at 10:44 AM, Ghitulete Razvan < razvan.ghitulete@gmail.com> wrote:
-- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero
On Sun, Feb 24, 2013 at 3:44 PM, Ghitulete Razvan < razvan.ghitulete@gmail.com> wrote:
So what I think you need is a pypy binary that can run without an os... the pypy binary needs a libc to access stuff, if you have one that you are using with other C software in your project maybe you can port pypy to it... probably a pthreads library will also be needed. What you need is to define a new platform and port the whole pypy to it... probably cross compiling from linux. I think that is how the arm port works and should be doable. -- Leonardo Santagada
Hi Ghitulete, So are you saying that you don't want to use CPython because it's C, and you want to try C-less alternatives, or at least things that don't use libc? Then look elsewhere. An RPython program (which is definitely something different than a Python program) is translated to C code that uses libc. Changing this would be possible, but certainly not less work than, say, changing CPython to not use the libc. Which, I seem to recall, has been done long ago in an experiment of "booting CPython". Either way, I'm rather sure that this has nothing to do with seeing how fast Python runs. Using a regular PyPy is more or less the fastest known way to run full pure Python code, so far. If you're rather interested in restricted subsets of Python or other Python-ish languages, then yes, RPython is one of them, and others have been mentioned in this thread. A bientôt, Armin.
On Sun, Feb 24, 2013 at 8:47 PM, Alex Gaynor <alex.gaynor@gmail.com> wrote:
I really disapprove of this language purity stuff. If it compiles, it works. If it runs it's perfect. The idea behind this attempt is to see what can be done if one removes all possible overhead. So I would not like to go down that rabbit hole. On Sun, Feb 24, 2013 at 11:14 PM, Armin Rigo <arigo@tunes.org> wrote:
I have never said I want to try C-less alternatives, but as to my knowledge the only common ground between CPython and C, si that part of CPython is written in C, as opposed to generating C code. What I need is to get the equivalent C code of a python program. CPython on the other hand would need to have a VM to run the bytecode in, which I not plan on doing. On Sun, Feb 24, 2013 at 9:17 PM, Leonardo Santagada <santagada@gmail.com> wrote:
I have pondered on doing that, but even though it is doable, it would require quite an effort as it would need a more complete environment than what I already have. Also, by porting pypy I would yet again get another layer between python code and hardware. -- Sincerely, Razvan Ghitulete Universitatea Politehnica Bucuresti
Hi, On Mon, Feb 25, 2013 at 9:13 AM, Ghitulete Razvan <razvan.ghitulete@gmail.com> wrote:
The point that Alex tried to make is that if you take a random medium-sized Python program, like any of the benchmarks you wanted to use, then it is very unlikely that just by chance they happen to also be valid RPython or Cython code. In order to take a Python program that was not meant to be RPython, and turn it into RPython, for example, then you need to review and fix it completely --- it is quite an endeavour. I wouldn't call it "language purity stuff" at all. If you don't think what I'm saying here makes sense, just try. A bientôt, Armin.
Hi, On Mon, Feb 25, 2013 at 10:43 AM, Armin Rigo <arigo@tunes.org> wrote:
It's not that I don't think it makes sense and I am pretty sure it will prove to be an ordeal. Also, the reason I said that I don't want to go into language purity arguments is that it is actually pretty obvious that unless you get an actual VM you cannot say that the end result is pure python as some features of the language are really hard to get when you are using a direct translation. Though I am curious as to why there isn't any `full` python code translator. -- Sincerely, Razvan Ghitulete Universitatea Politehnica Bucuresti
participants (8)
-
Alex Gaynor -
Armin Rigo -
Daπid -
Douwe Osinga -
Ghitulete Razvan -
Leonardo Santagada -
Maciej Fijalkowski -
Ronny Pfannschmidt