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

181–190 of 203 posts

Re: Why Python, Ruby, and Javascript are Slow

#181

Post by sb »

ubernostrum wrote: post #159
sb wrote: post #112

Earlier quoted context omitted.

Interesting point of view, the problem in compiler construction is well known ("Proebsting's law", though it says it's more like 18 years instead of 10.) The issue with benchmarks is surely well known, also by the PyPy authors; I wonder what the biggest application is that they have benchmarked or that runs on PyPy. Your point on the JIT compiler interrupting program execution is certainly valid, too, but not necessa…

I wonder what the biggest application is that they have benchmarked or that runs on PyPy. speed.pypy.org has benchmark info on Django, Twisted and some other large, non-trivial codebases.

I know these from the site, and have looked at the Django benchmark that's listed there. I think it's a rather small benchmark that does exercise lots of Django internals (but that benchmark comes from Unladden Swallow). I don't know for the twisted ones, though.

What I actually wanted to know, what the biggest application is, i.e., a not benchmark.

Re: Why Python, Ruby, and Javascript are Slow

#182

Post by oscargrouch »

fijal wrote: post #179
jzwinck wrote: post #173

Earlier quoted context omitted.

I know it's for a simpler core language, but LuaJIT is quite a shoestring project too, with one main developer. Yet LuaJIT posts impressively fast results, even though Lua makes no distinction between objects and hash tables. In this and other ways, Lua can be compared to Javascript...but it does have a fast, high-quality JIT implementation, despite not a ton of money or even mindshare. I'm curious why you think this…

I know, Mike is really good. However, this sort of approach does not scale toward larger teams hence the limits of what sort of language you can potentially implement. Lua is much much simpler than Javascript, which is again simpler than Python (Python is really vast). Also, can you find two Mikes?

Mike Pall + Lars Bak = JIT Dream Team :)

Re: Why Python, Ruby, and Javascript are Slow

#183

Post by slurgfest »

coldtea wrote: post #165
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…

> 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. Meh, MEH. That's because you don't do anything involved with your Python code. > I'm sure there are people who do wait. But that's why numpy, c extensions, all the pypy, psycho, and similar things exist. That they HAVE to exist could also be considered a sad state of affairs though…

Anything involved with what? What kind of specific task do you actually mean by 'involved'?

If you don't mind leaving Python's advantages on the table then use C in good health. Odds are that other people will be waiting on you to produce the C code, so let's hope you actually needed to do that.

Re: Why Python, Ruby, and Javascript are Slow

#184

Post by [deleted] »

coldtea wrote: post #164

Speak about Python and Ruby. Javascript is insanely fast, with V8 and its ilk. And I'm not talking about "toy benchmarks" either, I'm talking about envolved stuff written in plain JS (no C extensions), from the QT port to JS/Canvas, to the h264 encoder and such. Try doing those on Python and you'll see what you get. And of course all the toy benchmarks also agree. Javascript with v8 is like a faster PyPy (with less p…

[deleted]

Re: Why Python, Ruby, and Javascript are Slow

#185

Post by oscargrouch »

Its time to face it:

People start to create computer languages without carrying too much about the target processor opcodes (because in that time processor were just getting faster with time) and focus more on programmer convenience, and wild beasts like python and ruby were born..

C is fast because it was created with processor awareness in mind.. pretty simple...

these days kids are all about trying to create more and more crappy convenient sintax languages.. and they get worry when the languages dont scale? for what computer they design the language? from venus ?

nobody should be doing any serious software in python or ruby.. is such a waste of talent .. use it for education.. for fun.. or for the things they are best.. wich is not in the system/plumbing side of things

Re: Why Python, Ruby, and Javascript are Slow

#186

Post by cliffbean »

pjmlp wrote: post #169
Zak wrote: post #102

The creators of Common Lisp knew what Alex is talking about. Lisp is, of course just as dynamic as Ruby, Python or Javascript, but it exposes lower-level details about data structures and memory allocation iff the programmer wants them. Features that come to mind include preallocated vectors (fixed-size or growable), non-consing versions of the standard list functions and the ability to bang on most any piece of data…

In the early 80's there was a time Lisp compilers could even beat FORTRAN for floating point computations. http://www.cs.berkeley.edu/~fateman/papers/lispfloat.pdf

From the discussion of their most relevant benchmark (Singular value decomposition):

  The Allegro CL 4.1 times of 3.9 seconds beat the f77 time of 4.8 [seconds];
Nice!

  setting on optimization for f77 brought its time down to 0.45 seconds.

  Thus for this system, the [LISP] compiled code can have quite comparable speed to
  that of the corresponding unoptimized Fortran in this case as well.
Oh really.

Re: Why Python, Ruby, and Javascript are Slow

#187

Post by evincarofautumn »

DannyBee wrote: post #93

Speaking as a compiler guy, and having a hand in a few successful commercial JITs: The only reason he thinks they aren't slow is because they haven't yet reached the limits of making the JIT faster vs the program faster. Yes, it's true that the languages are not slow in the sense of being able to take care of most situations through better optimization strategies. As a compiler author, one can do things like profile…

I develop a compiler for ActionScript 3. Though it’s not a great language, it does have a few distinct advantages over its cousin JavaScript. First, type annotations. Obviously the more knowledge you have about the structure of the program, the better you can help it run well. Having a class model instead of a prototype model also helps—much as I like working with prototypes—because you can easily eliminate late binding (“hash lookups”) and allocations, two of the performance killers mentioned in the slides. The operative word there is easily. You can analyse and JIT all you want, but you cannot feasibly solve at runtime the fundamental constraints imposed by the language.

Say a compiler author needs twice as much effort and cleverness to make programs in language X run fast than for language Y. That means that—all other things being equal—implementations of X will be twice as slow as Y for the same basic quality of implementation.

Re: Why Python, Ruby, and Javascript are Slow

#188

Post by Peaker »

pointernil wrote: post #180
vidarh wrote: post #177

Earlier quoted context omitted.

> For example: Almost all of the allocations and copying can be optimized, but depending on the language, the algorithms to figure out what you can do safely may be N^3. ... and this is pretty much his point: He can keep optimizing, but the moment you start passing complex objects around and copying them all over the place, instead of passing raw buffers around and operating on them in place, you've massively raised…

.) Just wondering, are there any languages/runtime-systems based on the idea of a fixed memory layout? No heap just "preallocated" buffers? I remember that was / probably still is quite common in the embedded world. I guess it is done easily with globals in C .) Any profilers providing information reg. the heap-allocs as part of the execution costs? .) Any Runtimes / VM actually optimizing the layout of those omni-pr…

.) At our workplace, we use preallocation for almost everything. When we do dynamic allocations, typically it is from free-lists from pools that we pre-allocate.

Almost all of our allocation/freeing costs are cheap O(1). Pretty much everything is zero-copy. That is why I cringe a little when I hear that GC's are "faster than manual MM". Because manual MM done well can eliminate almost all of the costs of memory management.

I also cringe a little when I see "malloc" deep inside C functions.

I really like the basic convention in C that you should pass needed allocations in as arguments (and it is virtually always possible) allowing these allocations to be members of of members of other allocations, aggregating allocations so there are much fewer.

.) Information regarding heap-allocs is relatively easy to obtain with "oprofile", look up the time spent in "malloc" and "free" and the related functions underneath them.

.) C makes it very easy to use an array of the values you want, rather than an indirection. For Lists, I don't think that is a useful idea. For hash tables, given that many entries are empty, I think it is a better trade-off to have your hash array as an indirection, though the buckets could be explicitly put together. And so on.

I often encountered dynamic allocation overheads are noticeable or even huge chunks of my runtime when I had to work with code that used them. Reducing the dynamic allocation really helps. We're not safe, we need to work towards it explicitly.

Re: Why Python, Ruby, and Javascript are Slow

#189

Post by dmg8 »

oscargrouch wrote: post #185

Its time to face it: People start to create computer languages without carrying too much about the target processor opcodes (because in that time processor were just getting faster with time) and focus more on programmer convenience, and wild beasts like python and ruby were born.. C is fast because it was created with processor awareness in mind.. pretty simple... these days kids are all about trying to create more…

Please don't ever comment again. Thanks in advance.

Re: Why Python, Ruby, and Javascript are Slow

#190

Post by pwang »

emn13 wrote: post #162
pwang wrote: post #98

Earlier quoted context omitted.

> Is it also faster than C? From my limited experience, it seems that people sometimes spend a lot of time on concurrency when faster code would have been easier It can reach FORTRAN speeds with the right tools. With Numba ( http://numba.pydata.org/ ), your pure Python code gets compiled down to optimized machine code at call time, if your arguments are Numpy arrays. With NumbaPro ( https://store.continuum.io/cshop/n…

As a counterpoint; a last project I wrote in college was a machine learning algorithm. By a rough comparison it was on the order of 10000 times faster in C++ than the preexisting matlab implementation. The cause was that the performance bottleneck was not in large matrix operations; instead, there were lots of iterative updates until convergence; this meant small vectors; a C++ template-based matrix library such as E…

Good points, certainly, but just to clarify: Numba is not particularly dependent on Numpy's built-in vectorized and matrix operations. Instead, it's using the datatype information to do JIT type inference over the functions being called with the matrix/array arguments, and building machine code for them. You can call Numba JITted functions from other Numba JITted functions, and the overhead is the same as C functions calling each other.
Post reply on HN