5 ms·

My only gripe is: > Since a new instance of Python VM is running the code, there is no GIL and you get parallelism running on multiple cores. Has the potentia

My only gripe is: > Since a new instance of Python VM is running the code, there is no GIL and you get parallelism running on multiple cores. Has the potential to be misinterpreted by new Python devs. As I understand it, each process gets its own interpreter with its own GIL. So its not that there is no GIL, just that there are now 3 GILs each managing separate execution spaces. Also, at a higher level of discussion, this is just a rehash of multi-processing vs. multi-threading so perhaps it would be more illuminating to start from there and move down to the library examples. The casual reference to multi-threading in the quote from the POSIX fork definition also adds to potential reader confusion.

brianwawok 10y ago
The flip side is a lot of people think "oh the GIL, I can't even run Python code in a server with more than 1 CPU" No you can, just run lots of processes and make lots of GILS. Ends up still using less memory than Java in many cases. Gil will be the least of your worries.
- gshulegaard 10y ago
  That's a fair point: you can take advantage of multiple CPUs with Python, but you have to eat the overhead of multi-processing vs multi-threading. Multi-processing breaks down when you have to communicate with high frequency between various logical runners. I think there are vastly more problems that can be solved with multi-processing than those that require multi-threading but they do exist. There is also another layer of simulated parallelism via coroutines...but I was just trying to point out that there was potential for confusion in this piece.
  - dom0 10y ago
    You can of course use multithreading to get parallelism, eg. if the expensive calculations are not done in Python itself but rather some other library, be it cryptography, compression, numpy, serdes'ing stuff and so on. I/O works in parallel as well.
    - ddorian43 10y ago
      It's still 1 core for multithreading (on the python part).
      - gshulegaard 10y ago
        Just to add more context for others... C extensions called from Python are still subject to the GIL of the calling interpreter[1]. In fact, this guaranteed thread safety has led to the creation of many non-thread safe Python C extensions which is now a critical blocker to efforts to removing the GIL[2], although there are also a number of other issues as well. As noted in the StackOverflow, you can release the GIL but there are some tricks to doing so safely[3]. But threads of a C extensions library are not necessarily pinned to a single core by the GIL like regular Python byte code. Although many performance oriented libraries like numpy[4] forsake multi-threading by default in many cases and rely on parallelization by the user (programmer)[5]. [1] http://stackoverflow.com/questions/651048/concurrency-are-python-extensions-written-in-c-c-affected-by-the-global-inter http://stackoverflow.com/questions/651048/concurrency-are-py... [2] https://youtu.be/P3AyI_u66Bw https://youtu.be/P3AyI_u66Bw [3] https://docs.python.org/3/c-api/init.html#thread-state-and-the-global-interpreter-lock https://docs.python.org/3/c-api/init.html#thread-state-and-t... [4] http://www.numpy.org/ http://www.numpy.org/ [5] http://stackoverflow.com/questions/16617973/why-isnt-numpy-mean-multithreaded http://stackoverflow.com/questions/16617973/why-isnt-numpy-m...
    - jMyles 10y ago
      I wish I had a thousand upvotes to give this comment. This is the single most misunderstood concept in async python. I started and still contribute to hendrix (a "Twisted Django") and I can't believe how bright a lightbulb this is for people when they realize it.
- pjmlp 10y ago
  > Ends up still using less memory than Java in many cases. It will run slower in any case, and if I really care about startup speed, I will just use one of the third party JDKs and AOT compile to native code.
  - brianwawok 10y ago
    Maybe? Maybe not. I have coded services in Java that would never JIT before a reboot. Python can often beat un-JITed Java. For an IO bound tasks that is using less than 100% CPU.. again Python could be identical performance or at least very similar performance to Java.. Think of a simple rest service getting 10 hits per second. Maybe the Java service will be a few micros faster, but to a client across the internet you won't care. Now yes you are right if you are having 900 requests per second hitting your API, the Java API will crush the Python API. Not every app or service hits that though, and I would sure rather code in Python over Java.
- Symmetry 10y ago
  A memory consumption thing that you have to be careful of when doing that that we ran into recently. When you call fork Linux doesn't actually have to copy any of the existing memory until it's changed thanks to the magic of copy-on-write. But often Python will quickly increment or decrement the reference counters on all those bits of memory forcing copies; increasing memory usage and slowing things down. So either being careful with that or turning off garbage collection for the process (if it's short lived) are things to consider there.
  - jsmeaton 10y ago
    This was discussed recently in an instagram blog post. Did your team also independently reach these conclusions?
    - Symmetry 10y ago
      I'm not sure what the order of events was but I should certainly link that blog post. https://engineering.instagram.com/dismissing-python-garbage-collection-at-instagram-4dca40b29172#.xkfs7jfj6 https://engineering.instagram.com/dismissing-python-garbage-...
- whateveracct 10y ago
  "Less memory than Java" I can make a JVM use little memory at the cost of slowing it down. I can also give it all the memory on my server and it will translate that into performance. Java's memory usage is extremely within your control so this comparison doesn't make sense.
  - brianwawok 10y ago
    > "Less memory than Java" I can make a JVM use little memory at the cost of slowing it down. Maybe? You also need to assign about 2x live memory to the heap in order for GC to work properly. If you give it less, you will blow your heap and crash the JVM > I can also give it all the memory on my server and it will translate that into performance. No, it won't. CMS is realistically limited to about 16 GB of ram. Past that and you are going to have routine 2, 3, 4 second pauses for full GCs. G1GC is limited a bit higher, maybe 64 GB.. but again, beyond that and you are screwed. In a high performance app, routinely you limit heap usage to around 2 GB, which means you have about 1 GB of actual memory to use. > Java's memory usage is extremely within your control so this comparison doesn't make sense. Honestly, it sounds like you have never had to tune the JVM or run a Java app in production, so I disagree strongly with all you have said.

brianwawok 10y ago

The flip side is a lot of people think "oh the GIL, I can't even run Python code in a server with more than 1 CPU" No you can, just run lots of processes and make lots of GILS. Ends up still using less memory than Java in many cases. Gil will be the least of your worries.

gshulegaard 10y ago
That's a fair point: you can take advantage of multiple CPUs with Python, but you have to eat the overhead of multi-processing vs multi-threading. Multi-processing breaks down when you have to communicate with high frequency between various logical runners. I think there are vastly more problems that can be solved with multi-processing than those that require multi-threading but they do exist. There is also another layer of simulated parallelism via coroutines...but I was just trying to point out that there was potential for confusion in this piece.
- dom0 10y ago
  You can of course use multithreading to get parallelism, eg. if the expensive calculations are not done in Python itself but rather some other library, be it cryptography, compression, numpy, serdes'ing stuff and so on. I/O works in parallel as well.
  - ddorian43 10y ago
    It's still 1 core for multithreading (on the python part).
    - gshulegaard 10y ago
      Just to add more context for others... C extensions called from Python are still subject to the GIL of the calling interpreter[1]. In fact, this guaranteed thread safety has led to the creation of many non-thread safe Python C extensions which is now a critical blocker to efforts to removing the GIL[2], although there are also a number of other issues as well. As noted in the StackOverflow, you can release the GIL but there are some tricks to doing so safely[3]. But threads of a C extensions library are not necessarily pinned to a single core by the GIL like regular Python byte code. Although many performance oriented libraries like numpy[4] forsake multi-threading by default in many cases and rely on parallelization by the user (programmer)[5]. [1] http://stackoverflow.com/questions/651048/concurrency-are-python-extensions-written-in-c-c-affected-by-the-global-inter http://stackoverflow.com/questions/651048/concurrency-are-py... [2] https://youtu.be/P3AyI_u66Bw https://youtu.be/P3AyI_u66Bw [3] https://docs.python.org/3/c-api/init.html#thread-state-and-the-global-interpreter-lock https://docs.python.org/3/c-api/init.html#thread-state-and-t... [4] http://www.numpy.org/ http://www.numpy.org/ [5] http://stackoverflow.com/questions/16617973/why-isnt-numpy-mean-multithreaded http://stackoverflow.com/questions/16617973/why-isnt-numpy-m...
  - jMyles 10y ago
    I wish I had a thousand upvotes to give this comment. This is the single most misunderstood concept in async python. I started and still contribute to hendrix (a "Twisted Django") and I can't believe how bright a lightbulb this is for people when they realize it.
pjmlp 10y ago
> Ends up still using less memory than Java in many cases. It will run slower in any case, and if I really care about startup speed, I will just use one of the third party JDKs and AOT compile to native code.
- brianwawok 10y ago
  Maybe? Maybe not. I have coded services in Java that would never JIT before a reboot. Python can often beat un-JITed Java. For an IO bound tasks that is using less than 100% CPU.. again Python could be identical performance or at least very similar performance to Java.. Think of a simple rest service getting 10 hits per second. Maybe the Java service will be a few micros faster, but to a client across the internet you won't care. Now yes you are right if you are having 900 requests per second hitting your API, the Java API will crush the Python API. Not every app or service hits that though, and I would sure rather code in Python over Java.
Symmetry 10y ago
A memory consumption thing that you have to be careful of when doing that that we ran into recently. When you call fork Linux doesn't actually have to copy any of the existing memory until it's changed thanks to the magic of copy-on-write. But often Python will quickly increment or decrement the reference counters on all those bits of memory forcing copies; increasing memory usage and slowing things down. So either being careful with that or turning off garbage collection for the process (if it's short lived) are things to consider there.
- jsmeaton 10y ago
  This was discussed recently in an instagram blog post. Did your team also independently reach these conclusions?
  - Symmetry 10y ago
    I'm not sure what the order of events was but I should certainly link that blog post. https://engineering.instagram.com/dismissing-python-garbage-collection-at-instagram-4dca40b29172#.xkfs7jfj6 https://engineering.instagram.com/dismissing-python-garbage-...
whateveracct 10y ago
"Less memory than Java" I can make a JVM use little memory at the cost of slowing it down. I can also give it all the memory on my server and it will translate that into performance. Java's memory usage is extremely within your control so this comparison doesn't make sense.
- brianwawok 10y ago
  > "Less memory than Java" I can make a JVM use little memory at the cost of slowing it down. Maybe? You also need to assign about 2x live memory to the heap in order for GC to work properly. If you give it less, you will blow your heap and crash the JVM > I can also give it all the memory on my server and it will translate that into performance. No, it won't. CMS is realistically limited to about 16 GB of ram. Past that and you are going to have routine 2, 3, 4 second pauses for full GCs. G1GC is limited a bit higher, maybe 64 GB.. but again, beyond that and you are screwed. In a high performance app, routinely you limit heap usage to around 2 GB, which means you have about 1 GB of actual memory to use. > Java's memory usage is extremely within your control so this comparison doesn't make sense. Honestly, it sounds like you have never had to tune the JVM or run a Java app in production, so I disagree strongly with all you have said.