jython-users

Re: [Jython-users] jython to java?

[Ype K. <yk...@xs...>]

Originally alreadu sent to:

John,

>Any thoughts about developing a tool to convert Jython to Java?  Unlike
>jythonc (which is a great tool!), something to ease the job of porting
>to Java in order to get better performance.
>
>I'm porting code by hand now.  It's pretty mechanical.  And the
>performance gain is dramatic.  If only it wasn't sooo tedious.
>
>BTW, after spending hours adding braces and semicolons and "new" and
>*obvious* data types, etc. to transform Jython to Java, I now think of
>Java as simply Jython dressed in drag.  (Not that there's anything
>wrong with that!)

Try adding changing a method of an object in Java to remember the
differences....

Seriously, in case you will have to spend many more hours dressing
Jython in drag, you might consider getting your hands on the Python
pretty printer module and change its output to do a lot of
the work for you. You'll spend some hours before becoming
productive, though.

Ten years ago I would have used /usr/bin/sed to do a thing like this.
It might still work, too. I never got to know awk in depth, but
it might even be better.

Some alternatives:

Try and use a profiler to determine which
code to move to Java first. Where is that Jython profiler anyway?

Also it is quite possible to create a Java superclass for your
jython classes. This allows you to concentrate on the time critical
methods first, instead of moving whole classes at a time.

Actually I think creating Java superclasses and doing a bit
of manual profiling in Jython is the most effective use of your time.
Normally 80-90% of time is spent in 10-20% of the code.


Good luck,
Ype

Re: [Jython-users] jython to java?

[Samuele P. <pe...@in...>]

Hi.

A) Some general considerations

[John Mudd]
> Maybe there's a market for this sort of scenario.  Use a subset of
> Jython in exchange for the ability to switch to Java after the
> prototype solidifies.  Maybe both languages would benfit from
> collaboration.
As philosophy (unrelated to java) that's the niche (at least in term of 
promises) of Common Lisp System vendors, which still give a lot
of dynamism in the delivered version, and the pontential niche
of dylan (that didn't catch up), where you lose most of the dynamism
for performance in the delivered version of a program, but you
have full dynamism during development.

Having both dynamic language features (very good for RAD) and performance is not 
that simple:

the runtime/compiler should understand when you are not using them ;)


some possible approach are

1) optional static typing over a basically dynamic typed language
   and/or giving up  (implicitly/explicitly)   
   with some dynamic aspects of semantic in deployed versions.
2) dynamic (at runtime) compilation and optimisation techniques
3) closed world assumption (take a whole program and compile it =>
you lose dynamic linking or dynamic linked stuff is much slower than the rest)
  this simplifies type inference and allows vtbls like techniques etc
4) type inference (much a reasearch field in absence of any explicit
type information or implicit rules (like in ML)), mostly an open problem if one 
want dynamic loading: type inference for an object oriented program need
whole call graph construction that needs type inference results, a difficult
fix-point problem , algorithms exist but are "slow" and there are problems
dealing with reflective/introspective features of a language.

* java takes 1) to the extreme (it has static typing) and its runtimes use 2),
  you have dynamic linking
* dylan uses 1) and 3), AFAIK no dynamic linking in deployed versions of a 
program
* Self (a sun/stanford univerty project) takes 2 to the extreme, and some
  of the results of the project are used in java runtimes, such runtimes
  (java and even more Self) are very complex and complicated piece of software,
  AFAIK there is no open source project trying to do that kind of stuff,
  these techniques are not simply JIT.

Python and jython at the moment do not exploit any of these things,

1) and using a bit of 4) as an idea has been around for a long time,
let see if and what will happen with P3K.

What JimH was trying (as far as I have understood) was very experimental
and implied a lot of assumptions that are not true in general for python 
semantic, he was using 3) and mostly trying to detect numeric types.

Maybe a bit of 2) can be put in jython to improve its performance,
but using dynamic techniques over a static typed, typesafe and
dynamic compiling/optimizing runtime (the actual JVMs) is likely
to be difficult or impossible, memory consuming, and not worth the effort,
and the increased code base complexity.
Jython is ideal if you don't want performance or can solve your problems
with adding a reasonable amount of pure java.

****************************

[D-Man]
> Besides, unless the VM's do some
> real intelligent runtime optimizations it can't be as fast as C.  It
> is implemented in C.  Every Java instruction takes several C
> instructions to execute. 
The actual jvms try to do some intelligent runtime opt, on the
other hand what java gives you and what C gives is very different,
java has an effective oo dynamic linking, and when a program crash
you always get a nice stack trace etc

Java gives some performance, effective dynamic linking and gc,
a growing and rich set of libs.
But it's verbose and e.g. swing is slow.
For some kind of application the cons are very important, like
complicated server frameworks that dynamicly load modules at runtime...
but in other cases one is better served elsewhere.

regards, Samuele Pedroni.

Re: [Jython-users] jython to java?

[John M. <joh...@ya...>]

--- Samuele Pedroni <pe...@in...> wrote:
> Hi.
> 
> A) Some general considerations
> 
> [John Mudd]
> > Maybe there's a market for this sort of scenario.  Use a subset of
> > Jython in exchange for the ability to switch to Java after the
> > prototype solidifies.  Maybe both languages would benfit from
> > collaboration.
> As philosophy (unrelated to java) that's the niche (at least in term
> of 
> promises) of Common Lisp System vendors, which still give a lot
> of dynamism in the delivered version, and the pontential niche
> of dylan (that didn't catch up), where you lose most of the dynamism
> for performance in the delivered version of a program, but you
> have full dynamism during development.

----snip----

Thanks for the detailed explanation.  On one hand it's a bit
intimidating for me.  I tend to oversimplify problems.  But, OTOH, it
is encouraging that others have already seen and tried to scale the
same mountain.  I trust that given enough time someone will surely make
it to the top.


> 
> 1) and using a bit of 4) as an idea has been around for a long time,
> let see if and what will happen with P3K.
> 

P3K?  I had no idea.  My expectations are now officially running
wild...

---snip-----

> 
> regards, Samuele Pedroni.
> 


__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices.
http://auctions.yahoo.com/