Hacker News new | ask | show | jobs
by mlyle 1205 days ago
Sure, and if you can't get stuff in and out of Python objects with concurrency, it doesn't help you much a lot of the time. Plus, again, computing is cheap: it'd be nice to use all my cores before I spend a lot of effort optimizing and rewriting things in native code.
1 comments
VHRanger 1205 days ago
That's a data layout problem largely, though.

If your data is fragmented across a bunch of small containers/classes, passing it around will be expensive whichever the method (either passing to C++, or just in terms of cache efficiency).

If you just pass an array of data back and forth it's cheap.

link
mlyle 1205 days ago
> If you just pass an array of data back and forth it's cheap.

Yes, and numpy is great, and all. Python works great as glue to marshal things to and from native code and do inexpensive (but possibly complicated) bits of control logic.

But if I'm trying to deal with large numbers of client requests, say... the lack of concurrency in python itself really hurts. Sure, I can punt almost everything to native code, but what's the point in having Python at all, then?

Not all problems have state that can be shared well across Multiprocessing or completely externalized to large lumps that travel to native code in a few calls-- I'd actually say these are special case exceptions than the rule.

link
VHRanger 1205 days ago
Right, if your issue is that you're getting a ton of small, individual API calls, python will suffer.

At that point you'd look to Go or another language, and also carefully choose the REST API framework you're setting up.

Note that having a solution setup where the end result is "a ton of small, individual API calls" could possibly indicate a bad system architecture.

link
mlyle 1205 days ago
> Note that having a solution setup where the end result is "a ton of small, individual API calls" could possibly indicate a bad system architecture.

Or just a lot of clients with a fair bit of shared state which is best kept resident, which is a pretty common use case.

It's a bummer to write python code that works well, and then maxes out at 130% CPU load when you grow your usage... and not have any obvious path to scale upwards despite you having 32 threads of execution around. Then, you can rewrite some of the more expensive things in native code to squeeze a little more performance, or add indirection to store the data somewhere else so multiprocessing works.

Other languages that have more finely grained locks scale 3-4x higher with minimal thought, and much, much higher with a bit of thought about how to handle locking and data model.

> At that point you'd look to Go or another language

Well, yah... this is us complaining about Python's concurrency problems.

link