Is a "real" C-Python possible?

[MonkeeSage]

On Dec 11, 3:10 am, Duncan Booth <duncan.bo... at invalid.invalid> wrote:
> sturlamolden <sturlamol... at yahoo.no> wrote:
> > On 9 Des, 23:34, Christian Heimes <li... at cheimes.de> wrote:
>
> >> >http://antoniocangiano.com/2007/11/28/holy-shmoly-ruby-19-smokes-pyth
> >> >...
>
> >> The Ruby developers are allowed to be proud. They were able to
> >> optimize some aspects of the implementation to get one algorithm
> >> about 14 times faster. That's good work. But why was it so slow in
> >> the first place?
>
> > The thing to notice here is that Congiano spent 31.5 seconds computing
> > 36 Fibonacci numbers in Python and 11.9 seconds doing the same in
> > Ruby. Those numbers are ridiculous! The only thing they prove is that
> > Congiano should not be programming computers. Anyone getting such
> > results should take a serious look at their algoritm instead of
> > blaming the language. I don't care if it takes 31.5 seconds to compute
> > 36 Fibonacci numbers in Python 2.5.1 with the dumbest possible
> > algorithm.
>
> Quite so.
>
> Take something likehttp://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/498110
> and then modify the Python code from the "Ruby smokes Python" article by
> the addition of @memoize(3) to decorate the otherwise unchanged fib
> function: the Python runtime drops down to 0.002 seconds.
>
> That is just slightly better than Ruby's 11.9 seconds although I'm sure the
> Ruby code would also gain as much from a memoize decorator.
>
> from memoize import memoize
>
> @memoize(3)
> def fib(n):
>    if n == 0 or n == 1:
>       return n
>    else:
>       return fib(n-1) + fib(n-2)
>
> from time import clock
> start = clock()
> for i in range(36):
>     print "n=%d => %d" % (i, fib(i))
> print clock()-start
>
> When I run this (with output directed to a file: I'm not trying to time
> windows console speed), the output is:
>
> n=0 => 0
> n=1 => 1
> n=2 => 1
> n=3 => 2
> n=4 => 3
> n=5 => 5
> n=6 => 8
> n=7 => 13
> n=8 => 21
> n=9 => 34
> n=10 => 55
> n=11 => 89
> n=12 => 144
> n=13 => 233
> n=14 => 377
> n=15 => 610
> n=16 => 987
> n=17 => 1597
> n=18 => 2584
> n=19 => 4181
> n=20 => 6765
> n=21 => 10946
> n=22 => 17711
> n=23 => 28657
> n=24 => 46368
> n=25 => 75025
> n=26 => 121393
> n=27 => 196418
> n=28 => 317811
> n=29 => 514229
> n=30 => 832040
> n=31 => 1346269
> n=32 => 2178309
> n=33 => 3524578
> n=34 => 5702887
> n=35 => 9227465
> 0.00226425425578

Another point is, the reason the ruby code shows such a performance
increase is because of the way it wraps native (C) types for integers
in the the new byte compiler; i.e., it's a directed optimization,
which the example code exploits to its full extent. But with
dictionary access, for example, python still creams ruby (by a 2/1
factor in my tests). Speaking as someone who uses both python and
ruby, I can say that ruby 1.9 is approaching python's speed, which is
very cool, but is still not quite as fast as python in general (the
whole "smokes python" bit is just propaganda that utilizes a specific
feature vector, and is generally unhelpful).

Regards,
Jordan