Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Python, Ruby, and Javascript are Slow

speakerdeck.com

Post reply on HN
Print view View original

81–90 of 203 posts

Re: Why Python, Ruby, and Javascript are Slow

#81

Post by ynniv »

timtadh wrote: post #42
ynniv wrote: post #32

Earlier quoted context omitted.

Meh, when there's an io call or a network request in front of the computation you'll never know. EDIT: removed an additional comment about scientific computing that is now relevant as someone replied to it.

[Edit: the parent originally had a sentence about not understanding why people like Python for Scientific Computing. This was my response to that. The parent has now removed the sentence.] We (the people using Python for Scientific Computing) like Python for the following reasons: 1. Numpy+Scipy+matplotlib+cvxopt is a very speedy environment. Its only real competitor for what it provides is MatLab. I have a colleague…

Sorry, I decided that it wasn't important before you replied. I am genuinely interested in why people use python for scientific computing, tho.

I have a colleague who bench marked Python vs. Matlab for our workload. Python is faster

Is it also faster than C? From my limited experience, it seems that people sometimes spend a lot of time on concurrency when faster code would have been easier.

This generally involves doing math on paper. Then implementing it.

Ah, yes, math always wins. This reinforces your point #2.

So, is #2 that much of a win? Do scientific programs spend more time in "development" than "production"?

Re: Why Python, Ruby, and Javascript are Slow

#82

Post by simonster »

arocks wrote: post #2

It is almost time that people stop referring to Languages as Fast or Slow. It is an implementation that is fast or slow, not a language.

It's true that implementation makes a bigger difference to performance than language features, but language features can indeed affect speed. One clear example is that a language that checks for integer overflow will be slower than a language that doesn't. There are a lot of situations where there's no way you could optimize out the extra instructions you'd need to check for overflow.

Some language features are easy to optimize away for some common cases (e.g. array bounds checks, so that your program throws an exception instead of segfaulting), but you can't optimize these if, for example, you're iterating over data you read from a file using indices you also read from that file.

Re: Why Python, Ruby, and Javascript are Slow

#83

Post by jholman »

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.

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 computational throughput. One maybe doesn't care in scientific computing, but game developers are always going on about how they can't use a GC language because a stall mid-frame will knock them over 16ms/frame or 33ms/frame, which for console certification is a project-killer.

Re: Why Python, Ruby, and Javascript are Slow

#84

Post by mixmastamyk »

Question:

    def squares(n):
        sq = []
        for i in xrange(n):
            sq.append(i*i)
        return sq

    A basically idiomatic version of the same in Python. No list
    pre-allocation, so every iteration through the list we have the
    potential to need to resize the list and copy all the data. That's
    inefficient.
Is that true? I'd expect .append() to change a pointer or two, not "resize and copy" the list. Even an .insert() should just move pointers at the C-level... no need to "defrag" it. I guess the key word is potential.

Re: Why Python, Ruby, and Javascript are Slow

#85

Post by masklinn »

defen wrote: post #54

Back when I wanted to investigate the numeric performance of v8 I wrote a Runge-Kutta integrator + Lorenz attractor in C and in JavaScript as a simple-but-not-entirely-trivial benchmark. I was actually pretty impressed with how fast the v8 version was. On the downside, it's fairly non-idiomatic js and not that much nicer to look at than the C. Doing a million steps on my machine takes 0.65 seconds in node.js v0.8.4,…

> Back when I wanted to investigate the numeric performance of v8

Straightforward numerical computations really isn't a good jit benchmark, because numerical computations are by far the easiest thing to JIT, and JITted perfs are going to be much closer to AOT than in the general case (unless the problem can be vectorized an the AOT compiler is vectorizing, I don't think JITs can usually vectorize)

Re: Why Python, Ruby, and Javascript are Slow

#86

Post by chimeracoder »

mixmastamyk wrote: post #84

Question: def squares(n): sq = [] for i in xrange(n): sq.append(i*i) return sq A basically idiomatic version of the same in Python. No list pre-allocation, so every iteration through the list we have the potential to need to resize the list and copy all the data. That's inefficient. Is that true? I'd expect .append() to change a pointer or two, not "resize and copy" the list. Even an .insert() should just move pointe…

I believe you're correct - Python lists should be O(1) for appending[0].

[0] http://wiki.python.org/moin/TimeComplexity

Re: Why Python, Ruby, and Javascript are Slow

#87

Post by MBlume »

njharman wrote: post #16

Meh, MEH. I'm almost never waiting on my python code. I'm waiting on network or disk or database or joe to check in his changes or etc. I'm sure there are people who do wait. But that's why numpy, c extensions, all the pypy, psycho, and similar things exist. Python and more broadly "scripting" languages are for speed of development. Something else can take on speed of execution faster than 90% of people need it to be…

If you're completely satisfied with Python's performance, that's wonderful. It means the talk wasn't aimed at you. Move along.

Re: Why Python, Ruby, and Javascript are Slow

#88

Post by jholman »

kingkilr wrote: post #78

Author/speaker here: I don't have time to read all the comments now (thanks for all the interest though!). I just want to say I think when the video comes out it'll answer a lot of questions people are having.

I'm looking forward to the video. I'm also interested in proof of the "lame myths" claims, or links to debunkings of those myths, etc. And also if you have rants about those If There's Time topics in your last slide, I'd like to read those too. Thanks!

Re: Why Python, Ruby, and Javascript are Slow

#89

Post by nicholassmith »

tptacek wrote: post #62
lucian1900 wrote: post #58

Earlier quoted context omitted.

I would say that the difference between fast Python code and C is still quite large. - the syntax is less error-prone - ownership semantics are much clearer. You'll never segfault because you sent some memory into the wrong function - not as much detail is needed for memory layout, the JIT abstracts a lot of it away - there are high-level APIs handy - development and distribution are simpler with one less language -…

I'm interested in this discussion. Which of those issues could you dispense with using more modern APIs and idioms in C? Look at Objective C (mentally wipe off all the object goo), particular NSMutableString and NSMutableArray and NSMutableData, for examples of what I'm thinking about. The C syntax we're stuck with. But how big a deal is that syntax? Segfaults are mitigated if you don't expose pointers, except to the…

The crux of the argument seems to come down to trading on optimised development time versus optimised execution time. C with the right set of APIs could nail both of those, which is no slight to Python. Look at BIND, they've gone mixed C++/Python because they know you use the right language when you need it, and don't get religious.

Re: Why Python, Ruby, and Javascript are Slow

#90

Post by moreati »

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):
        return [i*i for i in xrange(n)]
    $ PYTHONPATH=. python -m timeit -s "from squares import squares_append" "squares_append(1000)"
    10000 loops, best of 3: 148 usec per loop
    $ PYTHONPATH=. python -m timeit -s "from squares import squares_comprehension" "squares_comprehension(1000)"
    10000 loops, best of 3: 74.1 usec per loop
    $ PYTHONPATH=. pypy -m timeit -s "from squares import squares_append" "squares_append(1000)"
    10000 loops, best of 3: 46.9 usec per loop
    $ PYTHONPATH=. pypy -m timeit -s "from squares import squares_comprehension" "squares_comprehension(1000)"
    100000 loops, best of 3: 8.67 usec per loop
I'm curious to know how many allocations/copies a list comprehension saves in CPython/PyPy. However I wouldn't begin to know how to measure it.
Post reply on HN