Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #57152 > unrolled thread

Python Front-end to GCC

Back to article view | Back to comp.lang.python

Contents

  Python Front-end to GCC Philip Herron <herron.philip@googlemail.com> - 2013-10-20 10:56 -0700
    Re: Python Front-end to GCC victorgarcianet@gmail.com - 2013-10-20 15:10 -0700
      Re: Python Front-end to GCC John Nagle <nagle@animats.com> - 2013-10-22 23:48 -0700
        Re: Python Front-end to GCC Philip Herron <herron.philip@googlemail.com> - 2013-10-23 00:25 -0700
          Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-23 09:42 +0100
          Re: Python Front-end to GCC John Nagle <nagle@animats.com> - 2013-10-23 13:51 -0700
    Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-20 20:35 -0700
      Re: Python Front-end to GCC Steven D'Aprano <steve@pearwood.info> - 2013-10-21 07:46 +0000
        Re: Python Front-end to GCC Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2013-10-21 10:55 +0100
          Re: Python Front-end to GCC Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-21 23:41 +0000
            Re: Python Front-end to GCC Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2013-10-22 10:14 +0100
              Re: Python Front-end to GCC Philip Herron <herron.philip@googlemail.com> - 2013-10-22 02:32 -0700
              Re: Python Front-end to GCC Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-22 12:00 +0000
                Re: Python Front-end to GCC Chris Angelico <rosuav@gmail.com> - 2013-10-22 23:20 +1100
                  Re: Python Front-end to GCC Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-22 17:27 +0000
                    Re: Python Front-end to GCC Chris Angelico <rosuav@gmail.com> - 2013-10-23 08:43 +1100
                Re: Python Front-end to GCC Dave Angel <davea@davea.name> - 2013-10-22 14:04 +0000
                  Re: Python Front-end to GCC Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-22 15:22 +0000
                    Re: Python Front-end to GCC Grant Edwards <invalid@invalid.invalid> - 2013-10-22 15:39 +0000
                      Re: Python Front-end to GCC Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-22 16:40 +0000
                        Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-22 17:50 +0100
                        Re: Python Front-end to GCC Chris Kaynor <ckaynor@zindagigames.com> - 2013-10-22 09:52 -0700
                        Re: Python Front-end to GCC Frank Miles <fpm@u.washington.edu> - 2013-10-22 16:53 +0000
                          Re: Python Front-end to GCC Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-22 17:23 +0000
                            Re: Python Front-end to GCC Chris Kaynor <ckaynor@zindagigames.com> - 2013-10-22 10:35 -0700
                            Re: Python Front-end to GCC Neil Cerutti <neilc@norwich.edu> - 2013-10-22 17:37 +0000
                            Re: Python Front-end to GCC Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2013-10-22 18:37 +0100
                            Re: Python Front-end to GCC MRAB <python@mrabarnett.plus.com> - 2013-10-22 18:42 +0100
                            Re: Python Front-end to GCC Grant Edwards <invalid@invalid.invalid> - 2013-10-22 18:49 +0000
                            Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-25 04:40 +0100
                            Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-25 04:55 -0700
                            Re: Python Front-end to GCC Dan Sommers <dan@tombstonezero.net> - 2013-10-25 12:55 +0000
                            Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-25 15:18 +0100
                            Re: Python Front-end to GCC Ned Batchelder <ned@nedbatchelder.com> - 2013-10-25 10:35 -0400
                            Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-25 11:26 -0700
                              Re: Python Front-end to GCC Grant Edwards <invalid@invalid.invalid> - 2013-10-25 19:06 +0000
                            Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-25 19:40 +0100
                            Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-25 11:45 -0700
                              Re: Python Front-end to GCC rusi <rustompmody@gmail.com> - 2013-10-25 11:59 -0700
                                Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-25 12:09 -0700
                                  Re: Python Front-end to GCC rusi <rustompmody@gmail.com> - 2013-10-25 12:15 -0700
                            Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-25 20:02 +0100
                            Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-25 12:18 -0700
                              Re: Python Front-end to GCC John Nagle <nagle@animats.com> - 2013-10-26 14:31 -0700
                                Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-26 15:10 -0700
                                Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-27 15:14 -0700
                                  Re: Python Front-end to GCC rusi <rustompmody@gmail.com> - 2013-10-27 19:15 -0700
                                    Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-28 08:44 +0000
                                      Re: Python Front-end to GCC rusi <rustompmody@gmail.com> - 2013-10-28 02:31 -0700
                            Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-25 20:36 +0100
                            Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-25 12:49 -0700
                            Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-25 21:14 +0100
                            Re: Python Front-end to GCC Tim Delaney <timothy.c.delaney@gmail.com> - 2013-10-26 07:11 +1100
                            Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-25 13:29 -0700
                            Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-25 21:36 +0100
                              Re: Python Front-end to GCC Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-26 02:42 +0000
                            Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-25 21:44 +0100
                            Re: Python Front-end to GCC Tim Delaney <timothy.c.delaney@gmail.com> - 2013-10-26 07:48 +1100
                            Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-25 21:56 +0100
                            Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-25 14:02 -0700
                            Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-25 22:11 +0100
                            Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-25 14:37 -0700
                            Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-25 22:56 +0100
                            Re: Python Front-end to GCC Chris Angelico <rosuav@gmail.com> - 2013-10-26 13:36 +1100
                    Re: Python Front-end to GCC Neil Cerutti <neilc@norwich.edu> - 2013-10-22 17:15 +0000
                      Re: Python Front-end to GCC Grant Edwards <invalid@invalid.invalid> - 2013-10-22 18:58 +0000
                        Re: Python Front-end to GCC Grant Edwards <invalid@invalid.invalid> - 2013-10-22 20:26 +0000
                  Re: Python Front-end to GCC Grant Edwards <invalid@invalid.invalid> - 2013-10-22 15:36 +0000
                Re: Python Front-end to GCC Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2013-10-22 15:15 +0100
        Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-21 13:14 -0700
        Re: Python Front-end to GCC Ned Batchelder <ned@nedbatchelder.com> - 2013-10-21 16:29 -0400
          Re: Python Front-end to GCC rusi <rustompmody@gmail.com> - 2013-10-21 20:40 -0700
    Re: Python Front-end to GCC Philip Herron <herron.philip@googlemail.com> - 2013-10-21 04:08 -0700
      Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-21 13:26 -0700
        Re: Python Front-end to GCC Philip Herron <herron.philip@googlemail.com> - 2013-10-21 14:03 -0700
          Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-21 16:04 -0700
            Re: Python Front-end to GCC Piet van Oostrum <piet@vanoostrum.org> - 2013-10-21 23:45 -0400
              Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-21 21:24 -0700
                Re: Python Front-end to GCC Steven D'Aprano <steve@pearwood.info> - 2013-10-22 05:25 +0000
              Re: Python Front-end to GCC Dave Angel <davea@davea.name> - 2013-10-22 04:39 +0000
              Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-22 08:04 -0700
                Re: Python Front-end to GCC Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-22 17:09 +0000
                Re: Python Front-end to GCC Piet van Oostrum <piet@vanoostrum.org> - 2013-10-22 13:20 -0400
              Re: Python Front-end to GCC Ned Batchelder <ned@nedbatchelder.com> - 2013-10-22 11:46 -0400
              Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-22 16:52 +0100
              Re: Python Front-end to GCC Benjamin Kaplan <benjamin.kaplan@case.edu> - 2013-10-22 09:03 -0700
              Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-22 10:50 -0700
                Re: Python Front-end to GCC rusi <rustompmody@gmail.com> - 2013-10-22 11:11 -0700
                Re: Python Front-end to GCC Neil Cerutti <neilc@norwich.edu> - 2013-10-22 18:18 +0000
                  Re: Python Front-end to GCC Piet van Oostrum <piet@vanoostrum.org> - 2013-10-22 15:20 -0400
                    Re: Python Front-end to GCC Neil Cerutti <neilc@norwich.edu> - 2013-10-22 19:27 +0000
                      Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-22 20:38 +0100
                        Re: Python Front-end to GCC Neil Cerutti <neilc@norwich.edu> - 2013-10-22 20:00 +0000
                    Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-22 20:32 +0100
              Re: Python Front-end to GCC Skip Montanaro <skip@pobox.com> - 2013-10-22 13:08 -0500
              Re: Python Front-end to GCC MRAB <python@mrabarnett.plus.com> - 2013-10-22 19:16 +0100
              Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-22 11:16 -0700
              Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-22 11:22 -0700
              Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-22 11:28 -0700
                Re: Python Front-end to GCC Piet van Oostrum <piet@vanoostrum.org> - 2013-10-22 18:11 -0400
                  Re: Python Front-end to GCC Chris Angelico <rosuav@gmail.com> - 2013-10-23 17:28 +1100
                Re: Python Front-end to GCC Grant Edwards <invalid@invalid.invalid> - 2013-10-22 22:47 +0000
              Re: Python Front-end to GCC Ned Batchelder <ned@nedbatchelder.com> - 2013-10-22 14:23 -0400
                Re: Python Front-end to GCC rusi <rustompmody@gmail.com> - 2013-10-22 11:40 -0700
                  Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-22 19:58 +0100
              Re: Python Front-end to GCC Ned Batchelder <ned@nedbatchelder.com> - 2013-10-22 14:40 -0400
                Re: Python Front-end to GCC alex23 <wuwei23@gmail.com> - 2013-10-23 11:36 +1000
                  Re: Python Front-end to GCC rusi <rustompmody@gmail.com> - 2013-10-22 21:04 -0700
                  Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-23 07:06 +0100
              Re: Python Front-end to GCC MRAB <python@mrabarnett.plus.com> - 2013-10-22 19:47 +0100
              Re: Python Front-end to GCC Ned Batchelder <ned@nedbatchelder.com> - 2013-10-22 13:56 -0400
              Re: Python Front-end to GCC Michael Torrie <torriem@gmail.com> - 2013-10-22 22:05 -0600
              Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-23 07:13 +0100
              Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-26 14:25 -0700
              Re: Python Front-end to GCC Mark Janssen <dreamingforward@gmail.com> - 2013-10-26 14:33 -0700
              Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-26 22:38 +0100
              Re: Python Front-end to GCC Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-26 22:35 +0100
      Re: Python Front-end to GCC Antoine Pitrou <solipsis@pitrou.net> - 2013-10-22 08:55 +0000
        Re: Python Front-end to GCC Philip Herron <herron.philip@googlemail.com> - 2013-10-22 02:08 -0700
        Re: Python Front-end to GCC Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-22 10:10 +0000
          Re: Python Front-end to GCC Antoine Pitrou <solipsis@pitrou.net> - 2013-10-22 15:51 +0000
      Re: Python Front-end to GCC Stefan Behnel <stefan_ml@behnel.de> - 2013-10-24 08:47 +0200
    Re: Python Front-end to GCC xDog Walker <thudfoo@gmail.com> - 2013-10-25 14:49 -0700

Page 1 of 7  [1] 2 3 4 5 6 7  Next page →

#57152 — Python Front-end to GCC

Hey,

I've been working on GCCPY since roughly november 2009 at least in its
concept. It was announced as a Gsoc 2010 project and also a Gsoc 2011
project. I was mentored by Ian Taylor who has been an extremely big
influence on my software development carrer.

Gccpy is an Ahead of time implementation of Python ontop of GCC. So it
works as you would expect with a traditional compiler such as GCC to
compile C code. Or G++ to compile C++ etc.

Whats interesting and deserves a significant mention is my work is
heavily inspired by Paul Biggar's phd thesis on optimizing dynamic
languages and his work on PHC a ahead of time php compiler. I've had
so many ups and down in this project and i need to thank Andi Hellmund
for his contributions to the project.
http://paulbiggar.com/research/#phd-dissertation

The project has taken so many years as an in my spare time project to
get to this point. I for example its taken me so long simply to
understand a stabilise the core fundamentals for the compiler and how
it could all work.

The release can be found here. I will probably rename the tag to the
milestone (lucy) later on.
https://github.com/redbrain/gccpy/releases/tag/v0.1-24
(Lucy is our dog btw, German Shepard (6 years young) loves to lick
your face off :) )

Documentation can be found http://gcc.gnu.org/wiki/PythonFrontEnd.
(Although this is sparse partialy on purpose since i do not wan't
people thinking this is by any means ready to compile real python
applications)

I've found some good success with this project in compiling python
though its largely unknown to the world simply because i am nervous of
the compiler and more specifically the python compiler world.

But at least to me there is at least to me an un-answered question in
current compiler implementations.  AOT vs Jit.

Is a jit implementation of a language (not just python) better than
traditional ahead of time compilation.

What i can say is ahead of time at least strips out the crap needed
for the users code to be run. As in people are forgetting the basics
of how a computer works in my opinion when it comes to making code run
faster. Simply need to reduce the number of instructions that need to
be executed in order to preform what needs to be done. Its not about
Jit and bla bla keyword llvm keyword instruction scheduling keyword
bla.

I could go into the arguments but i feel i should let the project
speak for itself its very immature so you really cant compare it to
anything like it but it does compile little bits and bobs fairly well
but there is much more work needed.

There is nothing at steak, its simply an idea provoked from a great
phd thesis and i want to see how it would work out. I don't get funded
of paid. I love working on compilers and languages but i don't have a
day job doing it so its my little pet to open source i believe its at
least worth some research.

I would really like to hear the feedback good and bad. I can't
describe how much work i've put into this and how much persistence
I've had to have in light of recent reddit threads talking about my
project.

I have so many people to thank to get to this point! Namely Ian
Taylor, Paul Biggar, Andi Hellmund, Cyril Roelandt  Robert Bradshaw,
PyBelfast, and the Linux Outlaws community. I really couldn't have got
to this point in my life without the help of these people!

Thanks!

--Phil

[toc] | [next] | [standalone]

#57158

On Sunday, October 20, 2013 3:56:46 PM UTC-2, Philip Herron wrote:
> I've been working on GCCPY since roughly november 2009 at least in its
> concept. It was announced as a Gsoc 2010 project and also a Gsoc 2011
> project. I was mentored by Ian Taylor who has been an extremely big
> influence on my software development carrer.

Cool!

> Documentation can be found http://gcc.gnu.org/wiki/PythonFrontEnd.
> (Although this is sparse partialy on purpose since i do not wan't
> people thinking this is by any means ready to compile real python
> applications)

Is there any document describing what it can already compile and, if possible, showing some benchmarks?

> But at least to me there is at least to me an un-answered question in
> current compiler implementations.  AOT vs Jit.
> 
> Is a jit implementation of a language (not just python) better than
> traditional ahead of time compilation.
> 
> What i can say is ahead of time at least strips out the crap needed
> for the users code to be run. As in people are forgetting the basics
> of how a computer works in my opinion when it comes to making code run
> faster. Simply need to reduce the number of instructions that need to
> be executed in order to preform what needs to be done. Its not about
> Jit and bla bla keyword llvm keyword instruction scheduling keyword
> bla.

Maybe a less agressive tone (and a lot more research before going into sweeping statements that do nothing to further your own project) could result in a better level of discussion?
 
> I could go into the arguments but i feel i should let the project
> speak for itself its very immature so you really cant compare it to
> anything like it but it does compile little bits and bobs fairly well
> but there is much more work needed.

Can you compare it to Nuitka (http://nuitka.net/), ShedSkin (http://nuitka.net/) and Pythran (http://pythonhosted.org/pythran/) when you think it's mature enough? These projects have test suits you can borrow to chart you progress along the full-language support road.

It'd be good to find a place for your project on http://compilers.pydata.org/ , as soon as you better describe its workings.

> There is nothing at steak, its simply an idea provoked from a great
> phd thesis and i want to see how it would work out. I don't get funded
> of paid. I love working on compilers and languages but i don't have a
> day job doing it so its my little pet to open source i believe its at
> least worth some research.

It's very interesting indeed. Congratulations and thank you for your work.

Victor

[toc] | [prev] | [next] | [standalone]

#57345

On 10/20/2013 3:10 PM, victorgarcianet@gmail.com wrote:
> On Sunday, October 20, 2013 3:56:46 PM UTC-2, Philip Herron wrote:
>> I've been working on GCCPY since roughly november 2009 at least in its
>> concept. It was announced as a Gsoc 2010 project and also a Gsoc 2011
>> project. I was mentored by Ian Taylor who has been an extremely big
>> influence on my software development carrer.
> 
> Cool!
> 
>> Documentation can be found http://gcc.gnu.org/wiki/PythonFrontEnd.
>> (Although this is sparse partialy on purpose since i do not wan't
>> people thinking this is by any means ready to compile real python
>> applications)
> 
> Is there any document describing what it can already compile and, if possible, showing some benchmarks?

    After reading through a vast amount of drivel below on irrelevant
topics, looking at the nonexistent documentation, and finally reading
some of the code, I think I see what's going on here.  Here's
the run-time code for integers:

http://sourceforge.net/p/gccpy/code/ci/master/tree/libgpython/runtime/gpy-object-integer.c

   The implementation approach seems to be that, at runtime,
everything is a struct which represents a general Python object.
The compiler is, I think, just cranking out general subroutine
calls that know nothing about type information. All the
type handling is at run time.  That's basically what CPython does,
by interpreting a pseudo-instruction set to decide which
subroutines to call.

   It looks like integers and lists have been implemented, but
not much else.  Haven't found source code for strings yet.
Memory management seems to rely on the Boehm garbage collector.
Much code seems to have been copied over from the GCC library
for Go. Go, though, is strongly typed at compile time.

   There's no inherent reason this "compiled" approach couldn't work,
but I don't know if it actually does.     The performance has to be
very low.  Each integer add involves a lot of code, including two calls
of "strcmp (x->identifier, "Int")".  A performance win over CPython
is unlikely.

   Compare Shed Skin, which tries to infer the type of Python
objects so it can generate efficient type-specific C++ code.  That's
much harder to do, and has trouble with very dynamic code, but
what comes out is fast.

			John Nagle

[toc] | [prev] | [next] | [standalone]

#57346

On Wednesday, 23 October 2013 07:48:41 UTC+1, John Nagle  wrote:
> On 10/20/2013 3:10 PM, victorgarcianet@gmail.com wrote:
> 
> > On Sunday, October 20, 2013 3:56:46 PM UTC-2, Philip Herron wrote:
> 
> >> I've been working on GCCPY since roughly november 2009 at least in its
> 
> >> concept. It was announced as a Gsoc 2010 project and also a Gsoc 2011
> 
> >> project. I was mentored by Ian Taylor who has been an extremely big
> 
> >> influence on my software development carrer.
> 
> > 
> 
> > Cool!
> 
> > 
> 
> >> Documentation can be found http://gcc.gnu.org/wiki/PythonFrontEnd.
> 
> >> (Although this is sparse partialy on purpose since i do not wan't
> 
> >> people thinking this is by any means ready to compile real python
> 
> >> applications)
> 
> > 
> 
> > Is there any document describing what it can already compile and, if possible, showing some benchmarks?
> 
> 
> 
>     After reading through a vast amount of drivel below on irrelevant
> 
> topics, looking at the nonexistent documentation, and finally reading
> 
> some of the code, I think I see what's going on here.  Here's
> 
> the run-time code for integers:
> 
> 
> 
> http://sourceforge.net/p/gccpy/code/ci/master/tree/libgpython/runtime/gpy-object-integer.c
> 
> 
> 
>    The implementation approach seems to be that, at runtime,
> 
> everything is a struct which represents a general Python object.
> 
> The compiler is, I think, just cranking out general subroutine
> 
> calls that know nothing about type information. All the
> 
> type handling is at run time.  That's basically what CPython does,
> 
> by interpreting a pseudo-instruction set to decide which
> 
> subroutines to call.
> 
> 
> 
>    It looks like integers and lists have been implemented, but
> 
> not much else.  Haven't found source code for strings yet.
> 
> Memory management seems to rely on the Boehm garbage collector.
> 
> Much code seems to have been copied over from the GCC library
> 
> for Go. Go, though, is strongly typed at compile time.
> 
> 
> 
>    There's no inherent reason this "compiled" approach couldn't work,
> 
> but I don't know if it actually does.     The performance has to be
> 
> very low.  Each integer add involves a lot of code, including two calls
> 
> of "strcmp (x->identifier, "Int")".  A performance win over CPython
> 
> is unlikely.
> 
> 
> 
>    Compare Shed Skin, which tries to infer the type of Python
> 
> objects so it can generate efficient type-specific C++ code.  That's
> 
> much harder to do, and has trouble with very dynamic code, but
> 
> what comes out is fast.
> 
> 
> 
> 			John Nagle

I think your analysis is probably grossly unfair for many reasons. But your entitled to your opinion.

Current i do not use Bohem-GC (I dont have one yet), i re-use principles from gccgo in the _compiler_ not the runtime. At runtime everything is a gpy_object_t, everything does this. Yeah you could do a little of dataflow analysis for some really really specific code and very specific cases and get some performance gains. But the problem is that the libpython.so it was designed for an interpreter.

So first off your comparing a project done on my own to something like cPython loads of developers 20 years on my project or something PyPy has funding loads of developers.

Where i speed up is absolutely no runtime lookups on data access. Look at cPython its loads of little dictionaries. All references are on the Stack at a much lower level than C. All constructs are compiled in i can reuse C++ native exceptions in the whole thing. I can hear you shouting at the email already but the middle crap that a VM and interpreter have to do and fast lookup is _NOT_ one of them. If you truely understand how an interpreter works you know you cant do this

Plus your referencing really old code on sourceforge is another thing. And i dont want to put out bench marks (I would get so much shit from people its really not worth it) but it i can say it is faster than everything in the stuff i compile so far. So yeah... not only that but your referncing a strncmp to say no its slow yeah it isn't 100% ideal but in my current git tree i have changed that. So i think its completely unfair to reference tiny things and pretend you know everything about my project.

One thing people might find interesting is class i do data flow anaylsis to generate a complete type for that class and each member function is a compiled function like C++ but at a much lower level than C++. The whole project has been about stripping out the crap needed to run user code and i have been successful so far but your comparing a in my spare time project to people who work on their stuff full time. With loads of people etc.

Anyways i am just going to stay out of this from now but your email made me want to reply and rage.

[toc] | [prev] | [next] | [standalone]

#57348

On 23/10/2013 08:25, Philip Herron wrote:

Personally I have no interest in your project but do wish you the best 
of luck with your endeavours.

However I do have a personnal interest in my eyesite, which gets 
strained by reading posts such as yours.  In order to assist me in 
looking after my health, would you please be kind enough to read, digest 
and action this https://wiki.python.org/moin/GoogleGroupsPython.

TIA.

-- 
Python is the second best programming language in the world.
But the best has yet to be invented.  Christian Tismer

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#57386

On 10/23/2013 12:25 AM, Philip Herron wrote:
> On Wednesday, 23 October 2013 07:48:41 UTC+1, John Nagle  wrote:
>> On 10/20/2013 3:10 PM, victorgarcianet@gmail.com wrote:
>> 
>>> On Sunday, October 20, 2013 3:56:46 PM UTC-2, Philip Herron
>>> wrote:
> Nagle replies:
>> 
>>>> Documentation can be found
>>>> http://gcc.gnu.org/wiki/PythonFrontEnd.
...
> 
> I think your analysis is probably grossly unfair for many reasons.
> But your entitled to your opinion.
> 
> Current i do not use Bohem-GC (I dont have one yet), 

You included it in your project:

http://sourceforge.net/p/gccpy/code/ci/master/tree/boehm-gc


> i re-use
> principles from gccgo in the _compiler_ not the runtime. At runtime
> everything is a gpy_object_t, everything does this. Yeah you could do
> a little of dataflow analysis for some really really specific code
> and very specific cases and get some performance gains. But the
> problem is that the libpython.so it was designed for an interpreter.
> 
> So first off your comparing a project done on my own to something
> like cPython loads of developers 20 years on my project or something
> PyPy has funding loads of developers.
> 
> Where i speed up is absolutely no runtime lookups on data access.
> Look at cPython its loads of little dictionaries. All references are
> on the Stack at a much lower level than C. All constructs are
> compiled in i can reuse C++ native exceptions in the whole thing. I
> can hear you shouting at the email already but the middle crap that a
> VM and interpreter have to do and fast lookup is _NOT_ one of them.
> If you truely understand how an interpreter works you know you cant
> do this
> 
> Plus your referencing really old code on sourceforge is another
> thing.

That's where you said to look:

http://gcc.gnu.org/wiki/PythonFrontEnd

"To follow gccpy development see: Gccpy SourceForge
https://sourceforge.net/projects/gccpy"

> And i dont want to put out bench marks (I would get so much
> shit from people its really not worth it) but it i can say it is
> faster than everything in the stuff i compile so far. So yeah... not
> only that but your referncing a strncmp to say no its slow yeah it
> isn't 100% ideal but in my current git tree i have changed that. 

So the real source code isn't where you wrote that it is?
Where is it, then?

> So i
> think its completely unfair to reference tiny things and pretend you
> know everything about my project.

If you wrote more documentation about what you're doing,
people might understand what you are doing.

> One thing people might find interesting is class i do data flow
> analysis to generate a complete type for that class and each member
> function is a compiled function like C++ but at a much lower level
> than C++.

It's not clear what this means.  Are you trying to determine, say,
which items are integers, lists, or specific object types?
Shed Skin tries to do that.  It's hard to do, but very effective
if you can do it.  In CPython, every time "x = a + b" is
executed, the interpreter has to invoke the general case for
"+", which can handle integers, floats, strings, NumPy, etc.
If you can infer types, and know it's a float, the run
time code can be float-specific and about three machine
instructions.

> The whole project has been about stripping out the crap
> needed to run user code and i have been successful so far but your
> comparing a in my spare time project to people who work on their
> stuff full time. With loads of people etc.

Shed Skin is one guy.

> Anyways i am just going to stay out of this from now but your email
> made me want to reply and rage.

You've made big claims without giving much detail.  So people
are trying to find out if you've done something worth paying
attention to.

				John Nagle

[toc] | [prev] | [next] | [standalone]

#57166

> Gccpy is an Ahead of time implementation of Python ontop of GCC. So it
> works as you would expect with a traditional compiler such as GCC to
> compile C code. Or G++ to compile C++ etc.

That is amazing.  I was just talking about how someone should make a
front-end to GCC on this list a couple of months ago.  Awesome!

> Documentation can be found http://gcc.gnu.org/wiki/PythonFrontEnd.
> (Although this is sparse partialy on purpose since i do not wan't
> people thinking this is by any means ready to compile real python
> applications)

What's missing?

> I've found some good success with this project in compiling python
> though its largely unknown to the world simply because i am nervous of
> the compiler and more specifically the python compiler world.
>
> But at least to me there is at least to me an un-answered question in
> current compiler implementations.  AOT vs Jit.
>
> Is a jit implementation of a language (not just python) better than
> traditional ahead of time compilation.

Not at all.  The value of jit compilation, I believe, is purely for
the dynamic functionality that it allows.  AOT compilation will never
allow that, but in return you get massive performance and runtime-size
gains (that is, you don't need a massive interpreter environment
anymore!)  If your compiler produces an executable program without the
need for the python interpreter environment:  Two major wins.

> What i can say is ahead of time at least strips out the crap needed
> for the users code to be run. As in people are forgetting the basics
> of how a computer works in my opinion when it comes to making code run
> faster.

Agreed.

> I could go into the arguments but i feel i should let the project
> speak for itself its very immature so you really cant compare it to
> anything like it but it does compile little bits and bobs fairly well
> but there is much more work needed.

I wish I had the resources to try it myself, but would love to see
some performance numbers (say factorizations, or bubble-sorts, etc).
Also runtime executable sizes.


> I would really like to hear the feedback good and bad. I can't
> describe how much work i've put into this and how much persistence
> I've had to have in light of recent reddit threads talking about my
> project.

Please reference threads in question, would like to see the issues raised.
-- 
MarkJ
Tacoma, Washington

[toc] | [prev] | [next] | [standalone]

#57184

On Sun, 20 Oct 2013 20:35:03 -0700, Mark Janssen wrote:

[Attribution to the original post has been lost]
>> Is a jit implementation of a language (not just python) better than
>> traditional ahead of time compilation.
> 
> Not at all.  The value of jit compilation, I believe, is purely for the
> dynamic functionality that it allows.  AOT compilation will never allow
> that, but in return you get massive performance and runtime-size gains

On the contrary, you have that backwards. An optimizing JIT compiler can 
often produce much more efficient, heavily optimized code than a static 
AOT compiler, and at the very least they can optimize different things 
than a static compiler can. This is why very few people think that, in 
the long run, Nuitka can be as fast as PyPy, and why PyPy's ultimate aim 
to be "faster than C" is not moonbeams:

http://morepypy.blogspot.com.au/2011/02/pypy-faster-than-c-on-carefully-crafted.html

http://morepypy.blogspot.com.au/2011/08/pypy-is-faster-than-c-again-string.html


See here for a discussion on what JIT compilers can do which static 
compilers can't:

http://en.wikipedia.org/wiki/Just-in-time_compilation


Of course, the disadvantage of a JIT compiler is that there's a certain 
amount of runtime overhead: it takes time to analyse the running code, 
and more time to compile it on the fly. This is why, for example, PyPy 
likely won't be as fast for really short-running scripts as a static 
compiler could be. Again, see the Wikipedia article.

JIT compilation is really about optimization, which is why languages like 
Java and .NET which could easily be compiled to machine code at compile 
time generally use an intermediate bytecode and a JIT compiler instead. 
They're not doing it for dynamism since they aren't dynamic languages. 
It's a way of generating more aggressive (i.e. better but harder) 
optimizations based on information only available at runtime.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#57190

On 21 October 2013 08:46, Steven D'Aprano <steve@pearwood.info> wrote:
> On Sun, 20 Oct 2013 20:35:03 -0700, Mark Janssen wrote:
>
> [Attribution to the original post has been lost]
>>> Is a jit implementation of a language (not just python) better than
>>> traditional ahead of time compilation.
>>
>> Not at all.  The value of jit compilation, I believe, is purely for the
>> dynamic functionality that it allows.  AOT compilation will never allow
>> that, but in return you get massive performance and runtime-size gains
>
> On the contrary, you have that backwards. An optimizing JIT compiler can
> often produce much more efficient, heavily optimized code than a static
> AOT compiler, and at the very least they can optimize different things
> than a static compiler can. This is why very few people think that, in
> the long run, Nuitka can be as fast as PyPy, and why PyPy's ultimate aim
> to be "faster than C" is not moonbeams:

That may be true but both the examples below are spurious at best. A
decent AOT compiler would reduce both programs to the NULL program as
noted by haypo:
http://morepypy.blogspot.co.uk/2011/02/pypy-faster-than-c-on-carefully-crafted.html?showComment=1297205903746#c2530451800553246683

> http://morepypy.blogspot.com.au/2011/02/pypy-faster-than-c-on-carefully-crafted.html
>
> http://morepypy.blogspot.com.au/2011/08/pypy-is-faster-than-c-again-string.html

I just modified the add() example so that none of the operations can
be entirely optimised away:

def main():
    i = 0
    a = 0.0
    b = 0.0
    while i < 1000000000:
        a += 1.0
        b += add(a, a)
        i += 1
    print(b)

Similarly for the C version:

#include <stdio.h>

double add(double a, double b);

int main()
{
  int i = 0;
  double a = 0;
  double b = 0;
  while (i < 1000000000) {
    a += 1.0;
    b += add(a, a);
    i++;
  }
  printf("%f", b);
}

My timings:

$ gcc -O3 x.c y.c
$ time ./a.exe
1000000000134218000.000000
real    0m5.609s
user    0m0.015s
sys     0m0.000s
$ time pypy y.py
1.00000000013e+18

real    0m9.891s
user    0m0.060s
sys     0m0.061s

So the pypy version takes twice as long to run this. That's impressive
but it's not "faster than C".

I also compared a script that uses intensive decimal computation run
under CPython 3.3 and PyPy 2.1 (pyver 2.7). This is essentially a
comparison between the C implementation of the decimal module and
pypy's jit'd optimisation of the pure Python module. CPython 3.3 takes
10 seconds and PyPy 2.1 takes 45 seconds. Again that's impressive (a
lot of work went into making the C implementation of the decimal
module as fast as it is) but it's not faster than C.

I don't mean to criticise PyPy. I've just tested it and I am impressed
and I think I'll definitely try and use it where possible. I do think
that some of the marketing there is misleading though.


Oscar

[toc] | [prev] | [next] | [standalone]

#57217

On Mon, 21 Oct 2013 10:55:10 +0100, Oscar Benjamin wrote:

> On 21 October 2013 08:46, Steven D'Aprano <steve@pearwood.info> wrote:

>> On the contrary, you have that backwards. An optimizing JIT compiler
>> can often produce much more efficient, heavily optimized code than a
>> static AOT compiler, and at the very least they can optimize different
>> things than a static compiler can. This is why very few people think
>> that, in the long run, Nuitka can be as fast as PyPy, and why PyPy's
>> ultimate aim to be "faster than C" is not moonbeams:
> 
> That may be true but both the examples below are spurious at best. A
> decent AOT compiler would reduce both programs to the NULL program as
> noted by haypo:
> http://morepypy.blogspot.co.uk/2011/02/pypy-faster-than-c-on-carefully-
crafted.html?showComment=1297205903746#c2530451800553246683

Are you suggesting that gcc is not a decent compiler? If "optimize away 
to the null program" is such an obvious thing to do, why doesn't the most 
popular C compiler in the [FOSS] world do it?


[...]
> So the pypy version takes twice as long to run this. That's impressive
> but it's not "faster than C".

Nobody is saying that PyPy is *generally* capable of making any arbitrary 
piece of code run as fast as hand-written C code. You'll notice that the 
PyPy posts are described as *carefully crafted* examples.

I believe that, realistically, PyPy has potential to bring Python into 
Java and .Net territories, namely to run typical benchmarks within an 
order of magnitude of C speeds on the same benchmarks. C is a very hard 
target to beat, because vanilla C code does *so little* compared to other 
languages: no garbage collection, no runtime dynamism, very little 
polymorphism. So benchmarking simple algorithms plays to C's strengths, 
while ignoring C's weaknesses.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#57248

On 22 October 2013 00:41, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Mon, 21 Oct 2013 10:55:10 +0100, Oscar Benjamin wrote:
>
>> On 21 October 2013 08:46, Steven D'Aprano <steve@pearwood.info> wrote:
>
>>> On the contrary, you have that backwards. An optimizing JIT compiler
>>> can often produce much more efficient, heavily optimized code than a
>>> static AOT compiler, and at the very least they can optimize different
>>> things than a static compiler can. This is why very few people think
>>> that, in the long run, Nuitka can be as fast as PyPy, and why PyPy's
>>> ultimate aim to be "faster than C" is not moonbeams:
>>
>> That may be true but both the examples below are spurious at best. A
>> decent AOT compiler would reduce both programs to the NULL program as
>> noted by haypo:
>> http://morepypy.blogspot.co.uk/2011/02/pypy-faster-than-c-on-carefully-
> crafted.html?showComment=1297205903746#c2530451800553246683
>
> Are you suggesting that gcc is not a decent compiler?

No.

> If "optimize away
> to the null program" is such an obvious thing to do, why doesn't the most
> popular C compiler in the [FOSS] world do it?

It does if you pass the appropriate optimisation setting (as shown in
haypo's comment). I should have been clearer.

gcc compiles programs in two phases: compilation and linking.
Compilation creates the object files x.o and y.o from x.c and y.c.
Linking creates the output binary a.exe from x.o and y.o. The -O3
optimisation setting used in the blog post enables optimisation in the
compilation phase. However each .c file is compiled independently so
because the add() function is defined in x.c and called in y.c the
compiler is unable to inline it. It also can't remove it as dead code
because although it knows that the return value isn't used it doesn't
know if the call has side effects.

You might think it's silly that gcc can't optimise across source files
and if so you're right because actually it can if you enable link time
optimisation with the -flto flag as described by haypo. So if I do
that with the code from the blog post I get (using mingw gcc 4.7.2 on
Windows):

$ cat x.c
double add(double a, double b)
{
  return a + b;
}
$ cat y.c
double add(double a, double b);

int main()
{
  int i = 0;
  double a = 0;
  while (i < 1000000000) {
    a += 1.0;
    add(a, a);
    i++;
  }
}
$ gcc -O3 -flto x.c y.c
$ time ./a.exe

real    0m0.063s
user    0m0.015s
sys     0m0.000s
$ time ./a.exe  # warm cache

real    0m0.016s
user    0m0.015s
sys     0m0.015s

So gcc can optimise this all the way to the null program which takes
15ms to run (that's 600 times faster than pypy).

Note that even if pypy could optimise it all the way to the null
program it would still be 10 times slower than C's null program:

$ touch null.py
$ time pypy null.py

real    0m0.188s
user    0m0.076s
sys     0m0.046s
$ time pypy null.py  # warm cache

real    0m0.157s
user    0m0.060s
sys     0m0.030s

> [...]
>> So the pypy version takes twice as long to run this. That's impressive
>> but it's not "faster than C".

(Actually if I enable -flts with that example the C version runs 6-7
times faster due to inlining.)

> Nobody is saying that PyPy is *generally* capable of making any arbitrary
> piece of code run as fast as hand-written C code. You'll notice that the
> PyPy posts are described as *carefully crafted* examples.

They are more than carefully crafted. They are useless and misleading.
It's reasonable to contrive of a simple CPU-intensive programming
problem for benchmarking. But the program should do *something* even
if it is contrived. Both programs here consist *entirely* of dead
code. Yes it's reasonable for the pypy devs to test things like this
during development. No it's not reasonable to showcase this as an
example of the potential for pypy to speed up any useful computation.

> I believe that, realistically, PyPy has potential to bring Python into
> Java and .Net territories, namely to run typical benchmarks within an
> order of magnitude of C speeds on the same benchmarks. C is a very hard
> target to beat, because vanilla C code does *so little* compared to other
> languages: no garbage collection, no runtime dynamism, very little
> polymorphism. So benchmarking simple algorithms plays to C's strengths,
> while ignoring C's weaknesses.

As I said I don't want to criticise PyPy. I've just started using it
and I it is impressive. However both of those blog posts are
misleading. Not only that but the authors must know exactly why they
are misleading. Because of that I will take any other claims with a
big pinch of salt in future.


Oscar

[toc] | [prev] | [next] | [standalone]

#57249

On Tuesday, 22 October 2013 10:14:16 UTC+1, Oscar Benjamin  wrote:
> On 22 October 2013 00:41, Steven D'Aprano
> 
> >>> On the contrary, you have that backwards. An optimizing JIT compiler
> 
> >>> can often produce much more efficient, heavily optimized code than a
> 
> >>> static AOT compiler, and at the very least they can optimize different
> 
> >>> things than a static compiler can. This is why very few people think
> 
> >>> that, in the long run, Nuitka can be as fast as PyPy, and why PyPy's
> 
> >>> ultimate aim to be "faster than C" is not moonbeams:
> 
> >>
> 
> >> That may be true but both the examples below are spurious at best. A
> 
> >> decent AOT compiler would reduce both programs to the NULL program as
> 
> >> noted by haypo:
> 
> >> http://morepypy.blogspot.co.uk/2011/02/pypy-faster-than-c-on-carefully-
> 
> > crafted.html?showComment=1297205903746#c2530451800553246683
> 
> >
> 
> > Are you suggesting that gcc is not a decent compiler?
> 
> 
> 
> No.
> 
> 
> 
> > If "optimize away
> 
> > to the null program" is such an obvious thing to do, why doesn't the most
> 
> > popular C compiler in the [FOSS] world do it?
> 
> 
> 
> It does if you pass the appropriate optimisation setting (as shown in
> 
> haypo's comment). I should have been clearer.
> 
> 
> 
> gcc compiles programs in two phases: compilation and linking.
> 
> Compilation creates the object files x.o and y.o from x.c and y.c.
> 
> Linking creates the output binary a.exe from x.o and y.o. The -O3
> 
> optimisation setting used in the blog post enables optimisation in the
> 
> compilation phase. However each .c file is compiled independently so
> 
> because the add() function is defined in x.c and called in y.c the
> 
> compiler is unable to inline it. It also can't remove it as dead code
> 
> because although it knows that the return value isn't used it doesn't
> 
> know if the call has side effects.
> 
> 
> 
> You might think it's silly that gcc can't optimise across source files
> 
> and if so you're right because actually it can if you enable link time
> 
> optimisation with the -flto flag as described by haypo. So if I do
> 
> that with the code from the blog post I get (using mingw gcc 4.7.2 on
> 
> Windows):
> 
> 
> 
> $ cat x.c
> 
> double add(double a, double b)
> 
> {
> 
>   return a + b;
> 
> }
> 
> $ cat y.c
> 
> double add(double a, double b);
> 
> 
> 
> int main()
> 
> {
> 
>   int i = 0;
> 
>   double a = 0;
> 
>   while (i < 1000000000) {
> 
>     a += 1.0;
> 
>     add(a, a);
> 
>     i++;
> 
>   }
> 
> }
> 
> $ gcc -O3 -flto x.c y.c
> 
> $ time ./a.exe
> 
> 
> 
> real    0m0.063s
> 
> user    0m0.015s
> 
> sys     0m0.000s
> 
> $ time ./a.exe  # warm cache
> 
> 
> 
> real    0m0.016s
> 
> user    0m0.015s
> 
> sys     0m0.015s
> 
> 
> 
> So gcc can optimise this all the way to the null program which takes
> 
> 15ms to run (that's 600 times faster than pypy).
> 
> 
> 
> Note that even if pypy could optimise it all the way to the null
> 
> program it would still be 10 times slower than C's null program:
> 
> 
> 
> $ touch null.py
> 
> $ time pypy null.py
> 
> 
> 
> real    0m0.188s
> 
> user    0m0.076s
> 
> sys     0m0.046s
> 
> $ time pypy null.py  # warm cache
> 
> 
> 
> real    0m0.157s
> 
> user    0m0.060s
> 
> sys     0m0.030s
> 
> 
> 
> > [...]
> 
> >> So the pypy version takes twice as long to run this. That's impressive
> 
> >> but it's not "faster than C".
> 
> 
> 
> (Actually if I enable -flts with that example the C version runs 6-7
> 
> times faster due to inlining.)
> 
> 
> 
> > Nobody is saying that PyPy is *generally* capable of making any arbitrary
> 
> > piece of code run as fast as hand-written C code. You'll notice that the
> 
> > PyPy posts are described as *carefully crafted* examples.
> 
> 
> 
> They are more than carefully crafted. They are useless and misleading.
> 
> It's reasonable to contrive of a simple CPU-intensive programming
> 
> problem for benchmarking. But the program should do *something* even
> 
> if it is contrived. Both programs here consist *entirely* of dead
> 
> code. Yes it's reasonable for the pypy devs to test things like this
> 
> during development. No it's not reasonable to showcase this as an
> 
> example of the potential for pypy to speed up any useful computation.
> 
> 
> 
> > I believe that, realistically, PyPy has potential to bring Python into
> 
> > Java and .Net territories, namely to run typical benchmarks within an
> 
> > order of magnitude of C speeds on the same benchmarks. C is a very hard
> 
> > target to beat, because vanilla C code does *so little* compared to other
> 
> > languages: no garbage collection, no runtime dynamism, very little
> 
> > polymorphism. So benchmarking simple algorithms plays to C's strengths,
> 
> > while ignoring C's weaknesses.
> 
> 
> 
> As I said I don't want to criticise PyPy. I've just started using it
> 
> and I it is impressive. However both of those blog posts are
> 
> misleading. Not only that but the authors must know exactly why they
> 
> are misleading. Because of that I will take any other claims with a
> 
> big pinch of salt in future.
> 
> 
> 
> 
> 
> Oscar

You sir deserve a medal! I think alot of people are taking these sorts of benchmarks completely out of context and its great to see such a well rounded statement.

I applaud you so much! I've been sort of banging my head against the wall to describe what you just did as succinctly as that and couldn't.

[toc] | [prev] | [next] | [standalone]

#57253

On Tue, 22 Oct 2013 10:14:16 +0100, Oscar Benjamin wrote:

> On 22 October 2013 00:41, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
>> On Mon, 21 Oct 2013 10:55:10 +0100, Oscar Benjamin wrote:
>>
>>> On 21 October 2013 08:46, Steven D'Aprano <steve@pearwood.info> wrote:
>>
>>>> On the contrary, you have that backwards. An optimizing JIT compiler
>>>> can often produce much more efficient, heavily optimized code than a
>>>> static AOT compiler, and at the very least they can optimize
>>>> different things than a static compiler can. This is why very few
>>>> people think that, in the long run, Nuitka can be as fast as PyPy,
>>>> and why PyPy's ultimate aim to be "faster than C" is not moonbeams:
>>>
>>> That may be true but both the examples below are spurious at best. A
>>> decent AOT compiler would reduce both programs to the NULL program as
>>> noted by haypo:
>>> http://morepypy.blogspot.co.uk/2011/02/pypy-faster-than-c-on-
carefully-
>> crafted.html?showComment=1297205903746#c2530451800553246683

Keep in mind that the post's author, Maciej Fijalkowski, is not a native 
English speaker (to the best of my knowledge). You or I would probably 
have called the post a *contrived* example, not a "carefully crafted one" 
-- the meaning is the same, but the connotations are different.

Micro-benchmarks are mostly of theoretical interest, and contrived ones 
even more so, but still of interest. One needs to be careful not to read 
too much into them, but also not to read too little into them.


>> Are you suggesting that gcc is not a decent compiler?
> 
> No.
> 
>> If "optimize away
>> to the null program" is such an obvious thing to do, why doesn't the
>> most popular C compiler in the [FOSS] world do it?
> 
> It does if you pass the appropriate optimisation setting (as shown in
> haypo's comment). I should have been clearer.

"C can do nothing 10 times faster than Python!" -- well, okay, but what 
does that tell you about my long-running web server app? Benchmarks at 
the best of time are only suggestive, benchmarks for null programs are 
even less useful.

The very next comment after Haypo is an answer to his observation: 

    [quote]
    @haypo print the result so the loop don't get removed as dead 
    code. Besides, the problem is really the fact that's -flto is 
    unfair since python imports more resemble shared libraries 
    than statically-compiled files.


I'll be honest, I don't know enough C to really judge that claim, but I 
have noticed that benchmarks rarely compare apples and oranges, 
especially when C is involved. You can't eliminate all the differences 
between the code being generated, or at least not easily, since different 
languages have deep-seated differences in semantics that can't be 
entirely eliminated. But you should at least make some effort to compare 
code that does the same thing the same way.

Here's an example: responding to a benchmark showing a Haskell compiler 
generating faster code than a C compiler, somebody re-wrote the C code 
and got the opposite result:

http://jacquesmattheij.com/when-haskell-is-not-faster-than-c

Again, I can't judge the validity of all of the changes he made, but one 
stood out like a sore thumb:

    [quote]
    C does not require you to set static global arrays to ‘0’, so the 
    for loop in the main function can go...

Wait a minute... Haskell, I'm pretty sure, zeroes memory. C doesn't. So 
the C code is now doing less work. Yes, your C compiler will allow you to 
avoid zeroing memory before using it, and you'll save some time 
initially. But eventually[1] you will need to fix the security 
vulnerability by adding code to zero the memory, exactly as Haskell and 
other more secure languages already do. So *not* zeroing the memory is 
cheating. It's not something you'd do in real code, not if you care about 
security and correctness. Even if you don't care about security, you 
should care about benchmarking both languages performing the same amount 
of work.

Now, I may be completely off-base here. Some Haskell expert may chime up 
to say that Haskell does not, in fact, zero memory. But it does 
*something*, I'm sure, perhaps it tracks what memory is undefined and 
prevents reads from it, or something. Whatever it does, if it does it at 
runtime, the C benchmark better do the same thing, or it's an unfair 
comparison:

"Safely drive to the mall obeying all speed limits and traffic signals in 
a Chevy Volt, versus speed down the road running red lights and stop 
signs in a Ford Taurus" -- would it be any surprise that the Taurus is 
faster?

[...]
> They are more than carefully crafted. They are useless and misleading.
> It's reasonable to contrive of a simple CPU-intensive programming
> problem for benchmarking. But the program should do *something* even if
> it is contrived. Both programs here consist *entirely* of dead code.

But since the dead code is *not* eliminated, it is actually executed. If 
it's executed, it's not really dead, is it? Does it really matter that 
you don't do anything with the result? I'm with Maciej on this one -- 
*executing* the code given is faster in PyPy than in C, at least for this 
C compiler. Maybe C is faster to not execute it. Is that really an 
interesting benchmark? "C does nothing ten times faster than PyPy does 
something!"

Given a sufficiently advanced static analyser, PyPy could probably 
special-case programs that do nothing. Then you're in a race to compare 
the speed at which the PyPy runtime environment can start up and do 
nothing, versus a stand-alone executable that has to start up and do 
nothing. If this is a benchmark that people care about, I suggest they 
need to get out more :-)

Ultimately, this is an argument as what counts as a fair apples-to-apples 
comparison, and what doesn't. Some people consider that for a fair test, 
the code has to actually be executed. If you optimize away code and don't 
execute it, that's not a good benchmark. I agree with them. You don't. I 
can see both sides of the argument, and think that they both have 
validity, but on balance agree with the PyPy guys here: a compiler that 
optimizes away "for i = 1 to 1000: pass" to do-nothing is useful, but if 
you wanted to find out the runtime cost of a for-loop, you would surely 
prefer to disable that optimization and time how long it takes the for 
loop to actually run.

The actual point that the PyPy developers keep making is that a JIT 
compiler can use runtime information to perform optimizations which a 
static compiler like gcc cannot, and I haven't seen anyone dispute that 
point. More in the comments here:


    [quote]
    The point here is not that the Python implementation of 
    formatting is better than the C standard library, but that 
    dynamic optimisation can make a big difference. The first 
    time the formatting operator is called its format string is 
    parsed and assembly code for assembling the output generated. 
    The next 999999 times that assembly code is used without 
    doing the parsing step. Even if sprintf were defined locally,
    a static compiler can’t optimise away the parsing step, so 
    that work is done redundantly every time around the loop.

http://morepypy.blogspot.com/2011/08/pypy-is-faster-than-c-again-string.html?showComment=1312357475889#c6708170690935286644


Also possibly of interest:

http://beza1e1.tuxen.de/articles/faster_than_C.html





[1] Probably not until after the Zero Day exploit is released.  

-- 
Steven

[toc] | [prev] | [next] | [standalone]

#57255

On Tue, Oct 22, 2013 at 11:00 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> Given a sufficiently advanced static analyser, PyPy could probably
> special-case programs that do nothing. Then you're in a race to compare
> the speed at which the PyPy runtime environment can start up and do
> nothing, versus a stand-alone executable that has to start up and do
> nothing. If this is a benchmark that people care about, I suggest they
> need to get out more :-)

Like every benchmark, it has its uses. Just last week I was tinkering
with several high level languages in order to see which one would
start, do a fairly trivial task, and shut down, in the shortest space
of time. Why? Because I wanted that trivial task to be added to our
rapid-deployment sequence at a point where a human would be waiting on
it, and the task itself wasn't critical (it was an early-catcher for a
particular type of bug). Delaying my fellow developers by even one
second at that point would be unacceptable; the various options at my
disposal took anywhere from 250 to 750 ms (cold cache, which is what
matters) to run. Yes, I know a second isn't long. But I was trying to
sell a concept, and if I can say that it adds "practically no time" to
an interactive action, that's a lot better than even one second.
Considering that rapiding took about 1200ms (ish - again, cold cache)
previously, adding even just 250ms is noticeable. Benchmarking an
empty program would get very close to this actual real-world scenario.

(Eventually I merged the functionality into an unrelated script just
for the sake of saving on interpreter startup time.)

ChrisA

[toc] | [prev] | [next] | [standalone]

#57280

On Tue, 22 Oct 2013 23:20:52 +1100, Chris Angelico wrote:

> Considering that rapiding took about 1200ms (ish - again, cold cache)
> previously, adding even just 250ms is noticeable.

Please excuse my skepticism, but in my experience, that would probably 
mean in practice:

... rapiding took about 1200ms, plus or minus 200ms, plus 500ms if the 
system is under load, plus 800ms if the developer vagued out for a 
moment, plus 1900ms if he happened to be scratching an itch, plus 2700ms 
if the anti-virus happened to be scanning something, plus 4100ms if the 
dev decided this was a good time to take a sip of coffee, plus 437000ms 
if he needed to make the coffee first, plus 72000000ms if he was just 
taking a moment to check something on Reddit or answer an email...

I don't have a lot of sympathy for this sort of micro-optimization of 
interactive software, where the random variation from run to run is often 
larger than the time being optimized, and where the human element is 
usually one or two orders of magnitude greater still. Yes, developers 
complain when they have to wait for the computer for half a second, or at 
least the one time in thirty that they *notice* that they're waiting. The 
other 29 times the computer is actually waiting for them.

Still, I'm probably no better. Only instead of optimizing code, I tend to 
"optimize" travel time with "short cuts" that are guaranteed[1] to shave 
off a minute from a journey that takes thirty minutes, plus or minus six 
minutes. Show me a way to avoid waiting at traffic lights for 30s, and 
I'll take it, even if it means waiting for a break in the traffic at a 
Give Way sign for three minutes. So I shouldn't mock too much :-)

You're right, of course, that 1/4 second is noticeable. I just find it 
hard to credit that it's *significant* in the circumstances you're 
describing. But I could be wrong.



[1] Guarantee void in the presence of rain, fog, heavy winds, light 
winds, police radar traps, industrial action, civil protests, riots, 
wars, earthquakes, acts of God, or other cars.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#57316

On Wed, Oct 23, 2013 at 4:27 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Tue, 22 Oct 2013 23:20:52 +1100, Chris Angelico wrote:
>
>> Considering that rapiding took about 1200ms (ish - again, cold cache)
>> previously, adding even just 250ms is noticeable.
>
> Please excuse my skepticism, but in my experience, that would probably
> mean in practice:
>
> ... rapiding took about 1200ms, plus or minus 200ms, plus 500ms if the
> system is under load, plus 800ms if the developer vagued out for a
> moment, plus 1900ms if he happened to be scratching an itch, plus 2700ms
> if the anti-virus happened to be scanning something, plus 4100ms if the
> dev decided this was a good time to take a sip of coffee, plus 437000ms
> if he needed to make the coffee first, plus 72000000ms if he was just
> taking a moment to check something on Reddit or answer an email...

Yes; and more importantly, at the times when it actually would be
used, the cache will likely be warm.

> You're right, of course, that 1/4 second is noticeable. I just find it
> hard to credit that it's *significant* in the circumstances you're
> describing. But I could be wrong.

Yeah, but the problem here is a fundamental of human nature. I
mentioned earlier that I was trying to "sell" the notion of an instant
pre-check of the code. I use one myself, have done for ages, and it's
helped me often enough that I don't care if it occasionally adds a
second to my time. (I have a few such assistants that involve
searching through recent git commit messages, so they can take
multiple seconds if the cache is cold. I don't care; once it's in
cache, it's way faster.) But imagine sitting beside a skeptical fellow
developer and saying, "Enable this line here and it'll catch these
sorts of bugs before you even spin it up in your testbox" - and he
hits F7 and notices that it takes twice as long as he's used to.
That's going to make it a pretty hard sell. That's why I wanted to get
the time cost of the smoke test as low as I possibly could, even on a
cold cache.

(I'm used to tough sells at my workplace. It took years before we
adopted source control.... yes, seriously. And even once we did, I had
to fight to get other developers to make useful commits and commit
messages. One in particular - who, fortunately, is no longer with us -
saw the whole thing as a nuisance that got in the way of his genius,
so he'd just commit once at the end of the day with a barely-useful
message. But then, he was pretty astounding in a lot of other areas,
too - really amazing... like using the For-Case paradigm in PHP with
an off-by-one error...)

ChrisA

[toc] | [prev] | [next] | [standalone]

#57260

On 22/10/2013 08:00, Steven D'Aprano wrote:

> On Tue, 22 Oct 2013 10:14:16 +0100, Oscar Benjamin wrote:
>
   <snip>
> Here's an example: responding to a benchmark showing a Haskell compiler 
> generating faster code than a C compiler, somebody re-wrote the C code 
> and got the opposite result:
>
> http://jacquesmattheij.com/when-haskell-is-not-faster-than-c
>
> Again, I can't judge the validity of all of the changes he made, but one 
> stood out like a sore thumb:
>
>     [quote]
>     C does not require you to set static global arrays to ‘0’, so the 
>     for loop in the main function can go...
>
> Wait a minute... Haskell, I'm pretty sure, zeroes memory. C doesn't. So 

Static int variables are in fact zeroed.  However, most C compilers do
it by putting four bytes (or whatever) into the image of the
executable so it has no runtime cost.

<snip>
> But eventually[1] you will need to fix the security
> vulnerability by adding code to zero the memory, exactly as Haskell and 
> other more secure languages already do. So *not* zeroing the memory is
> cheating. It's not something you'd do in real code, not if you care
> about security and correctness.

I agree with most of what you say in the message, but here you go on to
say the C code is unsafely skipping initialization, which is not the
case.

By the way, a C compiler typically handles any initialization of a
static variable the same way.  So if you declare and initialize a static
variable as

int  myvar = 34 * 768;

it'll put the product directly in the executable image, and no runtime
code is generated.

Perhaps you were thinking of an automatic variable, which is not
initialized unless the programmer says so, and is then initialized with
code.

-- 
DaveA

[toc] | [prev] | [next] | [standalone]

#57264

On Tue, 22 Oct 2013 14:04:57 +0000, Dave Angel wrote:

[...]
> I agree with most of what you say in the message, 

Glad to hear I wasn't completely full of it. As a non-C developer, I'm 
very conscious that a lot of what I know about C is second hand.


> but here you go on to
> say the C code is unsafely skipping initialization, which is not the
> case.

Are you talking generically, or specifically about the C code referenced 
in the link I gave?

"Memory is always zeroed" is one of the advantages of Go over C and C++, 
at least according to Rob Pike:

http://commandcenter.blogspot.com.au/2012/06/less-is-exponentially-
more.html



> By the way, a C compiler typically handles any initialization of a
> static variable the same way.  So if you declare and initialize a static
> variable as
> 
> int  myvar = 34 * 768;
> 
> it'll put the product directly in the executable image, and no runtime
> code is generated.

Yes, that's a keyhole optimization, CPython does the same sort of thing:

py> import dis
py> dis.dis(compile("myvar = 34 * 768", "", "exec"))
  1           0 LOAD_CONST               3 (26112)
              3 STORE_NAME               0 (myvar)
              6 LOAD_CONST               2 (None)
              9 RETURN_VALUE



> Perhaps you were thinking of an automatic variable, which is not
> initialized unless the programmer says so, and is then initialized with
> code.

No, I was thinking of an array. Arrays aren't automatically initialised 
in C.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#57266

On 2013-10-22, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:
> On Tue, 22 Oct 2013 14:04:57 +0000, Dave Angel wrote:
>
> [...]
>> I agree with most of what you say in the message, 
>
> Glad to hear I wasn't completely full of it. As a non-C developer, I'm 
> very conscious that a lot of what I know about C is second hand.
>
>
>> but here you go on to
>> say the C code is unsafely skipping initialization, which is not the
>> case.
>
> Are you talking generically, or specifically about the C code
> referenced in the link I gave?

In C, static/global variables are always zeroed.

> "Memory is always zeroed" is one of the advantages of Go over C and C++, 
> at least according to Rob Pike:
>
> http://commandcenter.blogspot.com.au/2012/06/less-is-exponentially-more.html

Perhaps he's talking about automatic variables or malloc()ed memory?

You'd have to ask him.

>> Perhaps you were thinking of an automatic variable, which is not
>> initialized unless the programmer says so, and is then initialized with
>> code.
>
> No, I was thinking of an array. Arrays aren't automatically initialised 
> in C.

If they are static or global, then _yes_they_are_.  They are zeroed.

-- 
Grant Edwards               grant.b.edwards        Yow! I selected E5 ... but
                                  at               I didn't hear "Sam the Sham
                              gmail.com            and the Pharoahs"!

[toc] | [prev] | [next] | [standalone]

#57272

On Tue, 22 Oct 2013 15:39:42 +0000, Grant Edwards wrote:

>> No, I was thinking of an array. Arrays aren't automatically initialised
>> in C.
> 
> If they are static or global, then _yes_they_are_.  They are zeroed.

Not that I don't believe you, but do you have a reference for this? 
Because I keep finding references to uninitialised C arrays filled with 
garbage if you don't initialise them.

Wait... hang on a second...

/fires up the ol' trusty gcc


[steve@ando c]$ cat array_init.c
#include<stdio.h>

int main()
{
  int i;
  int arr[10];
  for (i = 0; i < 10; i++) {
    printf("arr[%d] = %d\n", i, arr[i]);
    }
    printf("\n");
    return 0;
}

[steve@ando c]$ gcc array_init.c
[steve@ando c]$ ./a.out
arr[0] = -1082002360
arr[1] = 134513317
arr[2] = 2527220
arr[3] = 2519564
arr[4] = -1082002312
arr[5] = 134513753
arr[6] = 1294213
arr[7] = -1082002164
arr[8] = -1082002312
arr[9] = 2527220


What am I missing here?


-- 
Steven

[toc] | [prev] | [next] | [standalone]

Page 1 of 7  [1] 2 3 4 5 6 7  Next page →

Back to top | Article view | comp.lang.python

csiph-web