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

41–50 of 203 posts

Re: Why Python, Ruby, and Javascript are Slow

#41

Post by lucian1900 »

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…

Alex's point is that Python on PyPy is trivially comparable to those C extensions in speed. So why give up Python, ever, if JITs are this good?

Re: Why Python, Ruby, and Javascript are Slow

#42

Post by timtadh »

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.

[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 who bench marked Python vs. Matlab for our workload. Python is faster. (often because some of the algorithms used are newer than the equivalents in Matlab.)

2. It is a very productive environment. We do a lot of evolutionary changes and prototyping. Doing in this in C would slow us down in dev. time. This is academic work and mostly the code isn't important the analysis is.

3. We generally know where the "hot loops" are. Which is what we focus on for optimization. This generally involves doing math on paper. Then implementing it. If you turn loops in to matrix multiplications and use a good matrix library you get a great speed up.

Re: Why Python, Ruby, and Javascript are Slow

#43

Post by cgh »

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's on this page: http://pypy.org/people.html

He works on the JIT, among other things.

Re: Why Python, Ruby, and Javascript are Slow

#44

Post by lucian1900 »

masklinn wrote: post #29
mzs wrote: post #14

Earlier quoted context omitted.

The first example is lookup based on name, you can get away from that in python with slots but the common consensus is that it's not worth the performance improvement. That somehow translates into a dogma like, "Never use slots," but sometimes it is worth it.

> The first example is lookup based on name, you can get away from that in python with slots You can get away from that with a sufficiently smart JIT turning a stable access to a known object into little more than a vtable dispatch. That's close to what V8 does with hidden classes on full cache hits (object map — its "hidden class" — + object "array" property both cached). point.x will generate the assembly: cmp [ebx…

Which PyPy does, so __slots__ is entirely useless.

Re: Why Python, Ruby, and Javascript are Slow

#45

Post by tptacek »

ynniv wrote: post #37
tptacek wrote: post #35

Earlier quoted context omitted.

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.

True, but obvious.

Re: Why Python, Ruby, and Javascript are Slow

#46

Post by tptacek »

lucian1900 wrote: post #41
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…

Alex's point is that Python on PyPy is trivially comparable to those C extensions in speed. So why give up Python, ever, if JITs are this good?

What if writing performant code on modern Python implementations is only incrementally easier than writing it in C to begin with?

With the right libraries, the hard parts of C probably turn out to be string processing with zero-copy string idioms, the requirement to lay out every data structure in fiddly detail, the requirement to track individual allocations, and the requirement to manage the memory lifecycle. What if performant Python only gives you an advantage on the last one of those?

Re: Why Python, Ruby, and Javascript are Slow

#47

Post by obviouslygreen »

tptacek wrote: post #34
timtadh wrote: post #33

Earlier quoted context omitted.

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.

And this comment thread is about why some people don't care in some applications. HN meta!

Re: Why Python, Ruby, and Javascript are Slow

#48

Post by dicroce »

As a C/C++ programmer I find these slides kind of amusing... These languages are popular because they make things simpler, and his suggestions may very well get a nicely jit'd language on par with C, but I suspect you'll then have the same problems C does (complexity).

Re: Why Python, Ruby, and Javascript are Slow

#49

Post by tptacek »

obviouslygreen wrote: post #47
tptacek wrote: post #34

Earlier quoted context omitted.

The deck is about the performance of the language.

And this comment thread is about why some people don't care in some applications. HN meta!

This comment thread is isomorphic to a comment thread on Packrat parsing with comments about how "I don't parse anything I just use sexprs".

Re: Why Python, Ruby, and Javascript are Slow

#50

Post by timtadh »

tptacek wrote: post #34
timtadh wrote: post #33

Earlier quoted context omitted.

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.

@chadcf and @tptacek

I was responding to @tptacek criticism of the parent not the deck. The deck is great and it mirrors the wisdom I have picked up from optimizing my own code over the years. I personally find it really frustrating not being able to easily pre-alloc lists in Python. I think that having better APIs would go a long way.

As the deck says:

"Line for line these languages are fast!"

"We need better no-copy/preallocate APIs"

"Take care in data structures"

Post reply on HN