This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Python frontend?


Andrew Haley wrote:
Robert Dewar writes:
> > I think so. People have used jython with gcj. I don't know that a
> > special Python front end would result in much better performance or
> > convenience.
> > Sure it would. The standard python interpretors are very slow. In
> class (my honors compiler class) we did a fast SPITBOL style
> compiler for Python generating x86 assembly language, and many
> programs ran 10-100 times faster.


Than an interpreter? Sure, you'd expect that.

Actually, for a dynamic language like Python it's not so easy, and most people would not expect that. Rather difficult and non-obvious techniques are required to achieve this. You can't just go generating add instructions when translating Python :-)

> That was gnerating x86 asm, and with a run-time whose critical > sections were hand written in x86 asm. You wouldn't do quite as > well with a normal target indepednet interface yto gcc, but you > could definitely get a huge improvement by generating code.

But gcj does generate code: that's the whole idea.  The issue is how
much speed is lost by going via the Java .class file format.  I admit
that I don't know.

The fact that gcj generates code is probably not terribly relevant. The issue is that the interface here is basically unsuitable for maximum efficiency in the case of Python. Of course that's only a guess, I assume we can get actual performance figures from the project itself.

Andrew


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]