He mentions that he couldn't find a pure C hash table.
Why Python, Ruby, and Javascript are Slow
51–60 of 203 posts
Re: Why Python, Ruby, and Javascript are Slow
#52Earlier quoted context omitted.
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.
I hate to feed someone on a troll, but you started this off with "Python is much, much slower than C." This comment thread is sponsored by obvious.
Re: Why Python, Ruby, and Javascript are Slow
#53Very interesting talk
Leads me to wonder - has anyone done a study of any large-scale program to check where the slow spots are? It's not that I don't trust the speaker, he makes excellent points and is obviously a great memeber of the community.
But it would be very interesting if he were able to say: "Using PyPy's secret 'hint' API, only in drop-dead obvious places, improved performance by a factor of 5".
Re: Why Python, Ruby, and Javascript are Slow
#54Back 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, 0.41 seconds in C compiled with gcc -O0, and 0.13 seconds with gcc -O3. Here is the code if anyone is interested. Note that it's not commented, not thread-safe, and doesn't free memory, so use at your own risk :)
https://gist.github.com/anonymous/5066486
gcc strange.c rk4.c; ./a.out
node strange.jsRe: Why Python, Ruby, and Javascript are Slow
#55Earlier quoted context omitted.
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…
You can control the details without it having to be overly fiddly. Certainly you can do better than C. You may end up doing similar things, but your code will be way easier to write and read. Go does this quite well.
Re: Why Python, Ruby, and Javascript are Slow
#56Someone actually posting notes with slides! It's a miracle!
yes thank god. I almost skipped it when I saw it was a slide deck, until I saw the notes. I hate it when people link to a slide deck with no notes. It's almost completely useless.
Re: Why Python, Ruby, and Javascript are Slow
#57One 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.
Re: Why Python, Ruby, and Javascript are Slow
#58Earlier quoted context omitted.
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…
I would say that the difference between fast Python code and C is still quite large.
- the syntax is less error-prone - ownership semantics are much clearer. You'll never segfault because you sent some memory into the wrong function - not as much detail is needed for memory layout, the JIT abstracts a lot of it away - there are high-level APIs handy - development and distribution are simpler with one less language - the barrier to optimising things is lower
Re: Why Python, Ruby, and Javascript are Slow
#59A nice talk. The punchline for me was: Things that take time •Hash table lookups •Allocations •Copying Interestingly, that's exactly how you write fast C++ code. His point is that languages like Python lack good API's for preallocating memory.
It's how you write fast algorithms in general, in any programming language. Minimize the number of reads and writes per iteration/recursion.
In higher-level programming languages, it's just a bit harder to control the number of reads and writes because you're working at several layers of abstraction above them, and are concerned with solving higher-level problems. Use the language that provides the appropriate level of abstraction for the problem you're trying to solve.
Re: Why Python, Ruby, and Javascript are Slow
#60It is almost time that people stop referring to Languages as Fast or Slow. It is an implementation that is fast or slow, not a language.
While I agree that implementations can be fast or slow, it does not completely eliminate the effect of the language. At minimum, different languages require different levels of effort to reach their optimum. So, while a language can be hurt by a poor implementation, it does not follow that all languages have the same potential performance.
As an example, just consider the enormous amount of effort that has gone into the JVM, and Java is still generally considered to be ~2x slower that C.