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

31–40 of 203 posts

Re: Why Python, Ruby, and Javascript are Slow

#31

Post by cschmidt »

rasmusfabbe wrote: post #22

This is misleading and contains errors like calling C++ "C". Unless you have a great deal of knowledge about these things already, I urge you not to learn from this but read the slides purely for entertainment. Question: The author claims to be a compiler author. After some digging I haven't found any information on what compilers he has written or are part of writing. Could someone point me to the compiler(s) Alex i…

He mentioned it directly in the talk: PyPy. Or are you being snarky and saying he doesn't know what he's talking about because PyPy isn't a "real" compiler. Alex has made huge contributions to several open source projects. I can't imagine too many people who know more about making Python go fast.

Re: Why Python, Ruby, and Javascript are Slow

#32

Post by ynniv »

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.

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.

Re: Why Python, Ruby, and Javascript are Slow

#33

Post by timtadh »

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.

This is completely true. It is indeed well known and common wisdom.

However, I think the point the parent was trying to make is: Python is much slower than C and many other languages, however most of the time speed is unimportant. When it becomes important, there are many technologies to mitigate the problem in your "hot loops."

If speed is your primary concern don't use Python et. al. If it isn't your main concern go ahead it probably won't become an issue and if it does you probably will be able to get around it.

Re: Why Python, Ruby, and Javascript are Slow

#34

Post by tptacek »

timtadh wrote: post #33
tptacek wrote: post #25

Earlier quoted context omitted.

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.

This is completely true. It is indeed well known and common wisdom. However, I think the point the parent was trying to make is: Python is much slower than C and many other languages, however most of the time speed is unimportant. When it becomes important, there are many technologies to mitigate the problem in your "hot loops." If speed is your primary concern don't use Python et. al. If it isn't your main concern g…

The deck is about the performance of the language.

Re: Why Python, Ruby, and Javascript are Slow

#35

Post by tptacek »

ynniv wrote: post #32
tptacek wrote: post #25

Earlier quoted context omitted.

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.

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.

Does that mean we can't discuss what makes languages or their implementations performant without having a detailed conversation about the relevance of performance?

Re: Why Python, Ruby, and Javascript are Slow

#36

Post by ynniv »

arocks wrote: post #8
masklinn wrote: post #5

Earlier quoted context omitted.

Have you considered reading the fucking presentation before snarking out on it?

What makes you think I didn't? The author seems to agree with me. He even concludes that we should improve the implementation rather than the language for optimisation.

No, the author concludes that languages based on hash table lookups and lacking copy avoidance mechanisms are inherently slower.

Re: Why Python, Ruby, and Javascript are Slow

#37

Post by ynniv »

tptacek wrote: post #35
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.

Does that mean we can't discuss what makes languages or their implementations performant without having a detailed conversation about the relevance of performance?

No, I'm in complete agreement with the OP, but you said

Python is slower than idiomatic C/C++ for solving comparable problems

And when io and especially network is involved, that is not true. Your efficient C code can't make up for time lost elsewhere in the system. No one is clamoring for curl to be rewritten in assembly.

Re: Why Python, Ruby, and Javascript are Slow

#38

Post by chadcf »

timtadh wrote: post #33
tptacek wrote: post #25

Earlier quoted context omitted.

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.

This is completely true. It is indeed well known and common wisdom. However, I think the point the parent was trying to make is: Python is much slower than C and many other languages, however most of the time speed is unimportant. When it becomes important, there are many technologies to mitigate the problem in your "hot loops." If speed is your primary concern don't use Python et. al. If it isn't your main concern g…

I think just saying don't use python where speed is important is missing the whole point of this slideshow. The author is saying, hey, if we thought about this and put in a few different features we could make it a lot faster without programmers having to do much other than use an alternate implementation of some data stuctures.

While I'd agree that for 99% of us we're not going to find python/ruby/php/javascript to be a bottleneck that can't be mitigated, that's no reason to say it's not worth trying to make them faster. If we can make changes to these languages that will make them more efficient, why not do it?

Re: Why Python, Ruby, and Javascript are Slow

#39

Post by chadcf »

bithive123 wrote: post #15

If you want to learn more about what the Ruby VM has to do in order to execute your code, and some of the performance challenges for Ruby implementors (such as it's extremely flexible parameter parsing) I suggest this talk by Koichi Sasada: http://www.youtube.com/watch?v=lWIP4nsKIMU

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?

Re: Why Python, Ruby, and Javascript are Slow

#40

Post by jeffdavis »

rasmusfabbe wrote: post #22

This is misleading and contains errors like calling C++ "C". Unless you have a great deal of knowledge about these things already, I urge you not to learn from this but read the slides purely for entertainment. Question: The author claims to be a compiler author. After some digging I haven't found any information on what compilers he has written or are part of writing. Could someone point me to the compiler(s) Alex i…

"This is misleading and contains errors like calling C++ "C"."

In what ways did that detract from his overall point?

Post reply on HN