3 ms·

Probably a bit of both, but python and other dynamic languages make doing the smart thing very difficult. While I continue to work professionally in both stati

by lumost 7y ago

Probably a bit of both, but python and other dynamic languages make doing the smart thing very difficult. While I continue to work professionally in both static and dynamic languages, I've observed a few limitations that prevent writing a fast python webserver - The Global Interpreter lock - you can't avoid forking processes in order to handle concurrent python code. - Threads are cheaper than processes. A default java thread carries 2MB overhead, a python process for a typical app can easily be 2GB without very careful memory consideration. - The pure single-threaded python runtime is 10-100x slower than your typical statically typed language, even when doing everything as carefully as possible you'll be 1-2 orders of magnitude off the best implementation in a statically typed language. Conversely a sloppy implementation in a statically typed language will probably work about as well as the best python implementation. - Foreign Function Interfaces(FFIs) are slow, in Python an int32 consumes 24 bytes of memory whereas in C the int32 consumes 4 bytes. Stringing together 2 C calls that manipulate an int with python would require 4 allocations and 4 casts. Applications that avoid this overhead have to adopt symbolic APIs that inform an underlying C program how to connect multiple function calls and will grind to a halt if there is any python control flow e.g. TensorFlow. Most of these limitations tend to be common to other dynamically typed languages such as Ruby, PHP, and Perl. While one can theoretically "drop down to C", it's often not that straightforward in common development scenarios. For businesses that require high(er) throughput, or low(er) latency the time spent fighting the interpreter or the associated AWS bills may not be worth the productivity gains from dynamic types in 2020 when compilers can perform an incremental build in milliseconds.

_bxg1 7y ago
I don't think it's productive to argue that non-dynamic languages are superior across the board. Everybody knows they're faster. For many people, they're still the right decision. I think (or at least assumed) that the post's discussion is more interesting than that. A sibling comment seemed to be zeroing in on the crux of the issue. "Python is an order of magnitude slower but it's web server is two orders of magnitude slower" is a meaningful and fruitful thing to talk about.
- lumost 7y ago
  That's fair, however the python language is two orders of magnitude slower than it's static brethren for a variety of tasks. Pretty much any time you need to use the native language in the interpreter. https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/python3-java.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... It may be worth looking at how this performance gap has trended over time. Anecdotally I recall the performance gap being much narrower 10 years ago.
hermitdev 7y ago
> a python process for a typical app can easily be 2GB without very careful memory consideration. Sorry, this is not true. I have a Python app that uses 2 threads. It's memory doesnt even exceed 200 MB. Yes, Python threads generally suck because of the GIL, but they dont cause memory bloat like what you're describing. For context, I use Python extensively for extract/transform/load (ETL) work. I deal with quite large files. My loaders all run in mear linear time relative to the number of records in the file, and none use more than 300MB RAM. This is against Python 3.7.3. If your multithreaded Python app is using 2 GB of RAM, it's not because of the threads. Best look elsewhere. Maybe you're caching something large in thread local storage?
- mplanchard 7y ago
  GP was talking about processes explicitly in comparison to threads, so multiprocessing not multithreading. I believe this was related to their previous comment about the GIL making true multithreaded performance impossible: > - The Global Interpreter lock - you can't avoid forking processes in order to handle concurrent python code. > - Threads are cheaper than processes. A default java thread carries 2MB overhead, a python process for a typical app can easily be 2GB without very careful memory consideration. And it is indeed true that forking can be much more memory intensive than threading.
zbobet2012 7y ago
> Threads are cheaper than processes. A default java thread carries 2MB overhead, a python process for a typical app can easily be 2GB without very careful memory consideration. Threads are not cheaper than processes in Linux in any significant way. See the stack overflow question on that: https://stackoverflow.com/questions/807506/threads-vs-processes-in-linux https://stackoverflow.com/questions/807506/threads-vs-proces... A _langauges_ use of those may have poor performance.

by lumost 7y ago

_bxg1 7y ago

I don't think it's productive to argue that non-dynamic languages are superior across the board. Everybody knows they're faster. For many people, they're still the right decision. I think (or at least assumed) that the post's discussion is more interesting than that. A sibling comment seemed to be zeroing in on the crux of the issue. "Python is an order of magnitude slower but it's web server is two orders of magnitude slower" is a meaningful and fruitful thing to talk about.

lumost 7y ago
That's fair, however the python language is two orders of magnitude slower than it's static brethren for a variety of tasks. Pretty much any time you need to use the native language in the interpreter. https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/python3-java.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... It may be worth looking at how this performance gap has trended over time. Anecdotally I recall the performance gap being much narrower 10 years ago.

hermitdev 7y ago

> a python process for a typical app can easily be 2GB without very careful memory consideration. Sorry, this is not true. I have a Python app that uses 2 threads. It's memory doesnt even exceed 200 MB. Yes, Python threads generally suck because of the GIL, but they dont cause memory bloat like what you're describing. For context, I use Python extensively for extract/transform/load (ETL) work. I deal with quite large files. My loaders all run in mear linear time relative to the number of records in the file, and none use more than 300MB RAM. This is against Python 3.7.3. If your multithreaded Python app is using 2 GB of RAM, it's not because of the threads. Best look elsewhere. Maybe you're caching something large in thread local storage?

mplanchard 7y ago
GP was talking about processes explicitly in comparison to threads, so multiprocessing not multithreading. I believe this was related to their previous comment about the GIL making true multithreaded performance impossible: > - The Global Interpreter lock - you can't avoid forking processes in order to handle concurrent python code. > - Threads are cheaper than processes. A default java thread carries 2MB overhead, a python process for a typical app can easily be 2GB without very careful memory consideration. And it is indeed true that forking can be much more memory intensive than threading.

zbobet2012 7y ago

> Threads are cheaper than processes. A default java thread carries 2MB overhead, a python process for a typical app can easily be 2GB without very careful memory consideration. Threads are not cheaper than processes in Linux in any significant way. See the stack overflow question on that: https://stackoverflow.com/questions/807506/threads-vs-processes-in-linux https://stackoverflow.com/questions/807506/threads-vs-proces... A _langauges_ use of those may have poor performance.