Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Python Is Slow: Looking Under the Hood

jakevdp.github.io

Post reply on HN
Print view View original

51–60 of 156 posts

Re: Why Python Is Slow: Looking Under the Hood

#51

Post by haberman »

[deleted] wrote: post #47
haberman wrote: post #34

Earlier quoted context omitted.

> This is very different from Perl, where a line of code isn't parseable until you know the values of the variables Perl is crazy, but I don't think it's that crazy. From perlcompile( http://perldoc.perl.org/5.8.9/perlcompile.html ) Perl has always had a compiler: your source is compiled into an internal form (a parse tree) which is then optimized before being run. If what you say is true, it would not be possible to…

[deleted]

I am aware of this result. However, that differs from what GP said in one important way.

Grandparent said "This is very different from Perl, where a line of code isn't parseable until you know the values of the variables."

If that were true, it would imply that you could have a loop whose body is parsed differently on every iteration. It would imply that the parser runs inline with the interpreter. Neither of those things are true.

What your link says is that the parsing can vary based on whether or not a subroutine prototype with appropriate arity was previously defined. That is a very different thing. A statement in a loop could be parsed differently depending on what was defined before it, but that parse doesn't change just because a subroutine is defined later, I'm pretty sure.

Yes, this means Perl's parsing is undecideable, because you can conditionally define a subroutine (this might be limited to BEGIN blocks; I'm not sure). But that's not the same as saying the parse varies based on the "values of the variables."

Re: Why Python Is Slow: Looking Under the Hood

#52

Post by haberman »

scott_s wrote: post #42
haberman wrote: post #34

Earlier quoted context omitted.

> This is very different from Perl, where a line of code isn't parseable until you know the values of the variables Perl is crazy, but I don't think it's that crazy. From perlcompile( http://perldoc.perl.org/5.8.9/perlcompile.html ) Perl has always had a compiler: your source is compiled into an internal form (a parse tree) which is then optimized before being run. If what you say is true, it would not be possible to…

Apparently, Perl is that crazy. See https://news.ycombinator.com/item?id=5770531 Basically, you can't always parse a Perl program without running it. There is a subset that you can, not not everything.

> Basically, you can't always parse a Perl program without running it.

That is true, but what the grandparent said is not: https://news.ycombinator.com/item?id=8626454

To expand on this, I think a succinct way of summarizing the issue is: you might have to run BEGIN blocks in Perl to parse the non-BEGIN-block part of the program. The canonical example of this is:

    BEGIN {
        if(arbitrary_function()) {
            eval "sub whatever() { }; 1" or die $@;
        } else {
            eval "sub whatever { }; 1" or die $@;
        }
    }

    # The parsing of this line depends on the result of arbitrary_function()
    whatever  / 25 ; # / ; die "this dies!";
arbitrary_function() can be anything, so the only way to parse the rest of the program is to actually run arbitrary_function().

Re: Why Python Is Slow: Looking Under the Hood

#54

Post by slashnull »

ludamad wrote: post #22
slashnull wrote: post #16

Short answer: because it doesn't JIT

That's a lossy short answer. LuaJIT with JIT turned off still runs circles around CPython.

True.

So, with element of answer 1) ruled out as Lua is also dynamic, and 2) ruled out by your evidence, remains

3. Python's object model can lead to inefficient memory access

Re: Why Python Is Slow: Looking Under the Hood

#57

Post by AlexeyBrin »

slantedview wrote: post #53

"it's slow" "just write a C extension" "but then why use Python?"

    "it's slow"
    "just write a C extension"
    "but then why use Python?"
Because you typically need to write a C extension for like 2% or your code, while you could keep the remaining 98% in an easier to write (and more compact) language.

Re: Why Python Is Slow: Looking Under the Hood

#59

Post by slashnull »

scott_s wrote: post #40

Even if you're already familiar with all of the main reasons that answer the question (that is, you're already familiar with how a VM works), read the Just for fun: a few "never use these" hacks . I mean, wow . That's the kind of nastiness I normally associate with C's free-for-all memory model.

With the nuance that C forces you to deal with those never use these hacks in order to do anything non-trivial.

I can't see why anyone would go and mess with CPython's internals like that in production code. Other than for nefarious purposes, I guess.

Re: Why Python Is Slow: Looking Under the Hood

#60

Post by debacle »

tjradcliffe wrote: post #27

A related question is: why is Perl so fast? Quite a few years ago I wrote a little Runge-Kutta solver in Perl for some simulation work. It seemed like a good idea at the time. The equations of motion had to be integrated over a very long time, and it could take hours for a single run (still much faster than the Monte Carlo it was being used to do a sanity-check on). I re-wrote everything in C++, and picked up less th…

Because it was written to do (certain) things very fast.
Post reply on HN