Why Python, Ruby, and Javascript are Slow

Post by cheald » Sat, Mar 02, 2013, 3:24 AM UTC

tptacek wrote: post #27

cheald wrote: post #4

Kind of a poorly-named deck. It's really about why programs use features of these languages that end up causing poor performance relative to C, rather than why the individual VMs themselves are slow. It's no surprise that trading the byte-precision of C for the convenience of a garbage collector and heap-allocated data structures results in a performance decrease. Dynamically-typed languages are often easier to progr…

Did you read the deck? The GC isn't the problem; it's layout and management of allocations that's the problem, whether you use a garbage collector or explicit deallocation to clean up the resulting mess. I think the idea that GC is what slows down dynamic languages has to be the most prevalent misconception about language performance.

Post by cheald » Sat, Mar 02, 2013, 3:33 AM UTC

jholman wrote: post #83

tptacek wrote: post #27

Earlier quoted context omitted.

Did you read the deck? The GC isn't the problem; it's layout and management of allocations that's the problem, whether you use a garbage collector or explicit deallocation to clean up the resulting mess. I think the idea that GC is what slows down dynamic languages has to be the most prevalent misconception about language performance.

Yeah. I dunno about "most prevalent", though. TFA contained two "lame excuses", both of which are things I believed to be causes of slowness in dynamic languages, and now I have to reconsider. dynamic typing prevents type-based optimization monkey patching prevents optimization I think the most common complaint I hear about GC is not that it affects computational throughput, but that it affects _predictability_ of co…

Post by pjscott » Sat, Mar 02, 2013, 4:22 AM UTC

omaranto wrote: post #148

pjscott wrote: post #127

Earlier quoted context omitted.

Well, my usual answer there is to change the file extension to .pyx and see what Cython can do with a few type annotations. Usually the results are pretty good, and sometimes they're very good.

Does Cython give you much better results than PyPy? I would have thought that if just a few type annotations make a big difference tracing in PyPy could figure them out.

Post by ericmoritz » Sat, Mar 02, 2013, 7:11 AM UTC

moreati wrote: post #90

Great presentation, thank you for making me aware of an aspect of Python performance. One slide struck me as odd - the "basically pythonic" squares() function. I understand it's a chosen example to illustrate a point, I just hope people aren't writing loops like that. You inspired me to measure it $ cat squares.py def squares_append(n): sq = [] for i in xrange(n): sq.append(i*i) return sq def squares_comprehension(n)…

    from numpy import arange

    def squares_numpy(n):
        a = arange(n)
        return a * a

    $ python -m timeit -s "from squares import squares_append" "squares_append(1000)"
    10000 loops, best of 3: 130 usec per loop
    $ python -m timeit -s "from squares import squares_comprehension" "squares_comprehension(1000)"
    10000 loops, best of 3: 95.4 usec per loop
    $ python -m timeit -s "from squares import squares_numpy" "squares_numpy(1000)"
    100000 loops, best of 3: 5.31 usec per loop

Post by ubernostrum » Sat, Mar 02, 2013, 7:29 AM UTC

sb wrote: post #112

DannyBee wrote: post #93

Speaking as a compiler guy, and having a hand in a few successful commercial JITs: The only reason he thinks they aren't slow is because they haven't yet reached the limits of making the JIT faster vs the program faster. Yes, it's true that the languages are not slow in the sense of being able to take care of most situations through better optimization strategies. As a compiler author, one can do things like profile…

Interesting point of view, the problem in compiler construction is well known ("Proebsting's law", though it says it's more like 18 years instead of 10.) The issue with benchmarks is surely well known, also by the PyPy authors; I wonder what the biggest application is that they have benchmarked or that runs on PyPy. Your point on the JIT compiler interrupting program execution is certainly valid, too, but not necessa…