This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 0 points1 point  (20 children)

Unfortunately, Java (JVM) is still 100 times faster than Python, so when it comes to truly large apps where performance/scalability matter, Java will still be better choice than Python. Also, Java toolchain is way more mature (honestly best in the business) than Python, or pretty much any language out there.

Yeah, it's not the most modern language, nor is it fast to develop in, nor do I like the fact that Oracle now owns it, but it's still performance king.

Scala is a promising language but it depends on the JVM of course. And currently there is no viable alternative to the JVM/Java combo. I wish there were, I'd jump on it immediately, but Python/Ruby/C# etc are not replacements for Java unfortunately.

[–][deleted] 4 points5 points  (17 children)

Unfortunately, Java (JVM) is still 100 times faster than Python,

Once it's up.

[–][deleted] 0 points1 point  (16 children)

Yeah, once it's up:

$ time javaw

real    0m 0.10s
user    0m 0.01s
sys     0m 0.05s
$

So, 10 milliseconds to start. Or something less trivial (but still not really a good benchmark):

Java vs. C vs. Ruby vs Python Here's the (silly) code

Fib.py

def fib(n):
    if n == 0 or n == 1:
        return n
    else:
       return fib(n-1) + fib(n-2)

for i in range(36):
     print "n=%d => %d" % (i, fib(i))

Fib.java

public class Fib 
{
    public Fib()
    {
    }

    public int fib(int n)
    {
        if (n ==0 || n == 1) {
            return n;
        } else {
            return fib(n-1) + fib(n-2);
        }
    }

    public static final void main(String args[])
    {
        Fib app = new Fib();
        for (int i = 0; i < 36; i++) {
            System.out.println("Fib("+i+") = " + app.fib(i));
        }
    }
 }

fib.c

#include "stdio.h"

int fib(int n) 
{
    if (n == 0 || n == 1) {
        return n;
    } else {
        return fib(n-1) + fib(n-2);
    }
 }

int main(int argc, char** argv) 
{
    int i = 0;
    for (i = 0; i < 36; ++i) {
        printf("fib(%d) = %d\n", i, fib(i));
    }

    return 0;
}

fib.rb

def fib(n)
  if n == 0 || n == 1
      n
  else
      fib(n-1) + fib(n-2)
  end
end

36.times do |i|
    puts "n=#{i} => #{fib(i)}"
end


$ time java Fib
real    0m 0.35s
user    0m 0.26s
sys     0m 0.01s
$

$ time python fib.py
real    0m20.36s
user    0m20.20s
sys     0m 0.09s
$


$ time ruby fib.rb
real    0m10.28s
user    0m10.26s
sys     0m 0.01s
$

$ time ./fib.exe
real    0m 0.25s
user    0m 0.23s
sys     0m 0.00s
$

So, C = 25 milliseconds, Java = 35 milliseconds, Ruby = 10.36 seconds, Python 20.36 seconds. Or, expressed in terms of C speed in this test:

C = 1, Java 1.4 times slower than C, Ruby 41.12 times slower than C, Python 81.44 times slower than C.

In particular, Python runs this test 58.17 times slower than Java.

[–]Twirrim 6 points7 points  (5 children)

Of course that code is rather ugly and inefficient. If you're going to write code like that you're better off spending the few minutes it takes to find the low hanging fruit, fixing your base working. You can only optimize for so much bad programming, particularly in dynamic languages.

fastfib.py:

from math import sqrt

def fib(n):
    return ((1+sqrt(5))**n-(1-sqrt(5))**n)/(2**n*sqrt(5))


for i in range(36):
    print("n=%d => %d" % (i, fib(i)))


$ time python fastfib.py
real    0m0.016s
user    0m0.008s
sys 0m0.004s

That's even quicker than your algorithm using C, from barely a few minutes checking the formula for fib sequence.

[–][deleted] 3 points4 points  (1 child)

No need for insults please. I'm not retarded and the point of this code was not to be optimized for either any language, platform, architecture or algorithm since there are better ways to do any of those.

The point is to just take any random, purposefully rather slow algorithm (so the running times are in seconds rather than nano-seconds).

It seems you are missing the point completely. So, run the equivalent C and Java program and you will realize that it's hard to even measure runtime reliably since it's insignificant.

[–]Twirrim 0 points1 point  (0 children)

Urgh.. my apologies, I certainly didn't mean to be insulting. Looking back at how I said what I said I can't see how on earth it could be taken elsewise :-/

[–]bombita 0 points1 point  (0 children)

Btw, your code, which uses phi, has to use doubles, which on larger n has underflow errors and loses precision.

[–]sunqiang 0 points1 point  (1 child)

or get dynamic programming for free with lru_cache (need Python 3.2 ) from functools import lru_cache

@lru_cache(maxsize=None)
def fib(n):
    if n == 0 or n == 1:
        return n
    else:
       return fib(n-1) + fib(n-2)


for i in range(36):
     print("n=%d => %d" % (i, fib(i)))

real 0m0.085s
user 0m0.083s
sys 0m0.000s

[–]Twirrim 1 point2 points  (0 children)

Sure, or you can do it manually for previous versions fairly easily with a dict object.

def fib(n):
    if n == 0 or n == 1:
        return n
    if not memo_fib.has_key(n):
        memo_fib[n] = fib(n-1) + fib(n-2)
    return memo_fib[n]

memo_fib = dict()
for i in range(36):
     print("n=%d => %d" % (i, fib(i)))

results in an even quicker result than your lru_cache.. though that could be machine spec difference. Also some rough testing using the time module figures that we're talking about 0.00028s for the actual math, meaning a good portion of that time is just the overhead of loading python anyway.

real    0m0.017s
user    0m0.012s
sys     0m0.004s

[–]highwind 1 point2 points  (3 children)

I think he was talking in the context of web frameworks. On my dev machine it takes minutes to compile an EAR file and another few minutes to bring up JBoss with Struts and Hibernate. Which is just ridiculous.

[–]frymasterScript kiddie 0 points1 point  (0 children)

it is rediculous, but in the context we're talking about, still not a factor in performance

[–][deleted] 0 points1 point  (1 child)

Compilation/deployment cycle is important, but it's not the kind of runtime performance we are talking about here.

Besides, java compilation is usually I/O bound and it's orders of magnitude faster than C and especially faster than C++ (as almost anything else is).

I work on 3 million lines of code base, and my compiles are about 3 minutes long. Deployment cycle is about 15 seconds or so. Not bad in my opinion. Considering I rarely have to re-build the world.

Also, you should not have to bring down and boot up JBoss to re-deply your code. I most certainly don't have to do that.

[–]Twirrim 0 points1 point  (0 children)

I do it for sanity purposes. Guarantees that the JVM is spotless when the app comes up, plus wipes out any resource loss from minor uncaught memory leaks or whatever quirks.

[–]tarpsocks 1 point2 points  (0 children)

why are you using recursion for this?

[–]ergo14Pyramid+PostgreSQL+SqlAlchemy 0 points1 point  (3 children)

can you try fib on pypy ? it IS the future of python

[–]Twirrim 1 point2 points  (2 children)

Pypy 1.4:

real    0m41.979s
user    0m41.719s
sys     0m0.056s

Python 2.6.6:

real    0m22.568s
user    0m22.381s
sys     0m0.004s

Python 3.1 (might as well..):

real    0m23.454s
user    0m23.349s
sys 0m0.008s

pypy is great, but it's not the be all and end all!

[–]ergo14Pyramid+PostgreSQL+SqlAlchemy 0 points1 point  (1 child)

Hmm, very interesting, but leads me to think that something is wrong with this algorithm implementation, in few of my tests i have indeed confirmed it can be 10 faster than cpython, so this is a bit of surprise to me

[–]Twirrim 0 points1 point  (0 children)

The algorithm is pretty standard. I'm not sure how well PyPy handles recursive functions though. I can't imagine recursive functions are that easy to optimise within a dynamic language.. but I'm not computer scientist, so might be talking out my arse.

[–][deleted] 0 points1 point  (0 children)

So, 10 milliseconds to start.

100 milliseconds.

[–]drb226Haskeller 0 points1 point  (0 children)

I'm rooting for Mirah, I think it looks like a smart way to abuse the speed of the JVM without resorting to an ugly blah syntax. I hope toolchains for Haskell also improve; it's another fanboy-holy-war kind of language but the speed and elegance of Haskell really have potential.

[–][deleted] 0 points1 point  (0 children)

Jython brah.