Python’s Weak Performance Matters • Hacker News Board

Re: Python’s Weak Performance Matters

#261

Post by dahart » Wed, Feb 07, 2018, 4:45 PM UTC

cbcoutinho wrote: post #245

dahart wrote: post #221

> It is true that programmer time is more valuable than computer time, but waiting for results to finish computing is also a waste of my time (I suppose I could do something else in the meanwhile, but context switches are such a killer of my performance that I often just wait). In film CG production, we had a rule of thumb. If running an interactive program takes longer than about ten seconds, the artist (user) becom…

Somewhat tangential to this, but I remember reading an article on HN about a group creating some web app that was constrained by some size limit (50 KB or so). Groups ended up putting 'dead code' in their projects to guard against other groups taking their space while they were working on their feature. I think this made it so the app never got less than 50... Did you ever see something similar where devs put in some…

Oh yeah, this is very common in game development, and I'm pretty sure in other embedded dev too. There's a famous story about a game programmer who saved an entire production when it started crashing something like two weeks before shipping by commenting one line of code. Turned out the line of code was a malloc (of like a megabyte) that he'd added a year earlier, in anticipation of the game running out of memory. My details are probably wrong, but I'm pretty sure I've seen this story linked on HN.

I was in game dev for a decade, and I saw this happen where I worked, the studio technical director adopted the practice of saving some space, because we always started running out of memory near the deadline as artists threw in all their content.

*edit: http://www.dodgycoder.net/2012/02/coding-tricks-of-game-deve...

Re: Python’s Weak Performance Matters

#262

Post by deathanatos » Wed, Feb 07, 2018, 4:47 PM UTC

fafhrd91 wrote: post #176

jerf wrote: post #162

Earlier quoted context omitted.

Extensions aren't a total solution, though, which people often sell them as. You have an impedance mismatch between Python and C code, because Python has all of its objects packed in a way that is very strange to C, so you end up essentially deserializing all objects into C, then back out into Python, in a very expensive and allocation-heavy (on both sides) conversion. If you can set up your computation in Python and…

Python extension doesn’t mean C. Rust works perfectly for extensions, it covers a lot of low level c-api integration and it is fast. You can write whole application in rust and use python as a glue language https://github.com/PyO3/pyo3 Pyo3 library gives you ability to work both diractions. Call python code from rust and call rust code from python.

PyO3 is a fork of rust-cpython, which has a nasty abort issue[1] which is unfortunately a show-stopper for me. It isn't clear to me if PyO3 is also affected by this issue.

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

Re: Python’s Weak Performance Matters

#263

Post by cjalmeida » Wed, Feb 07, 2018, 4:50 PM UTC

banachtarski wrote: post #71

inciampati wrote: post #68

Earlier quoted context omitted.

If you write more C++ than python, it will have a lower TimeToWriteCode. Despite having spent years writing python I don't find it any more productive than C++. C++11 has all the nice features you might expect from python with the only drawback being the lack of a REPL.

+1 people shouldn't overlook things that are bundled in the C++ stdlib now (chrono, random, thread, algorithm, mutex, containers, etc)

They're great and incredibly useful. And one should not forget that you can easily use them in a Python extension written in C++14 and exported using Cython or SWIG.

Re: Python’s Weak Performance Matters

#264

Post by mschaef » Wed, Feb 07, 2018, 4:55 PM UTC

Great article. The way I look at it is something like the swordsman scene in Raiders of the Lost Ark. The swordsman's doing fancy optimizations and C just blows away the need.

If you can find a language that's x100 the performance of an interpreted language, that speed delta will cover up lots of naivety in the code you write.

Re: Python’s Weak Performance Matters

#265

Post by halbritt » Wed, Feb 07, 2018, 4:56 PM UTC

bbatha wrote: post #239

skywhopper wrote: post #198

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. 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 re…

> 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.

Re: Python’s Weak Performance Matters

#266

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

blub wrote: post #222

theli0nheart wrote: post #209

Earlier quoted context omitted.

You're conflating Python the language and Python the default runtime implementation (CPython). PyPy, a Python JIT compiler, has shown you can have an incredibly fast Python implementation. In some cases, it's faster than C. Maybe this is what you're looking for. :) http://speed.pypy.org

Python and CPython are the same thing for the majority of Python developers, just like the Oracle JVM is a synonym of Java. Yes, there are other exotic runtimes, but only one official one and that's what people will use.

I get that, and I agree, but my point was that if you're writing Python and finding that your code is too slow, it's far easier to just drop in a faster runtime than it is to rewrite your entire existing codebase in a new language.

Re: Python’s Weak Performance Matters

#267

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

lmm wrote: post #215

munro wrote: post #66

> At the same time, data keeps getting bigger and computers come with more and more cores (which Python cannot easily take advantage of), while single-core performance is only slowly getting better. Thus, Python is a worse and worse solution, performance-wise. PySpark is makes it really easy to take advantage of multiple cores & machines. Most operations I want to do to my data I can find in PySpark's pyspark.sql.fun…

Spark is great, but at that point why not just use Scala? It offers Python-like conciseness/productivity, and by using the same language Spark is written in you avoid a big class of possible interop issues.

PySpark should only be used for prototyping. It add an enormous extra overhead on operations due to serializing data back and forth between the Java and Python processes.

Re: Python’s Weak Performance Matters

#268

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

rhodysurf wrote: post #168

scribu wrote: post #149

Earlier quoted context omitted.

I think the article makes a lot more sense if you consider it in the context of "Python for data science". In the last few years, there's been a lot of hype about replacing other number crunching solutions (R, SPSS, even Matlab) with the Python ecosystem of tools (Pandas, SciPy, etc.).

Except Pandas and SciPy use libraries written in CXX or Fortran and not pure python so speed is not really an issue with them usually

pandas.read_csv is kind of abysmally slow, unfortunately. There are a couple of alternatives, but nothing has really taken hold.

Dask exists, but not everyone can run a distributed system to read a multi-gigabyte csv.

Re: Python’s Weak Performance Matters

#269

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

kazagistar wrote: post #232

autokad wrote: post #152

Earlier quoted context omitted.

i dont seem to follow. if you are doing data science, all the bottle necked stuff will be running in numpy or pyspark. Choosing python over R, SPSS, Matlab usually doesnt come down to which one is faster, and R as far as i know is at least not vastly superior in speed.

This was explicitly addressed in the article: as soon as you have to do anything which isn't a trivial numpy operation, performance goes off a cliff, and that can be a problem.

This also isn't necessarily true. Take the example of TensorFlow. You build a representation of the computation you want to run, and then you can run nearly the whole thing end-to-end in native C++ using Eigen data structures, with occasional shuttling of data back into PyObjects (rare) or numpy (common) for metrics tracking.

Cython is a much more powerful tool than I think the author of this article realizes.

Re: Python’s Weak Performance Matters

#270

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

Sad not to see Cython getting a mention in this post. It is a superset of Python, so your vanilla code will run just fine, and you can optimize slow parts to native-speed. It's a fantastic tool.