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

101–110 of 203 posts

Re: Why Python, Ruby, and Javascript are Slow

#101

Post by defen »

masklinn wrote: post #85
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)

Yup...I wanted to try to quickly measure just how good the JIT was for that kind of stuff, to see if we were getting to the point where it's feasible to do physics in the browser. Turns out it's "fast enough", and yet still 5x slower than equivalent stock C.

Re: Why Python, Ruby, and Javascript are Slow

#102

Post by Zak »

The creators of Common Lisp knew what Alex is talking about. Lisp is, of course just as dynamic as Ruby, Python or Javascript, but it exposes lower-level details about data structures and memory allocation iff the programmer wants them.

Features that come to mind include preallocated vectors (fixed-size or growable), non-consing versions of the standard list functions and the ability to bang on most any piece of data in place. There are fairly few situations in which a CL program can't come within a factor of 2 or 3 of the performance of C.

Re: Why Python, Ruby, and Javascript are Slow

#103

Post by [deleted] »

jholman wrote: post #99
doktrin wrote: post #91

Earlier quoted context omitted.

Being fairly new to C, is appending to / dynamically growing an array really just a matter of "a pointer or two"? How can you take for granted the memory space past the end pointer is available?

On an array, you can't. This means that you can't on a Python list, either. mixmastamyk is mistaken about the implementation details. But if you assume that "list" means "linked list", then you can just navigate to the correct part of the list, allocate enough space for one new cell, and stitch together a few pointers. Allocation and stitching is O(1). In general, navigating to part of the list is O(n), but if your l…

[deleted]

Re: Why Python, Ruby, and Javascript are Slow

#104

Post by mixmastamyk »

jholman wrote: post #97
chimeracoder wrote: post #86

Earlier quoted context omitted.

I believe you're correct - Python lists should be O(1) for appending[0]. [0] http://wiki.python.org/moin/TimeComplexity

I think you're both right and wrong. mixmastamyk's comment implies that (s)he believes that Python lists are, under the hood, linked lists. This is wrong. Python lists are ultimately backed by C arrays. This is why get() and set() are O(1), and insert() is O(n). However, dynamically resizing an array to support append operations, if you're not stupid, takes amortized constant time. Individual operations may be O(n).…

Yes, I've always just assumed that internally a resizable Python list was a linked-list I learned about in C... fits perfectly.

I suppose using an array must improve performance in typical cases, while the resizing (a linked-list advantage) happens less often.

Re: Why Python, Ruby, and Javascript are Slow

#105

Post by koenigdavidmj »

andolanra wrote: post #80
CJefferson wrote: post #57

One main thought on this topic -- languages like Haskell and lisp also have very poor support for direct memory control, but tend to be viewed (perhaps untruthfully?) as much closer in performance to C than Python/Ruby.

Haskell and languages in the ML family have a lot of opportunities for elaborate static analysis, which often allows the resulting programs to be quite clever about optimizing the resulting programs. As one example, the GHC Haskell compiler uses loop fusion to combine multiple passes over a list into a single pass with no intermediate copies of the list produced. Consequently, Haskell code like map f (map g (map h so…

In the Haskell case you could also do something like this to avoid needing that optimisation:

  map (f . g . h) someList
And in Python 3, map returns an iterator, not a list, so you aren't building the full list until you ask for it, and you never build intermediate lists in your example. You can do the same thing in Python 2 with the itertools.imap function.

Re: Why Python, Ruby, and Javascript are Slow

#106

Post by marmaduke »

ynniv wrote: post #81
timtadh wrote: post #42

Earlier quoted context omitted.

[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 do…

There is no "production" in scientific programs. It runs once correctly to make the figure... more seriously, ontology is often a moving target, so the longer in takes to rewrite significant parts of the data structures, the less time there is to do science.

re: concurrency: I have a script that boots hundreds of IPython workers on hundreds of cores. I then make a client object (in antoher IPython shell), and map my 1e8 parameter configurations on to the cores, all in under a minute. This is much faster than rewritng in C.

I even implemented a special case of the brain simulator we've developed in Python (http://thevirtualbrain.org/) in C w/ unaliased pointer arithmetic etc. It's 50% faster but took more than 50% longer to write; on the other hand the PyCUDA implementation is 80x faster, and didn't take 80x, maybe 10x. Also a win because PyCUDA takes care of the uglier details.

so #2 is a big win

Re: Why Python, Ruby, and Javascript are Slow

#107

Post by voyou »

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…

Python lists are contiguous blocks of memory (i.e., arrays), not linked lists, so append will sometimes have to resize and copy. It's true that amortized worst case time is O(1), but that's still going to take longer than the one allocation involved in pre-allocating an array of known size. I don't know whether (or, under what circumstances) the difference is large enough to be significant, though.

Re: Why Python, Ruby, and Javascript are Slow

#108

Post by d0mine » 

    atoi(strchr(s, '-') + 1)
What does this do? Finds the first instance of a -, and converts the remainder of a string to an int. 0 allocations, 0 copies. Doing this with 0 copies is pretty much impossible in Python, and probably in ruby and Javascript too.

The copying could be avoided in non-idiomatic Python:

    int(buffer(s, s.find("-") + 1))

Re: Why Python, Ruby, and Javascript are Slow

#109

Post by ynniv »

marmaduke wrote: post #106
ynniv wrote: post #81

Earlier quoted context omitted.

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 do…

There is no "production" in scientific programs. It runs once correctly to make the figure... more seriously, ontology is often a moving target, so the longer in takes to rewrite significant parts of the data structures, the less time there is to do science. re: concurrency: I have a script that boots hundreds of IPython workers on hundreds of cores. I then make a client object (in antoher IPython shell), and map my…

It's 50% faster but took more than 50% longer to write

At this point it's useful to know how long it takes to run, and how long to write. Is a run days long, months long, or years long? Or another way, is concurrency more expensive than a C re-programmer?

Also a win because PyCUDA takes care of the uglier details.

Is there not an analogous C++ library to take care of ugly details?

(I actually like python a lot, so there's a bit of devil's advocate going on. But, my longest running python programs take less than an hour.)

Re: Why Python, Ruby, and Javascript are Slow

#110

Post by jewel »

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…

To counter the overhead of the JIT algorithm, would it be possible to do that work in a background thread or cache the JIT optimizations to disk?
Post reply on HN