Python Front-end to GCC

[John Nagle]

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 at 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