Why Python, Ruby, and Javascript are Slow • Hacker News Board

Re: Why Python, Ruby, and Javascript are Slow

#191

Post by pjmlp » Sun, Mar 03, 2013, 5:03 AM UTC

cliffbean wrote: post #186

pjmlp wrote: post #169

Earlier quoted context omitted.

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.

It's been a few decades since I have read the paper, so it seems my memory is a bit fuzzy on that regard.

On the other hand, given that C always had issues to beat even unoptimized Fortran, due to the optimization restrictions before C99, it is quite commendable that Lisp achieves such results.

Re: Why Python, Ruby, and Javascript are Slow

#192

Post by BrandonM » Sun, Mar 03, 2013, 7:24 AM UTC

emiliobumachar wrote: post #100

tptacek wrote: post #62

Earlier quoted context omitted.

I'm interested in this discussion. Which of those issues could you dispense with using more modern APIs and idioms in C? Look at Objective C (mentally wipe off all the object goo), particular NSMutableString and NSMutableArray and NSMutableData, for examples of what I'm thinking about. The C syntax we're stuck with. But how big a deal is that syntax? Segfaults are mitigated if you don't expose pointers, except to the…

I routinely program in Python and C, and syntax matters much to me. My personal favorite feature of Python is simply the syntatic sugar that allows me to write stuff like "for element in array" without having to remember that an index exists. These little things add up fast when you're trying to focus on the problem at hand!

I actually was able to write a macro in C that, along with a certain paradigm for defining collections, allows foreach loops that are just as nice as Python.

Re: Why Python, Ruby, and Javascript are Slow

#193

Post by ksec » Sun, Mar 03, 2013, 3:08 PM UTC

irahul wrote: post #174

Mike Pall of luajit fame has an interesting take on it. http://www.reddit.com/r/programming/comments/19gv4c/why_pyth... While I agree with the first part ("excuses"), the "hard" things mentioned in the second part are a) not that hard and b) solved issues (just not in PyPy). Hash tables: Both v8 and LuaJIT manage to specialize hash table lookups and bring them to similar performance as C structs (1). Interestingly, w…

Yeah i wish someone could crowd source a project so Mike could spare 20% of his time on RubyVM.

Re: Why Python, Ruby, and Javascript are Slow

#194

Post by cliffbean » Sun, Mar 03, 2013, 4:11 PM UTC

pjmlp wrote: post #191

cliffbean wrote: post #186

Earlier quoted context omitted.

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.

It's been a few decades since I have read the paper, so it seems my memory is a bit fuzzy on that regard. On the other hand, given that C always had issues to beat even unoptimized Fortran, due to the optimization restrictions before C99, it is quite commendable that Lisp achieves such results.

It's not obvious how optimized C in the '80s wouldn't have been as fast as unoptimized Fortran 77, even with whatever optimization restriction you might be thinking of.

The way the authors of that paper talk about unoptimized code in that paper gives the impression that they don't know what they're talking about. Your comments here begin to put you at risk of a similar appearance.

Re: Why Python, Ruby, and Javascript are Slow

#195

Post by lucian1900 » Sun, Mar 03, 2013, 7:17 PM UTC

mzs wrote: post #65

lucian1900 wrote: post #44

Earlier quoted context omitted.

Which PyPy does, so __slots__ is entirely useless.

pypy is great, but I and others used swig and am stuck now with maintaining that stuff. There is also memory benefit to slots for when there are many instances. Sometimes you just have to do gross stuff so you can get on to the next thing, it's okay when everybody understands it enough.

The memory benefit also exists on PyPy without slots.

It may be possible to write a cffi backend for swig, but it's likely quite hard.

Re: Why Python, Ruby, and Javascript are Slow

#196

Post by DannyBee » Mon, Mar 04, 2013, 4:29 AM UTC

cpprototypes wrote: post #152

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…

So does the JIT optimization algorithms depend on popular conventions and patterns of how people write code with a language? Like in JS theres bad language features people avoid and certain patterns on how to code something. If such things changed would the optimizations start failing? I guess I'm wondering if speed is somewhat related to trends in that language.

Once you get past generic dataflow based optimizations that have some notion of optimality[1], yes, you start to write optimizations that target idioms.

For example: Most compilers started doing structure layout and reorg optimizations (transforming structures with arrays into arrays of structures, and vice versa) to tackle specific benchmarks. In some cases, they discovered it also was useful generally.

But whatever the benchmarks are, that's often what gets targeted. You can't optimize in a vacuum, you need to know what you are trying to develop optimization algorithms to do. This usually occurs by taking user complaints/programs/whatever, finding out why they are slow, seeing if there is a common solution, and developing an optimization to do it.

So yeah, if you are targeting certain patterns, and the patterns change, ..

[1] IE You've removed all possible redundant computations, made it so everything is only computed among paths it is actually used, the calculations occur in lifetime optimal fashion, etc.

Re: Why Python, Ruby, and Javascript are Slow

#197

Post by lsiebert » Mon, Mar 04, 2013, 6:45 AM UTC

As a programmer that first learned c and still thinks like a C programmer in a lot of ways, this actually explains a lot to me.

Re: Why Python, Ruby, and Javascript are Slow

#198

Post by brent_noorda » Mon, Mar 04, 2013, 8:53 AM UTC

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…

No heap? Hmmm... As the slidedeck pointed out, much time is spent in both allocation and copying of memory, and in practice those things are most often strings. Given that 1) the languages under consideration declare strings as immutable, and 2) the strings enter the system at fixed points (e.g. source code or external inputs), and 3) exit at fixed points (e.g. sent out a socket).... Imagine a system that does not allow heap allocation or memory copying at all. Just doesn't allow them!

    var structure = "dog" + "house"
    print structure

does not need to allocate or move memory. That's how the script languages do it now, but should they? All the really need to do is print "dog" and then print "house", there's nothing that says those 8 letters need to be ever adjacent in memory.

Since it's so darn easy (and sloppy) to call malloc() and memcpy() the script-engine writers are going to keep doing so until they're given a MacrocosmicGod-like environment that won't allow malloc() or memcpy() and so will have to come up with a clever workaround. maybe it will be something like linked-lists of immutable blocks of memory? Something like ropes? Something smarter than that?

Anyway, script-engine writers, please forget that malloc() and memcpy() exist, and see what you come up with. It'll be wonderful. (P.S. I was in the script-engine business for a dozen years and didn't solve the problem, but that's just because I'm not smart enough.)

Re: Why Python, Ruby, and Javascript are Slow

#199

Post by Nursie » Mon, Mar 04, 2013, 11:28 AM UTC

pjmlp wrote: post #167

Nursie wrote: post #140

Earlier quoted context omitted.

Try telling that to a dedicated C++ guy. Apparently the C calls are dangerous, dirty and just to be avoided.

Fully agree. Only when C goes away we have the possibility to have more secure software.

Yeesh.

When incompetent programmers go away perhaps. C in and of itself is not the issue. And neither is scaring people away from it with horror stories.

I've run into young engineers recently who thing that pretty much any 'C style' system call is necessarily dangerous, because OMG the developer has to remember to pass in the length of the buffer they're passing in as well as the buffer itself. No, you just have to not be a frickin' idiot.

Re: Why Python, Ruby, and Javascript are Slow

#200

Post by emn13 » Tue, Mar 05, 2013, 1:47 PM UTC

pwang wrote: post #190

emn13 wrote: post #162

Earlier quoted context omitted.

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…

I've got no numba experience whatsoever, but if you're doing real function calls and memory allocations for simple things like multiplying small matrices, your code will be at least an order of magnitude slower than optimal, even in C. malloc's a big hit, and function calls often are too - not just because of the call itself (and the CPU cache hit that can involve), but no less significantly because they're opaque to the optimizer - and that means that the wrapping function is often optimized much less well.

It's not a fundamental issue, but I haven't seen a JIT do this particularly well, yet. All that inlining makes compiling slower, so to some extent the run-time nature of the JIT is an inherent limitation here.