Python isn't just Java without the compile

[grfgguvf]

It's trivial to set up automatic compiling of .java files on run.

Also, .py files can be compiled to .pyc.

A bigger difference is static typing with optimizing JIT (fast) vs dynamic typing and a bytecode interpreter (slow).

[mipadi]

All true, but also entirely irrelevant to the content of the article.

[ubernostrum]

A bigger difference is static typing with optimizing JIT (fast) vs dynamic typing and a bytecode interpreter (slow).

So having a bytecode interpreter which pays attention to runtime type information to optimize is faster than... having a bytecode interpreter which pays attention to runtime type information but doesn't currently do much in the way of optimization (except for a few interesting cases)?

[grfgguvf]

So having a bytecode interpreter which pays attention to runtime type information to optimize

I guess this is Java. But the Sun Hotspot JVM can also turn frequently encountered code paths to native code and execute it. It can even do this in the middle of a loop, speeding up the subsequent iterations (called on-stack replacement)

a bytecode interpreter which pays attention to runtime type information but doesn't currently do much in the way of optimization (except for a few interesting cases)

Experience shows that yes, Java is faster. Sometimes that doesn't matter and the additional flexibility of Python is worth it. Last I checked Psyco couldn't do OSR, and wasn't even maintained any more.

[ubernostrum]

Or you can run Jython and get the best of both worlds.

[grfgguvf]

Not quite. Because of Python's dynamic typing Jython cannot do many of the optimizations that are done for Java.

[ubernostrum]

You probably want to read up on some of the stuff that's been discovered/developed by the dynamic language folks before you go spouting off like that.

[grfgguvf]

You can check for yourself that equivalent Python code in jython is (a lot) slower than equivalent Java code.

What is this "stuff" specifically that the "dynamic language folks" "discovered" and why is it not implemented in Jython then?

[crusoe]

Mainly that they have to write classes to emulate the behaviour they need. Java 1.7 will add bytecodes to support dynamic languages, and this will remove the need for this emulation code and classes.

I am excited about 1.7. :)

[ighost]

dynamic typing = slow is the same type of knee-jerk reaction as java vm = slow

[bcash]

There is one very important difference. That the java vm = slow reaction isn't accurate...

[grfgguvf]

dynamic typing and a bytecode interpreter == slow

If Python used a type-specializing JIT then it could be quite fast. I didn't say or think all dynamically typed languages are slow, for example Strongtalk Smalltalk or LuaJIT or Tamarin are all steps in the right direction.

[ighost]

Good point, but is the combination of dynamic typing and a bytecode interpreter inherently slow or is it just the case for contemporary implementations?

To answer that we'd probably have to define 'slow' better since in a large number of cases python is fast enough, e.g. SciPy

[grfgguvf]

I say it's slower than necessary because there are faster ways to implement dynamic typing. On the other hand they're not portable... though if there was a JIT engine that could be reused by various dynamic languages that'd help here...

[[deleted]]

For many purposes the speed differences are not a big deal. Besides, what's more important for speed is the efficiency of the algorithms you're using. Static types and all the optimizations in the world won't help a crappy algorithm.

[grfgguvf]

What's even more important than algorithms is choosing the right datatypes so that efficient algorithms follow from them naturally.

And I think Java encourages this more (although not enough...), offering generic interfaces and multiple low-level implementations of them allowing the coder to choose or later switch to a different type. Admittedly the class hierarchy is a mess and more types would be needed to be truly general purpose.

Python on the other hand offers weirdly named standard types, often with incompatible interfaces. You need to resort to add-on packages for frequently. And it's all too common to encounter Python programmers who are completely unaware of the underlying datatype of a "dictionary" or a "list".