D vs VM-based platforms

Jan Claeys usenet at janc.be
Mon Apr 30 17:50:54 PDT 2007


Op Mon, 30 Apr 2007 11:51:07 -0700
schreef Sean Kelly <sean at 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



More information about the Digitalmars-d mailing list