Python Front-end to GCC

[Philip Herron]

On Wednesday, 23 October 2013 07:48:41 UTC+1, John Nagle  wrote:
> On 10/20/2013 3:10 PM, victorgarcianet at 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.