even if JIT does equally well, it's basically O(n) vs. O(1), n being the number of runs of the program. unless the advantage of dynamic optimization outweighs the cost of runtime compilation it's unlikely to be more efficient than pre-runtime compilation.

Sean Kelly wrote:
> Jan Claeys wrote:
>>
>> And I think in the case of dynamic languages like Python, a JIT-compiler often can create much better code at run-time than a compiler could do when compiling it before run-time.
> 
> One issue with run-time optimization is its impact on performance.  A traditional compiler can take as long as it wants to exhaustively optimize an application, while a JIT-compiler may only optimize in a way that does not hurt application responsiveness or performance.  At SDWest last year, there was a presentation on C++ vs. Java performance, and one of the most significant factors was that most Java JIT-compilers perform little if any optimization, while C++ compilers optimize exhaustively. That said, JIT optimization is still a relatively new practice, and with more cores being added to computers these days it's entirely possible that a JIT optimizer could run on one or more background CPUs and do much better than today.
> 
> 
> Sean

Jascha Wetzel wrote:
>> It's *already* abstracted away from the target machine, why add another
>> layer of abstraction?
> 
> to have a format for distribution that's still abstract but not human
> readable.

There's no point to that, since there are very good bytecode => java source translators. Running your source through a comment stripper would be about as good.

Jan Claeys wrote:
> And I think in the case of dynamic languages like Python, a JIT-compiler
> often can create much better code at run-time than a compiler could do
> when compiling it before run-time.

That's the theory. In practice, Python programmers who need performance will develop a hybrid Python/C++ app, with the slow stuff recoded in C++.

Walter Bright wrote:
> Jascha Wetzel wrote:
>>> It's *already* abstracted away from the target machine, why add another
>>> layer of abstraction?
>>
>> to have a format for distribution that's still abstract but not human
>> readable.
> 
> There's no point to that, since there are very good bytecode => java source translators. Running your source through a comment stripper would be about as good.

What I find amazing is that a good bytecode => source translator for .NET will often produce the original source code... exactly.  I assume the information is all present for reflection purposes, but I've never been able to get over it.  The first time it was shown to me I expected to see some half readable mess, not a photographic duplicate of the original source code.


Sean

Walter Bright wrote:
> Jan Claeys wrote:
>> And I think in the case of dynamic languages like Python, a JIT-compiler
>> often can create much better code at run-time than a compiler could do
>> when compiling it before run-time.
> 
> That's the theory. In practice, Python programmers who need performance will develop a hybrid Python/C++ app, with the slow stuff recoded in C++.

In practice with Python I think what happens is more like:
1) make sure you're not doing something stupid.  If not ...
2) try psycho (a kind of JIT) (http://psyco.sourceforge.net).  If that doesn't help (it never has for me)...
3) rewrite slow parts in pyrex (http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/).  If that's not feasible then...
4) rewrite it as a native code module with Boost::Python or SWIG or just using the raw C API.  Or write a native shared library and use ctypes (http://python.net/crew/theller/ctypes/) to access it.

If you're doing numerical code then there are a couple of things you can try before resorting to rewriting.   numexpr (http://www.scipy.org/SciPyPackages/NumExpr) and scipy.weave (http://www.scipy.org/Weave).

And now of course you also have the option of rewriting the slow parts in D, thanks to Kirk.

--bb

isn't that mainly because Java's .class files also contain declarations? in general it shouldn't be so easy to translate intermediate code back to source code, especially if general optimizations have already been applied.

Walter Bright wrote:
> Jascha Wetzel wrote:
>>> It's *already* abstracted away from the target machine, why add another layer of abstraction?
>>
>> to have a format for distribution that's still abstract but not human readable.
> 
> There's no point to that, since there are very good bytecode => java source translators. Running your source through a comment stripper would be about as good.

Op Mon, 30 Apr 2007 11:51:07 -0700
schreef Sean Kelly <sean@f4.ca>:

> Jan Claeys wrote:
> > 
> > And I think in the case of dynamic languages like Python, a JIT-compiler often can create much better code at run-time than a compiler could do when compiling it before run-time.
> 
> One issue with run-time optimization is its impact on performance.  A traditional compiler can take as long as it wants to exhaustively optimize an application, while a JIT-compiler may only optimize in a way that does not hurt application responsiveness or performance.  At SDWest last year, there was a presentation on C++ vs. Java performance, and one of the most significant factors was that most Java JIT-compilers perform little if any optimization, while C++ compilers optimize exhaustively. That said, JIT optimization is still a relatively new practice, and with more cores being added to computers these days it's entirely possible that a JIT optimizer could run on one or more background CPUs and do much better than today.

Well, in practice most Python code just runs on the Python bytecode interpreter (and in most other cases on the Java or .NET VMs), and with a good reason.

Some code runs faster when using the third party 'psyco' JIT compiler (which only exists for x86 anyway), while other code gains nothing from it (and thus gets slower due to the additional compilation step). Fortunately you can also tell this JIT at runtime what you want to compile to native code and what not.

OTOH I think every attempt to compile Python code into native machine code beforehand until now has resulted in code that runs up to 100x _slower_ than the interpreter(!).  ;-)

The "problem" with Python is that it's dynamic, and so there is *nothing* known about anything that touches something outside the current module...


-- 
JanC

Jan Claeys wrote:
> Well, in practice most Python code just runs on the Python bytecode
> interpreter (and in most other cases on the Java or .NET VMs), and with
> a good reason.
> ...

The really interesting stuff on Python is happening over at the PyPy[1] project.  They're basically trying to write a Python interpreter in a restricted subset of Python called RPython, which can then be translated into other formats like C or LLVM.

One of the really weird things is that you can run various transformations over the RPython code to change how it works without ever having to rewrite any of the actual code.  The classic example of this is integrating Stackless Python into the interpreter by basically throwing a switch.

It's all very cool, and really hard to understand. :P

	-- Daniel

[1] http://codespeak.net/pypy/

-- 
int getRandomNumber()
{
    return 4; // chosen by fair dice roll.
              // guaranteed to be random.
}

http://xkcd.com/

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/

Op Mon, 30 Apr 2007 13:44:05 -0700
schreef Walter Bright <newshound1@digitalmars.com>:

> Jan Claeys wrote:
> > And I think in the case of dynamic languages like Python, a JIT-compiler often can create much better code at run-time than a compiler could do when compiling it before run-time.
> 
> That's the theory. In practice, Python programmers who need performance will develop a hybrid Python/C++ app, with the slow stuff recoded in C++.

Just like some people write libraries in Fortran or assembler or some vector processor language because C and C++ and D are "too slow".   ;-)

There is one commonly used JIT-compiler for Python ('psyco') and it is actually useful in some cases, while I haven't seen one single Python-to-native-code compiler that makes code that's actually faster than the interpreter in most cases...

Python's strength is its "dynamism" and ability to adapt to "unexpected" changes at run-time.  And the fact that Python developers write extensions in other languages if speed is really important and 'psyco' doesn't help proves that compiling Python to native code before it's run is not really a useful option.


-- 
JanC

Jan Claeys wrote:
> Just like some people write libraries in Fortran or assembler or some vector processor language because C and C++ and D are "too slow".   ;-)

Or out of sheer bloody-mindedness.

Funny thing, turns out SSE is actually *slower* for doing a dot product than regular old x87 code!

> There is one commonly used JIT-compiler for Python ('psyco') and it is actually useful in some cases, while I haven't seen one single Python-to-native-code compiler that makes code that's actually faster than the interpreter in most cases...
> 
> Python's strength is its "dynamism" and ability to adapt to "unexpected" changes at run-time.  And the fact that Python developers write extensions in other languages if speed is really important and 'psyco' doesn't help proves that compiling Python to native code before it's run is not really a useful option.

That's what I like about Python; it's a massively expressive language that doesn't get in your way if you need the speed.

Incidentally, it's called "dynamicysm".

*DRINK*

	-- Daniel

-- 
int getRandomNumber()
{
    return 4; // chosen by fair dice roll.
              // guaranteed to be random.
}

http://xkcd.com/

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/