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

141–150 of 203 posts

Re: Why Python, Ruby, and Javascript are Slow

#141

Post by antrix »

DannyBee wrote: post #125
pcwalton wrote: post #119

Earlier quoted context omitted.

Background compilation in a separate thread actually works pretty well. IE9 has been shipping it with Chakra for a while, and Firefox is now getting it (and it improved the benchmarks a lot, especially on ARM).

Good to hear it's gotten better. Admittedly, I wasn't thinking about browser based JITs when I said that :) I'm actually curious if you have any stats on how much of the time this is being done on actual busy machines where it's going to compete for L1/etc resources vs how often it's able to be offloaded onto an otherwise empty core. IE i expect their to be a significant difference in the use cases for JIT's like PyP…

> Admittedly, I wasn't thinking about browser based JITs when I said that :)

Don't HotSpot and JRockit also do background (de)compilation & swapping of generated code?

Re: Why Python, Ruby, and Javascript are Slow

#142

Post by PeterisP »

metaphorm wrote: post #134
PeterisP wrote: post #123

Earlier quoted context omitted.

On the other hand, why should the abstraction layers prevent that? I mean, abstraction layers abstract away the [hopefully] unimportant low-level choices from me - but "copy or not copy" or "allocate once or allocate thrice" isn't a choice that I need to make anyway; the abstraction layer simply should make the 'non-copy' choice for me. Exactly the same way that the C abstraction layer right now makes the proper opco…

its not always possible to go with the "non-copy" choice. for example, there are very good reasons for having immutable strings, and once you've made that choice at the language level every string function you write is going to copy at least once. I think Alex Gaynor is correct and that basically what is wrong at the moment is that dynamic languages lack API's that have any sensitivity to performance concerns. There'…

Compilers can work around that choice - if you want to do something with immutable strings (like the Haskell example I mentioned, it does have immutable strings) then you will have to make some copy, but you don't need to make a copy per every function - if you're stringing three string functions in a row, the compiler can "fuse" the processing so that only a single, final copy is made, not the intermediate ones.

For any language the compiler may know which variables won't ever be used - for example in pseudocode

  b = a.lowercase()
  c = b.replace("x","y")
  d = a.lowercase.replace("x","y")
both 'b' and the intermediate result in 'd' are strings, but the compiler can flag these two 'throw-away' variables as mutable strings (while still maintaining the promise that all programmer-visible strings will be immutable); and you may have a special version of 'replace' standard function that does no-copy, in-place replacement in such cases. It means extra work in building API/stdlib, but brings better performance for the same programs.

Re: Why Python, Ruby, and Javascript are Slow

#143

Post by kristianp »

As a ruby lover, I'm interested in the ruby implementation the Author wrote and mentioned, topaz [1]. Has anyone here tried it?

"Topaz is a high performance implementation of the Ruby programming language, written in Python on top of RPython (the toolchain that powers PyPy)."

[1] http://docs.topazruby.com/en/latest/

Re: Why Python, Ruby, and Javascript are Slow

#144

Post by jholman »

metaphorm wrote: post #136
jholman wrote: post #111

Earlier quoted context omitted.

Resizing is not a linked-list advantage, though. Resizing is an ammortized-constant-time operation. The only advantage I'm aware of for linked lists is insert and delete (but not append and pop), which are constant time in a linked list but O(n) in an array. The thing is, though, that doing insert() on a linked-list usually requires a seek first. Which is O(n) on a linked-list (and may be O(n), O(logn), or O(1) on an…

linked lists are the default data structure underlying almost every implementation of Stacks and Queues and the variants of those. they're far from useless. they're also such a flexible data structure that it is literally the ONLY data structure necessary to implement any of the LISPs.

> linked lists are the default data structure underlying almost every implementation of Stacks and Queues

Citation needed. I doubt this.

Certainly if I had only ten minutes to implement a stack or a queue, without access to anything more than stdlib.h (or equivalent), a linked list is easy to get right in a hurry, and only takes a few dozen lines. But the auto-resizing array is only a little harder, and has better performance for nearly every operation, as I explained in the previous post.

> they're also such a flexible data structure that it is literally the ONLY data structure necessary to implement any of the LISPs.

Of course. So what? That's not a reason to use them anywhere other than a school assignment that requires you to use them.

Re: Why Python, Ruby, and Javascript are Slow

#145

Post by lutusp »

jholman wrote: post #144
metaphorm wrote: post #136

Earlier quoted context omitted.

linked lists are the default data structure underlying almost every implementation of Stacks and Queues and the variants of those. they're far from useless. they're also such a flexible data structure that it is literally the ONLY data structure necessary to implement any of the LISPs.

> linked lists are the default data structure underlying almost every implementation of Stacks and Queues Citation needed. I doubt this. Certainly if I had only ten minutes to implement a stack or a queue, without access to anything more than stdlib.h (or equivalent), a linked list is easy to get right in a hurry, and only takes a few dozen lines. But the auto-resizing array is only a little harder, and has better pe…

> > linked lists are the default data structure underlying almost every implementation of Stacks and Queues

> Citation needed. I doubt this.

As do I. Since you're not going to reorder a stack or (in most cases) a queue, and since they contain fixed-size elements, what's the point of a linked list?

Re: Why Python, Ruby, and Javascript are Slow

#146

Post by marcosdumay »

ynniv wrote: post #109
marmaduke wrote: post #106

Earlier quoted context omitted.

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

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

No. In general, there isn't an analogous library at the more static-explicit languages (it doesn't matter much what library you choose). There are libs that people use when they have similar requisites, but they rarely are analogous.

Re: Why Python, Ruby, and Javascript are Slow

#147

Post by mixmastamyk »

metaphorm wrote: post #135
stevejohnson wrote: post #129

Earlier quoted context omitted.

That will create a list of 100 instances of the same object. object[0].x = 1 print object[1].x > 1 Edit: On second read, it looks like you're asking something other than what I thought you were asking. Yes, you could create a list of 100 items and then replace its elements, but that's not idiomatic.

but it is idiomatic in C, which is the point of the slide. C was built around a performance focused idiom, which is to pre-allocate memory and then do in place writes and swaps to mutate the buffer to the state you need it to be. Python is built around an idiom of largely creating copies of objects and appending them to dynamically allocated lists. Its a much slower idiom.

Yes, the question was regarding this line in the original post: "I personally find it really frustrating not being able to easily pre-alloc lists in Python."

So my mind of course wandered in the direction of how to do that.

Re: Why Python, Ruby, and Javascript are Slow

#148

Post by omaranto »

pjscott wrote: post #127
mistercow wrote: post #94

Earlier quoted context omitted.

Speed in Python (or Ruby, or JS) isn't a big deal... until it is. When that happens, would you rather have to switch over to C and glue the resulting binary in (assuming you're not using JS, in which case you're just SOL), or would you rather have a high performance API at your fingertips for optimization when you need it?

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.

Re: Why Python, Ruby, and Javascript are Slow

#149

Post by pwang »

marmaduke wrote: post #131
ynniv wrote: post #109

Earlier quoted context omitted.

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

Typical simulations for us take between half a minute and several days, but this can depend because it's typically necessary to do a parameter sweep in several dimensions (leading in extreme cases to runtimes of several months on a cluster). I believe Thrift (now shipped w/ CUDA SDK) makes things easier, but (since you know Python) nothing like NumPy exists in C++ and PyCUDA maps NumPy seamlessly into GPU computing,…

If you are getting good results from CUDA and PyCUDA, you might want to take a look at Numba and NumbaPro: http://numba.pydata.org and http://continuum.io/numbapro. They are still in their early stages but work pretty well on a number of cases. Here is an example of what NumbaPro can do: http://docs.continuum.io/numbapro/generalizedufuncs.html#gen...

Numba is completely open source. NumbaPro is not open source, but it is free for academic users.

Re: Why Python, Ruby, and Javascript are Slow

#150

Post by rdtsc »

tptacek wrote: post #25
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…

It's not an unresolved question whether idiomatic Python is slower than idiomatic C/C++ for solving comparable problems. Python is much, much slower than C.

> It's not an unresolved question whether idiomatic Python is slower than idiomatic C/C++ for solving comparable problems. Python is much, much slower than C.

The real question is does it matter for a particular project.

If it is a desktop GUI. Does it matter if you write it in C++ and the time from button click to status update is 5usec or 1msec?

If you are receiving 10 messages per second, parsing out json and sending back a response or saving it to disk, does it always matter that it all happens in 10msec instead of 11msec. Maybe it does, I found it often doesn't.

Post reply on HN