News for hackers. Stuff that matters.
Re:Why Python is Slow: Looking Under the Hood (2014) by weberc2 on Wednesday October 25, 2017 @08:15PM (#15555394)
> My point was simply that while it's easy to sit around talking about microbenchmarks that's not helpful for most developers.

To be clear, I never mentioned or implied microbenchmarks.

> Most developers are not employed to make a single thing as fast as possible but instead have to ship new features on a regular basis, handle a wide range of inputs correctly, etc.

I absolutely agree that performance is just factor among many, but the scope of this entire post is "performance". Most of your points seem to pertain to "the biggest performance problem I see is with poor engineering practices". This is definitely a problem, and you're right to prioritize addressing it over choosing a fast language. No language is going to fix stupid, although I will say that Go makes it less appealing to write stupid code, thanks to its restrictive type system. So once you've fixed your stupidity problem, the language-level problems will start to crop up. :)

And by the way, since you mentioned memory access patterns and I/O, I want to point out that these are also language-level concerns. Since everything in Python is a reference into a random location of heap, memory access performance is terrible. Go lets you specify whether something is a pointer or a value, which means you can specify which things are collocated. This is important for good cache performance. Regarding I/O, Python makes you choose between async for performance or sync and your process does no work until the I/O completes. Go lets you write normal synchronous code, and the runtime/scheduler make async calls under the hood so code which doesn't depend on the result of your I/O can execute while other code blocks.

> Given unlimited time and budget, yes, a compiled language will probably win but for most projects the better question is “what tools will allow me to meet my goals with acceptable performance?” and that's a very different question.

It is a very different question, but as new compiled languages improve on ergonomics without compromising performance and as new interpreted languages improve on performance without compromising ergonomics, the answer will increasingly become "not CPython" (Python is the fastest growing language in 2017, but that's largely due to a surge in data science popularity; however, since Python is popular with the data science community largely because of its libraries and not language features, other languages will catch up [and indeed are catching up] quickly).

Re:Why Python is Slow: Looking Under the Hood (2014) by igouy on Thursday October 26, 2017 @10:00AM (#15558838)
> To be clear, I never mentioned or implied microbenchmarks.

> As for "what I benchmarked", my comment was based on a decade of experience with these languages…

No doubt others have based their comments on their experience, which they trust more.

Re:Why Python is Slow: Looking Under the Hood (2014) by weberc2 on Thursday October 26, 2017 @01:24PM (#15561027)
I don't disagree; the parent asked where I got my estimates from and I answered.
Re:Why Python is Slow: Looking Under the Hood (2014) by igouy on Thursday October 26, 2017 @09:51AM (#15558765)
> Python is the fastest growing language in 2017, but that's largely due to a surge in data science popularity…

How do you know - "that's largely due to"?

Re:Why Python is Slow: Looking Under the Hood (2014) by weberc2 on Thursday October 26, 2017 @01:24PM (#15561042)
There were a lot of analyses that came out about this recently. I don't remember specific articles, but they floated around this and other fora. I think StackOverflow may have had one.