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

131–140 of 156 posts

Re: Why Python Is Slow: Looking Under the Hood

#131

Post by [deleted] »

lispm wrote: post #128
rurban wrote: post #95

Unfortunately this blog post is misleading and uninformed. Python and the related other slow dynamic languages perl, php, and ruby are slow not because the dynamic type checks, branches and indirections are costly, but because they are badly written. They are just inefficient and poor interpreters, with bad ops and data structures. In comparison efficient dynamic languages like lisp, scheme, lua or javascript and man…

I think the paper is even worse, in that it spreads confusion about what an Interpreter for a programming language actually is, what it does and what it provides. The paper fails to define the concept of what to call an Interpreter. A bytecode interpreter is entirely different from a Lisp interpreter, which actually runs from source structures. Mixing VMs into the picture makes it only worse. Part of the reason may b…

[deleted]

Re: Why Python Is Slow: Looking Under the Hood

#132

Post by Htsthbjig »

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…

"why is Perl so fast?"

Is not. We tested our own code in Perl for doing some text processing in our company.

The result was 89 times slower than our c code, which is not so slow compared with other options, but is slow.

We use a lot of c++ and python, but always for managing encapsulated low level code.

With anything that has to compute intensely, like audio, video or 3d work, the differences are way over 3000 times slower. That is: the computer working for a second or for an hour.

Java is not fast, it has never been. It is not its "forte". You could decide to use java or any high level languages based on its merits, but being fast is not one of them.

It is a good idea to learn assembly and disassembly with the debugger before using high level languages. It gives you the knowledge of what computers are really doing under the hood.

Re: Why Python Is Slow: Looking Under the Hood

#133

Post by stinos »

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…

I re-wrote everything in C++, and picked up less than a factor of two in speed.

Don't think it has been mentioned in the other comments, but this could also be a performance problem with your C++ code - possibly in combination with doing something Perl is good at

Re: Why Python Is Slow: Looking Under the Hood

#134

Post by bjz_ »

rdtsc wrote: post #113
Cyther606 wrote: post #102

Earlier quoted context omitted.

Check out Nim. import rdstdin, strutils let time24 = readLineFromStdin("Enter a 24-hour time: ").split(':').map(parseInt) hours24 = time24[0] minutes24 = time24[1] flights: array[8, tuple[since: int, depart: string, arrive: string]] = [(480, "8:00 a.m.", "10:16 a.m."), (583, "9:43 a.m.", "11:52 a.m."), (679, "11:19 a.m.", "1:31 p.m."), (767, "12:47 p.m.", "3:00 p.m."), (840, "2:00 p.m.", "4:08 p.m."), (945, "3:45 p.m…

If I had to guess speed is pretty close to C, right. Nim is pretty awesome and has been around for a while. I wish one of big entities out there Google, Mozilla, Microsoft, Apple would have adopted Nim and ran with it instead of inventing their own langauges.

At the time when Go and Rust were conceived Nim would have certainly not been on their radar. Both were announced in 2009, at a time when the Nimrod repository had barely even got off the ground[0]. And Nim doesn't really address one of Apple's chief concerns: smoothly transitioning away from Objective-C.

[0]: https://github.com/Araq/Nimrod/graphs/contributors

Re: Why Python Is Slow: Looking Under the Hood

#135

Post by anentropic »

jlebar wrote: post #84
mikkom wrote: post #78

Almost all these points apply to javascript as well. Javascript, however, is not really slow anymore. http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te...

> Almost all these points apply to javascript as well. Sort of. The article talks about why CPython, an implementation of the Python language, is slow. You're right that a naive implementation of Javascript would have many of the same problems, and indeed many of the first implementations of JS did have these problems. But due to heated competition, Mozilla, Google, Apple, and Microsoft have invested a huge amount of…

that's what PyPy is http://speed.pypy.org/

Re: Why Python Is Slow: Looking Under the Hood

#137

Post by andreasvc »

albertzeyer wrote: post #129
csirac2 wrote: post #91

Earlier quoted context omitted.

I don't know why I always have to chip in on "perl is unreadable lol" comments, but over the last 8 years apart from a steady trickle of C coding here and there the bulk of my dayjob has moved around from C/Verilog, then I discovered Ruby, then Perl/R/Python, to full-time Python now. It's true that unsupervised, weak coders using perl turn out worse code than in other languages. But it really doesn't take much to pro…

Python 3 has function annotations and you can use it for static type checks. See this: http://www.infoq.com/news/2014/08/python-type-annotation-pro... https://mail.python.org/pipermail/python-ideas/2014-August/0... http://mypy-lang.org/ https://docs.python.org/3/tutorial/controlflow.html#function...

Those are only checks, and don't make your code faster (in fact, slower, when checks are enabled). To get efficiency benefits you need a language/compiler designed around static typing. Cython offers a superset of Python that can be statically typed.

Re: Why Python Is Slow: Looking Under the Hood

#138

Post by Igglyboo »

visarga wrote: post #120
Igglyboo wrote: post #107

Earlier quoted context omitted.

I think the takeaway is that perl is "fast enough" for perl type problems. Writing a complicated file parser in C would be a nightmare.

When I have a one-time computation job that takes an hour to write and two hours to run in Perl, but in C takes 10 hours to write and half an hour to run, then Perl is faster than C. And these one-time/rare/short jobs are much more frequent than intense, high throughput C code like the nginix web server or the node javascript interpreter.

I see your point, C is definitely the choice for long running jobs or jobs that will be run more than a handful of times, in my experience however I'm writing a lot of one-off scripts that take 30 seconds tops to run so Perl wins out pretty hard over C.

Re: Why Python Is Slow: Looking Under the Hood

#139

Post by fidotron »

csirac2 wrote: post #114
fidotron wrote: post #108

Earlier quoted context omitted.

Last time I used Perl it went badly, but it was a typical hacked up mess. For someone mainly in the Python/Java/C++ world is Moose something worth looking at as a mind expansion exercise? Your description makes it sound appealing. And, dare I ask, what about Perl 6?

I want to write something concise and coherent, but it's not happening today :) Instead, assuming you've read the teasers in the Moose manual [1] I'd recommend this [2] interesting comparison of how horizontal code re-use can be achieved in Java, Ruby, PHP and Perl+Moose. There's more philosophical/winding essays on Moose from Chromatic, for example at [3]. Roles/traits/method modifiers/MOP/composability etc. are all…

One of those times I wish I had more than one upvote - thanks!

I definitely have a preference for a more declarative approach, and not in the J2EE giant piles of XML way. Will give these a look for inspiration - thanks again!

Re: Why Python Is Slow: Looking Under the Hood

#140

Post by JoeAltmaier »

dragonwriter wrote: post #105
JoeAltmaier wrote: post #98

Earlier quoted context omitted.

Its hard to be worse than an interpreter. 100X slower than compiled code is typical. Whatever 'metadata and indirection' your C target has, it seems likely to be 10X better than interpreted, easily.

> Its hard to be worse than an interpreter. Its actually quite easy to be worse than an interpreter that is actually a combination of a bytecode compiler and a VM built around the execution model of the language it is for, which is what the main Python interpreter is.

Interpreters have to be implemented somehow; that's a way. Its not fast. Its orders of magnitude slower than native code. Even bad native code.
Post reply on HN