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

Python’s Weak Performance Matters

metarabbit.wordpress.com

Post reply on HN
Print view View original

291–300 of 336 posts

Re: Python’s Weak Performance Matters

#291

Post by narimiran »

alecco wrote: post #136
narimiran wrote: post #102

If you would like 10-100x faster performance than Python, but would like to keep the easy-to-read code, give Nim [0] a try. I do all my work in Python, and I've been using Nim in last couple of months - it took me a week or two until I was able to be productive in Nim. Don't expect Python's large ecosystem, nor some Python goodies, but if you're looking for a readable, writable, high-performance post-Python language…

Or just program a module in C or Cython.

> Or just program a module in C

You can do that in Nim - it compiles to C.

If you have no previous knowledge of C, with Nim you get C-like speed with Python-like easy to write syntax.

Re: Python’s Weak Performance Matters

#292

Post by dragonwriter »

narimiran wrote: post #102

If you would like 10-100x faster performance than Python, but would like to keep the easy-to-read code, give Nim [0] a try. I do all my work in Python, and I've been using Nim in last couple of months - it took me a week or two until I was able to be productive in Nim. Don't expect Python's large ecosystem, nor some Python goodies, but if you're looking for a readable, writable, high-performance post-Python language…

> If you would like 10-100x faster performance than Python, but would like to keep the easy-to-read code, give Nim [0] a try.

Why not Cython, which gives speedups in those ranges, is more familiar to Python developers and fully integrated into the Python ecosystem?

Re: Python’s Weak Performance Matters

#293

Post by [deleted] »

lmm wrote: post #203
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…

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

[deleted]

Re: Python’s Weak Performance Matters

#294

Post by gh02t »

cjalmeida wrote: post #275
luispedrocoelho wrote: post #42

Earlier quoted context omitted.

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

Numba is nice, but it's another large dependency to pull in. If I can avoid it I will.

Re: Python’s Weak Performance Matters

#295

Post by dragonwriter »

weberc2 wrote: post #181
alecco wrote: post #136

Earlier quoted context omitted.

Or just program a module in C or Cython.

Which is error prone and often actually slower depending on calling patterns between C and Python. There are many languages today that offer better ergonomics than Python/C, and a few (like Go) which offer better ergonomics than Python by itself, all while besting it in performance by one or more orders of magnitude. I like Python; I just wish I could say the same for its developers...

> There are many languages today that offer better ergonomics than Python/C

Including Cython. I mean, if you've got a C library, sure, interface it with Python; but unless you want something to be called from something else in addition to Python, dropping to C for performance needn't be the default choice in Python; that's the whole reason Cython exists.

> and a few (like Go) which offer better ergonomics than Python by itself

I find Go’s ergonomics to be worse than Python but better, mostly, than Java.

> all while besting it in performance by one or more orders of magnitude.

And, still, including Cython.

Re: Python’s Weak Performance Matters

#296

Post by aldanor »

b0rsuk wrote: post #156

Is writing extensions a lost art? I read a few blog posts about speeding up Python and Ruby with Rust extensions. This should enable rewriting only the slow parts. Later, you could replace more of it if needed. Is writing extensions so very problematic in practice? I know Go has runtime issues making it not very good for mixing with other languages, so it often encourages rewriting the whole application in it.

Most definitely not. You can write C++ extensions inside Jupyter notebook these days ([1]) -- thanks to libraries like pybind11 [2].

[1] https://github.com/aldanor/ipybind [2] https://github.com/pybind/pybind11

Re: Python’s Weak Performance Matters

#297

Post by walterstucco »

smoe wrote: post #231
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…

How many people are there who actually need to scale an application across hundreds, thousands, or millions of servers vs the ones that think they are going to need it? I agree that at some point CPU speed is more expensive than programming time, but how many applications in the wild are actually at or beyond that point? I would be surprised if it is more than a couple of percent. Sure if I know that a product has to…

The argument works both ways

Imagine you spend $200 a month on Amazon and can cut it to just $50 with a faster and less memory taxing language

You suddenly have more money to spend on something else

Re: Python’s Weak Performance Matters

#298

Post by empthought »

bzbarsky wrote: post #235
NoahTheDuke wrote: post #207

Earlier quoted context omitted.

Because Python doesn't have block scoping, only function scoping.

Yes, my point is that function scoping can hardly be described as "makes sense all the time". Especially given that variable declarations in python are _very_ implicit, without even the "var" that will indicate to you that you're messing with your function scope in JavaScript.

> Yes, my point is that function scoping can hardly be described as "makes sense all the time".

Block and function scoping both "make sense all the time." Whether or not you personally are accustomed to a language's design decisions does not have any bearing on whether or not those decisions "make sense."

In the particular case you cited, of course it is natural that `foo` is in scope outside of the loop; it appears in a line outside of the loop. This is trivially evident in the indentation.

Re: Python’s Weak Performance Matters

#299

Post by narimiran »

tekkk wrote: post #177
ptype wrote: post #106

I love Python. The language is a joy, the eco system is fantastic. But yes, let’s be honest, if you can not vectorise your code it is slow, and I think that will be its downfall eventually. I’m excited about Julia, I hope it gains popularity and the eco system grows. Until then, and in particular until the data frames story can compete with pandas, it Python with Cython for me, but I’d rather skip the Cython if it wa…

I feel bit ambivalent about Python as it's a nice language for prototyping and quickly hacking things done. Yet I'm always baffled when I read Numpy's or Matplotlib's documentation and try to make sense of it as it can be (or at least feel) so complex and highly ambiguous. Eg. sometimes there is no/very brief examples at Numpy's documentation pages how the method works and most results from Google are only about adva…

> In Matplotlib I still don't understand what is the right way of initializing a pyplot, there seems to be a million ways to do it and a million parameters you can give. API changes and inconsistencies too pain me at times

Matplotlib has the worst API of all Python libraries I have used over the years!

If there were a fork of it that got rid of Matlab-way of doing things (keeping only OOP style) and with consistent names (no more `twowords` and `two_words`), I would gladly switch in a heartbeat.

Re: Python’s Weak Performance Matters

#300

Post by bzbarsky »

empthought wrote: post #298
bzbarsky wrote: post #235

Earlier quoted context omitted.

Yes, my point is that function scoping can hardly be described as "makes sense all the time". Especially given that variable declarations in python are _very_ implicit, without even the "var" that will indicate to you that you're messing with your function scope in JavaScript.

> Yes, my point is that function scoping can hardly be described as "makes sense all the time". Block and function scoping both "make sense all the time." Whether or not you personally are accustomed to a language's design decisions does not have any bearing on whether or not those decisions "make sense." In the particular case you cited, of course it is natural that `foo` is in scope outside of the loop; it appears…

The context is that we're talking about people picking up the language for the first time, coming from other languages. What matters is whether the scoping rules make sense to such people.

For that, it matters whether they're coming from another function-scoped language (or are familiar with one), and whether they're used to having their variable declarations being obvious or not.

For me, when I was first learning Python, this scoping issue was a significant pain point. This is obviously an anecdote, not data, but again for purposes of "people first coming to the language" it's relevant.

Obviously once one has worked in Python for a while one internalizes things like this, just like one internalizes various things in other languages that are obvious pain points for beginners.

Post reply on HN