slower than cpython 2.5?

[garyrob]

HI,

I tried running a large production process under Unladen Swallow
2009Q3 and it didn't seem any faster than CPython 2.5. So I tried
Unladen with a little loop:

x=0
while x < 100000000:
x+=1

Under CPython 2.5, this loop takes 15 seconds on my box, and 26 under
Unladen.

I do notice that the Fibonacci function presented at
http://code.google.com/p/unladen-swallow/wiki/Release2009Q2 does run a
bit faster with Q3 Unladen (I get about 14%).

So it seems like Unladen is at a point now where it'll run slower for
some things and faster for others.

Does this match others' experience? If so, is the Q4 release expected
to be *generally* faster, and something that most people looking for
speed will find useful?

Thanks,
Gary

[Reid Kleckner]

There's a couple reasons why that particular benchmark won't get much faster.

- We only JIT compile functions that we've detected are hot. If we
didn't do this, compilation time would dwarf runtime.
- Second, we don't have any on-stack-replacement like the JVM, which
lets them detect hot loops and switch over to using the compiled code
without waiting for the next function call.
- We've also made the eval loop a bit slower in order to record
statistics so we can generate better code, so if you end up only using
the eval loop like you are in this case, you get a slowdown. :(

If you want to force u-s to compile a piece of code, I think the
preferred way is to throw it in a function and set __use_llvm__ on the
code object like so:

import timeit
setup = """
def f():
x = 0
while x < 100000000:
x += 1
try:
f.__code__.__use_llvm__ = True
except AttributeError:
pass
"""
print timeit.Timer(stmt="f()", setup=setup).timeit(number=1)

I get the following results:

[reid@muikyl ~]$ python t.py
7.62441802025
[reid@muikyl ~]$ unladen-swallow/python t.py
4.34114408493

Obviously, we could do a lot better, but we've tried to focus on real
world Python code instead of short numeric loops that aren't
idiomatic. For example, Collin's done a lot of work speeding up
function calls to builtin C functions and caching module level globals
that don't change.

Reid

[garyrob]

Many thanks for your response. Very enlightening!

I have some follow-up questions:

1) It seems like the points you make could appropriately be on the
http://code.google.com/p/unladen-swallow/wiki/WritingOptimizableCode
page, yes? I was thinking of adding them myself but it looks like the
wiki is set up so that not just anybody can edit it. In any case, it
seems like there probably are other points that somebody knowledgeable
could add...

2) Is the __use_llvm__ functionality going to continue to be available
in u-s as it progresses, including when it's merged into CPython, or
is it just a temporary thing for the time being?

3) Are all types of methods (static, class, instance) , as well as
nested functions just as optimizable as regular functions; in
particular does the __use_llvm__ trick work?

Many thanks again!!
Gary

> >http://code.google.com/p/unladen-swallow/wiki/Release2009Q2does run a

[Alex Gaynor]

The __use_llvm__ thing actually applies to code objects, so yes,
anything with a code object exposed can be altered in that way.

Alex

--
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me

[Collin Winter]

Hi Gary,

On Fri, Nov 6, 2009 at 11:23 AM, garyrob <gary...@gmail.com> wrote:
> Many thanks for your response. Very enlightening!
>
> I have some follow-up questions:
>
> 1) It seems like the points you make could appropriately be on the
> http://code.google.com/p/unladen-swallow/wiki/WritingOptimizableCode
> page, yes? I was thinking of adding them myself but it looks like the
> wiki is set up so that not just anybody can edit it. In any case, it
> seems like there probably are other points that somebody knowledgeable
> could add...

I don't know that adding Reid's points to the WritingOptimizableCode
wiki page would really help. That page is intended for people writing
whole applications, not highly-synthetic micro-benchmarks. Similarly,
we don't really want to publicize __use_llvm__, which is mostly a tool
for testing code generation.

Thanks,
Collin Winter