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

Python is Slow, and I Don't Care

medium.com

Post reply on HN
Print view View original

61–69 of 69 posts

Re: Python is Slow, and I Don't Care

#61

Post by thesmallestcat »

jackmott wrote: post #34
rakoo wrote: post #28

Earlier quoted context omitted.

> then later rewritten in C++ or Go, and generally ran with 100x fewer resources This kind of story comes again all the time, but the most important detail is always missing: how much of that 100x can be attributed to the language, and how much can be attributed to now I know the domain better, I know where the pitfalls are, how to model the problem, and when I need to optimize ? Because arguably the second one can b…

In my own deep experiments with simplex noise generation in c++ and C#, C++ allowed me to go ~10x faster and it was 100% due to the 'language' (and associated ecosystem). Domain knowledge for me is higher in C#, both were optimized as far as I could figure out. There are dozens of cpu instructions you can't even make happen in most runtime GC languages. It is banananastown.

You could get similar performance with a C or C++ extension, or by using Cython. 99% of your application is probably not generating simplex noise or doing anything CPU-bounded like that.

Re: Python is Slow, and I Don't Care

#62

Post by khedoros1 »

poikniok wrote: post #58
std_throwaway wrote: post #44

Earlier quoted context omitted.

It's about half and half, 50x comes from the language and 50x comes from experience. The important part is to add those factors together by good management.

The math here doesn't really make sense, factors multiply, so if there were two 50x factors the total improvement would be 2500x. In other words if one factor is 50x, the other one must be 2x to get 100x total.

This is useless pedantry. You know what they were trying to say: The improvement can be attributed equally to using a more suitable technology and to better knowledge of the problem domain.

Re: Python is Slow, and I Don't Care

#63

Post by qbrass »

throwaway2048 wrote: post #14
nhumrich wrote: post #10

Earlier quoted context omitted.

Maybe I'm daft, but I don't quite understand what your getting at.

translated: We dont care if our software runs like crap for you because our time is more important than your user experience.

It runs like crap, but still saved an hour a day over doing it by hand.

Does the fast version save you more time than it cost by not being available?

Re: Python is Slow, and I Don't Care

#64

Post by pbreit »

lawnchair_larry wrote: post #55
pbreit wrote: post #21

Earlier quoted context omitted.

Isn't Python3's primary issue that it killed developer productivity?

How would it do that?

Major project just to stay in place. And then all the modules that aren't ready. Basically tons of work just to get the same result. Infinitely unproductive.

Re: Python is Slow, and I Don't Care

#65

Post by BenFrantzDale »

Along these lines, the first major Python project I used I was amazed Python was used. It's a real-time 3D reconstruction system operating on a live video stream. That was ten years ago.

There was some assembly and C at the very core, but every point generated was a Python tulle at one point in processing.

Re: Python is Slow, and I Don't Care

#66

Post by khedoros1 »

nhumrich wrote: post #25
throwaway2048 wrote: post #14

Earlier quoted context omitted.

translated: We dont care if our software runs like crap for you because our time is more important than your user experience.

I think your misunderstanding the tone of the article. I mention how the bottleneck is usually not the language. It IS important to optimize, but its important to understand where the real issue is. I later explain that things have to be only "good enough". And I also explain how you CAN optimize python when it IS to slow for your users.

From their viewpoint: The biggest cost for the company that implements something is their employees' time, and that's likely true of your customers, as well. Your costs are easily measured by you; the customers' costs aren't. Reading the article, it's a little grating that their costs aren't given the same weight as yours.

From your viewpoint: You've got a large constant X (representing time taken doing something un-optimizable like I/O), a small constant Y (representing the "language multiplier"), and a small constant Z (representing CPU-heavy work). So you've got something like Time=N(X+Y*Z), which for values of Y and Z in your work, means that X is by far the largest timesink.

From my viewpoint: You're talking past each other, imagining different constants. It's also interesting to me that a program is still considered written in "Python" if the interesting parts are actually in C, and called from Python. You make points that I agree with about premature optimization, but I think the way you wrote your article opens it to easy misinterpretation, since everyone will view it through their workloads (which may vary strongly from yours). I would've limited the discussion explicitly to the kinds of use-cases you're thinking of.

Re: Python is Slow, and I Don't Care

#67

Post by kajecounterhack »

lawnchair_larry wrote: post #50
titzer wrote: post #11

If your reasoning is productivity above everything, therefore the only solution you can think of is Python, I call BS. As a Googler, I could relate countless stories of systems that were cobbled together in Python and then scaled up with massive investment, then later rewritten in C++ or Go, and generally ran with 100x fewer resources. Hell, from what I can tell, almost all of YouTube was written in Python and has or…

I bet the youtube founders would disagree with you. They probably do not regret launching it quickly in python, selling it to Google for over a billion dollars, and letting Google spend the next decade rewriting it.

If they didn't sell, they would have had to do the rewrite.

There are plenty of future YouTubes who don't want to be acquired and instead are looking to be long term companies. They'd do well to avoid the pain and cost. There are ways to achieve velocity and maintainability, they're not mutually exclusive.

Re: Python is Slow, and I Don't Care

#68

Post by candiodari »

staticassertion wrote: post #47
rakoo wrote: post #28

Earlier quoted context omitted.

> then later rewritten in C++ or Go, and generally ran with 100x fewer resources This kind of story comes again all the time, but the most important detail is always missing: how much of that 100x can be attributed to the language, and how much can be attributed to now I know the domain better, I know where the pitfalls are, how to model the problem, and when I need to optimize ? Because arguably the second one can b…

I've written 1 to 1 (algorithm) code from Python to Rust and seen orders of magnitude performance/ memory difference. This was not a 'rewrite it with lessons learned' this was 'rewrite it as similarly as possible'. It is the language (and runtime).

This is why C++ (and maybe Rust, damn I need to learn Rust) will keep existing forever. If cloud deployments make sense, then optimizing by rewriting into C++ also makes a lot of sense, as it provides a continuous direct savings: your bill goes down by a directly quantifiable amount.

Re: Python is Slow, and I Don't Care

#69

Post by guohaochuan »

titzer wrote: post #11

If your reasoning is productivity above everything, therefore the only solution you can think of is Python, I call BS. As a Googler, I could relate countless stories of systems that were cobbled together in Python and then scaled up with massive investment, then later rewritten in C++ or Go, and generally ran with 100x fewer resources. Hell, from what I can tell, almost all of YouTube was written in Python and has or…

As others' comments, it's totally different maintaining a successful business from launching one. The decision should be based on what value the language can provide.

I'm in a very python heavy company, and maintains the python architecture that are being used on hundreds of servers. The ugly part(lack of restriction, multiprocessing, distribution) quickly shows why it's not suited for very large system.

But I'm curious at which point, we would be so annoyed as to decide to rewrite the whole stuff.

Post reply on HN