Python’s Weak Performance Matters • Hacker News Board

Re: Python’s Weak Performance Matters

#271

Post by theli0nheart » Wed, Feb 07, 2018, 5:07 PM UTC

_dps wrote: post #219

theli0nheart wrote: post #204

Earlier quoted context omitted.

> CPU performance long ago hit physical limits, and more and more we are scaling out applications across hundreds, thousands, or millions of servers. We've passed the inflection point where CPU speed really is more expensive than programmer time, if you are running that code at a big enough scale. When you're starting a startup, scaling out your application to hundreds, thousands, or millions of servers isn't somethi…

I was with you up until the last paragraph. Taken literally you seem to suggest there is no such thing as a CPU-bound workload. That's obviously not the case (cryptography is just one such example), but I would agree that many people think they are CPU-bound when they are really constrained by something else. Secondly, Python and the patterns its expressiveness encourages are terrible for cache performance. In a simp…

Good point. I see what you're saying and I was definitely not suggesting that. I was speaking mainly from a web application perspective, where program execution on the server is very low on the list of items affecting application speed as perceived by the end-user.

Scientific computing, on the other hand, is a completely different animal.

Re: Python’s Weak Performance Matters

#272

Post by bbatha » Wed, Feb 07, 2018, 5:11 PM UTC

halbritt wrote: post #265

bbatha wrote: post #239

Earlier quoted context omitted.

> The quoted argument that "easy to write but slow languages are better because programmer time is far more costly than CPU speed" was pretty common, and I honestly think correct, 10-15 years ago. But things have changed. I don't think things have fundamentally changed in the programmer time is cheaper than cpu time calculation. What has changed is: 1. Classic dynamic languages (ruby, python, etc) all heavily assume…

To your point 1: This is the reason that AsyncIO exists in Python 3.6 and IIRC Facebook is pushing really, really hard to adopt it.

Absolutely, but its arguably 10 years too late. Node has already eaten python's lunch in the server space. To get your existing python code working on async you may basically need a full rewrite including any libraries that you pulled in. At that point most companies ask themselves if python is really the right language to conduct a rewrite in.

Re: Python’s Weak Performance Matters

#273

Post by cjalmeida » Wed, Feb 07, 2018, 5:15 PM UTC

mark_l_watson wrote: post #148

banku_brougham wrote: post #46

I’d like to thank the author for sharing a very practical view of problem solving in the data science space. Can I suggest julia? Its very easy to understand coming from python, and performant code can be had usually in easy to read implementation of the expressions in whatever paper you are basing your work upon.

Thanks for mentioning Julia, a good solution to slow Python code. I used Julia for 2 weeks last year on a consulting gig, and despite rough spots and given more development time, Julia might become fairly popular. I have never been much of a fan of Python. 15 years ago at lunch Peter Norvig was talking about the advantages of Python (he and I wrote Common Lisp books at the same time). I then tried Python for a few mo…

This. I can't emphasize enough how type hints + decent IDE is useful to productivity.

Cython is also pretty good. My tip to write fast Cython is to code as if you were writing pure C and forget higher level constructs. This way it gets translates to C almost 1:1 with all performance benefits.

Alternatively, if you do need more abstraction, you can write nice C++14 and use Cython as glue code.

Re: Python’s Weak Performance Matters

#274

Post by cjalmeida » Wed, Feb 07, 2018, 5:24 PM UTC

pleasecalllater wrote: post #146

hidenotslide wrote: post #29

I don't find this a very compelling argument. The author doesn't mention any attempts to profile or speed up the code. Specifically with pandas I've found if you aren't careful you can do a lot of unnecessary copying. Not sure if that's what is going on here, but cProfile can help find the bottlenecks.

Well, I just wanted to use pandas to load a 4GB csv file. After using 32GB of my RAM, and 4GB of swap I gave up. I've just loaded all that data to Postgres, and made a couple of queries. This way I stopped using pandas at all.

I found that pandas is great for data exploration and data that you know is small (few 100s MB). Other than that, Python builtins and numpy arrays are a better alternative.

Re: Python’s Weak Performance Matters

#275

Post by cjalmeida » Wed, Feb 07, 2018, 5:27 PM UTC

luispedrocoelho wrote: post #42

gh02t wrote: post #22

Earlier quoted context omitted.

Honestly, NumPy is gonna be hard to beat even for someone knowledgeable in certain use cases, especially ones where the overhead in Python is trumped by time spent in library calls. It's the same reason that it's hard to beat MATLAB or Mathematica in cases they are optimized for despite being relatively slow languages. They are calling some of the most heavily optimized libraries in existence (e.g., BLAS) and using h…

"spending an hour figuring out what arcane incantation I need to pass to np.einsum to get the operation I want" Yes, I have also had this experience and I hate how in the end, the code is very hard to read, while the for loop was probably trivial.

Every time I thought I needed einsum or similar arcane ops, I found that a Numba optimization for loop did the job.

Re: Python’s Weak Performance Matters

#276

Post by deathanatos » Wed, Feb 07, 2018, 5:29 PM UTC

I agree with some of this, such as,

> Python, it is slow as molasses. I don’t mean slower in the sense of “wait a couple of seconds”, I mean “wait several hours instead of 2 minutes.”

Python can be multiple orders of magnitude slower than the equivalent in C/C++/Rust, but,

> more cores (which Python cannot easily take advantage of)

Python's multiprocessing makes launching new processes (which can take advantage of more cores) pretty much as easy as launching threads.

But as a developer, I am frustrated by a lot of the things people believe are options. They are options, but … they're hard to use, and hard to take advantage of.

* Writing a Python extension requires dropping down to C, which has so many foot-guns, I'd like to delay doing so as long as absolutely possible. Even then, you might not be able to win back that much performance, if most of your time is spent manipulating Python objects. Programmers, in my experience, also vastly overestimate their ability to write correct C.

* Cython can compile Python to "C", but in Python 2 (which I am alas stuck with, despite my will; someday…), has a bug that miscompiles code dealing with metaclasses. Worse still, the latest version of six will trigger this bug. (The Cython developers do not consider this — Cython's compiled version of code behaving differently from Python and CPython — a bug.)

* rust-cpython is theoretically great, but has a bug on OS X that causes aborts (it erroneously links against the Python binary, I think, and this causes issues w/ virtual environments, where a different binary ends up getting used. I don't think this effects Linux, but I need to support OS X.)

(Throw in the enormous amount of time that I spend debugging object of type NoneType has no attribute "static_typing", and the amount of time that I spend wonder "what type is this variable supposed to be? and working it out by reverse engineering the code, and I honestly wonder if Python is actually "faster".)

[1]: https://github.com/dgrunwald/rust-cpython/issues/59

Re: Python’s Weak Performance Matters

#277

Post by blub » Wed, Feb 07, 2018, 5:38 PM UTC

lmm wrote: post #237

blub wrote: post #228

Earlier quoted context omitted.

This "make it work" adage makes no sense at all when scrutinized. Does anyone believe that other industries think like that? First let's invent a washing machine that washes, but occasionally sets clothes on fire and takes 24h for a washing cycle. Then we'll redesign it so it doesn't set things on fire, and finally redesign it yet again to finish in 2h. It's incredibly wasteful. For any complex project, making it wor…

> Does anyone believe that other industries think like that? Software is very unlike other industries. > For any complex project, making it work and fast only at the end will either result in massive cost overruns or an outright canceled project. Citation needed, because my experience is the exact opposite: projects that put effort into making it fast from the first never get off the ground.

Software is different, but it doesn't bend space and time. Redesign costs can be significantly cheaper, but they are still present, and if the project is complex enough can be just as high as in physical world project catastrophes. I assume you have heard of various software projects which cost millions and overshot their budget by 50%, 100%, 200%, etc...

Now regarding the make -> work -> fast cliché: I tend to have architectural discussions at the beginning of the project, which include among other things performance. Depending on the project it might be a surface discussion, or go deeper.

Then based on the performance requirements and design decisions, the system is implemented, performance is tracked and adjustments are made. So performance should not be put first, middle or last, it's an architectural level concern which is controlled throughout the project.

How do those of us that like to complain about "premature optimisation" whenever performance is discussed design software? Because based on HN discussions it looks like code & pray.

Re: Python’s Weak Performance Matters

#278

Post by apendleton » Wed, Feb 07, 2018, 5:38 PM UTC

jakear wrote: post #238

uluyol wrote: post #220

Earlier quoted context omitted.

> If you're a startup and your 100x more performant Go code takes an extra 3-6 months to write I can write Go code nearly as fast as Python, sometimes faster if I need to refactor. Obviously this depends on familiarity with languages, but I think most of difference is probably experience with the language more than anything else. > 100x difference in CPU time is nothing compared to the 1000x loss in a cache hit or a…

To me the last sentence nullifies the entire argument. People doing a lot of numeric computations aren't (typically) doing it all in Python. They write critical sections in C (or some other "fast" language), or use existing libraries that already have done so. If they aren't writing those sections in C already, perhaps because they don't know how, or it would take too long to do right, then why would they ever choose…

Firstly, not everyone doing performance-sensitive work is doing numeric work (that seems to have been a motivator for writing this article), so numpy isn't always practical. Secondly, I think the "if it's slow just rewrite the hard parts in C" is generally out of step with more modern options. Python gets you a really nice environment that's super pleasant to work with... until suddenly it doesn't and you're backed into a performance corner, and then you potentially need to conquer a major learning curve, take a huge usability hit, sacrifice memory safety, etc. There are increasingly common options now that let you get near-C performance for many applications while also totally avoiding that cliff. For applications that have even a decent chance of eventually needing that kind of work, I think it's reasonable to ask why you'd want to chance it when you could just write it in something both reasonably fast and much more pleasant than C from the get-go.

Re: Python’s Weak Performance Matters

#279

Post by brians » Wed, Feb 07, 2018, 5:39 PM UTC

blub wrote: post #228

lmm wrote: post #203

Earlier quoted context omitted.

> It is a failure of our community that we allow languages to proliferate while remaining slow. This is bad because allowing slow tools to become popular means people create slow things, which wastes other peoples time and energy. Make it work, then make it work right, then make it work fast. I mean yes, a lot of things are slower than they should be, but the level of outright correctness bugs in software today is mi…

This "make it work" adage makes no sense at all when scrutinized. Does anyone believe that other industries think like that? First let's invent a washing machine that washes, but occasionally sets clothes on fire and takes 24h for a washing cycle. Then we'll redesign it so it doesn't set things on fire, and finally redesign it yet again to finish in 2h. It's incredibly wasteful. For any complex project, making it wor…

Yeah. Speed is the dominant cost in software, but other industries treat other costs similarly. To pick another darling, look at Tesla: the Roadster is expensive, flammable, suitable only for enthusiasts. The S is generally useful, but too expansive. Still a narrow market. The E is their first general purpose product.

That’s normal. Same deal with Apple II, Mac, iPhone. Same deal with ether, coarse general anesthetic, modern mixes.

Yes, this is completely normal, and software based products should expect to evolve similarly.

Re: Python’s Weak Performance Matters

#280

Post by blub » Wed, Feb 07, 2018, 5:40 PM UTC

DrJosiah wrote: post #240

gameswithgo wrote: post #196

Earlier quoted context omitted.

I would argue that performance always matters, and that Python is never the right tool for the job in an absolute sense. Python may be the right tool for the job given the options we have today but there is no reason we cannot have a language exactly as nice to use as Python is, but that also provides good performance. Languages like Nim or F# approximate that ideal, for instance. And while I realize there are high p…

As a guy who just spent the past summer doing (his 19th year of) Python, (6rd year of) Cython(/Pyrex), and (8th year of) C, picking around PyPy, and writing a couple transpilers; the tools are incredible. And I think you're talking out your butt here. Speed is a matter of choice and a bit of manual tooling. You seem like a Golang advocate; great. I hope it continues to work for you. Python solves 95% of problems toda…

"You want performance in Python? Okay. Where do you want performance? If there isn't already a library there to help you, I'd be very surprised."

I assume you haven't read the article, but give it a try. The author explains where they wanted performance and that there was no library, so they had to write some ugly code instead.