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

71–80 of 203 posts

Re: Why Python, Ruby, and Javascript are Slow

#71

Post by tikhonj »

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.

No, Haskell really does have significantly better performance than Python or Ruby. Same with some Lisp variants as well--there was even a research whole-program optimizing compiler for Scheme that apparently sometimes beat hand-optimized C (Stalin Scheme).

So one way to improve performance is simply by having a good compiler. And GHC, at least, is a very good compiler.

Also, Haskell support for direct memory control is not that bad. In fact, in some ways, it's better than even Java--you can have your own unboxed data types which essentially act like structs, for example. This also means that you can have unboxed arrays of more than just primitive types.

Haskell also does some very clever things with both the heap and the stack, but I'm not familiar enough with its internals to comment. My understanding is that Haskell makes heap allocation much cheaper and has a GC optimized for handling lots of small allocations (as you would expect for a functional language).

Ultimately, the point is that the question is fairly nuanced and you won't be able to pin down a single language or implementation feature that uniquely determines performance.

Re: Why Python, Ruby, and Javascript are Slow

#72

Post by jderick »

I think the preallocate APIs sound like a cool idea. Perhaps there could also be some kind of 'my hashtable is an object' hint that could let the compiler do the same kind of optimizations on hashtables that it does on objects (assuming that your hash keys don't change much).

Re: Why Python, Ruby, and Javascript are Slow

#73

Post by cwzwarich »

pcwalton wrote: post #66

Related to this is the importance of deforestation. Some good links: * http://en.wikipedia.org/wiki/Deforestation_%28computer_scien... * http://www.haskell.org/haskellwiki/Short_cut_fusion Deforestation is basically eliminating intermediate data structures, which is similar to what the "int(s.split("-", 1)[1])" versus "atoi(strchr(s, '-') + 1)" slides are about. If you consider strings as just lists of characters, th…

Automatic deforestation can remove intermediate results in a pipeline of computation, but it can not rewrite a program that is based around the querying / updating of a fixed data structure to use an efficient imperative equivalent throughout.

Re: Why Python, Ruby, and Javascript are Slow

#74

Post by lucian1900 »

pcwalton wrote: post #66

Related to this is the importance of deforestation. Some good links: * http://en.wikipedia.org/wiki/Deforestation_%28computer_scien... * http://www.haskell.org/haskellwiki/Short_cut_fusion Deforestation is basically eliminating intermediate data structures, which is similar to what the "int(s.split("-", 1)[1])" versus "atoi(strchr(s, '-') + 1)" slides are about. If you consider strings as just lists of characters, th…

Deforestation is easily done in lazy languages like Haskell.

As for GC, it would be nice to have good real time GCs in runtimes.

Re: Why Python, Ruby, and Javascript are Slow

#75

Post by cwzwarich »

tptacek wrote: post #69
cwzwarich wrote: post #68

Earlier quoted context omitted.

Is this really true? I have investigated a few performance / power problems caused by somebody using a bad networking API or using a networking API correctly, despite doing the same amount of I/O. It is also more likely to be possible to use efficient platform-specific APIs for things like zero-copy I/O in C than in a scripting language.

Zero-copy is often not actually a win; it's also uncommon in C code, too. The parent comment is right; I/O bound programs tend to do just as well in slow languages as in fast. It's true that language performance often doesn't matter, just like it's true that parser designs don't matter if you just use sexprs for everything.

I disagree. I've measured it and it matters.

Re: Why Python, Ruby, and Javascript are Slow

#76

Post by tptacek »

cwzwarich wrote: post #75
tptacek wrote: post #69

Earlier quoted context omitted.

Zero-copy is often not actually a win; it's also uncommon in C code, too. The parent comment is right; I/O bound programs tend to do just as well in slow languages as in fast. It's true that language performance often doesn't matter, just like it's true that parser designs don't matter if you just use sexprs for everything.

I disagree. I've measured it and it matters.

For your data set.

Re: Why Python, Ruby, and Javascript are Slow

#77

Post by wting »

I have a few comments about some of the slides, feel free to correct any misunderstandings.

Dictionary vs Object:

Lookups in both data structures is O(1), the difference being the hashing cost (and an additional memory lookup for heap) vs a single memory lookup on the stack (1 line of assembly).

Squares list:

> ... so every iteration through the list we have the potential need to size the list and copy all the data.

This is no different than stl::vector which has an amortized cost of O(1) for a push_back().

It's not going to be as fast as C, but I'd also argue for a generator version instead:

    def squares(n):
        return (i*i for i in xrange(n))
One of the main reasons people choose Python is for expressiveness and not manually managing memory, although pre-allocation does seem like a good idea.

Re: Why Python, Ruby, and Javascript are Slow

#79

Post by jholman »

StavrosK wrote: post #61
chadcf wrote: post #39

Earlier quoted context omitted.

I really wish this talk had been done by someone who spoke english, I found it rather painful to try and get through... Any good articles that summarize this info?

I find this attitude a bit entitled. The speaker does speak English, his accent is just not very understandable. However, opening the video and seeking to a random point, I must say that the phrase "Ruby release policy: Ruby level compatibility" isn't doing any Japanese speaker a favour.

You find his attitude entitled, I find your reply needlessly confrontational.

It's not like chadcf said "This talk is bullshit, that guy doesn't even speak English". chadcf said "I experienced this difficulty, I wish that the following thing existed, can anyone help me?" Maybe he could afford to have done

    s/speak English/speak more fluent English/

Re: Why Python, Ruby, and Javascript are Slow

#80

Post by andolanra »

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 someList))
is going to involve allocating exactly one list of the same size as someList, while a direct translation into Python

    map(f, map(g, map(h, someList)))
is going to involve the creation of several intermediate lists.
Post reply on HN