Larry Hastings The Gilectomy How's It Going PyCon 2017

[@freddupont3597]

Maybe I understood 5% of it, this is a great talk! Loved it! :)

[@mmmhorsesteaks]

This is turning into a magnificent Rube Goldberg machine :D In a way, deciding dynamically wether an object should be lockable or not feels both very pythonic and quite insane. He'll be adding STM next (after all, it's easier to ask foregiveness then permission...) ;-)

[@OfferoC]

Thanks, Larry! Keep it up, we're rooting for you!

[@seanspicer516]

i love these videos. so patching together a few bits of info from random sources. i saw a survey on what people use python for. and (from what i recall, which is most likely exaggerated) game dev was dead last, i mean by a significant margin compared to all others. another just-off-the-top-of-my-head-prob-exagg-memory is the hett saying that 1) the hast likes gaming 2) gamers dont like python bc the gil 3) the gil is more python's ultra-elegant-solution than greatest-problem 4) if u wanna squeeze every last bit-twitch from a thread, well use a 'c'.upper() lang but for anything else, the gil is ur fren. im prolly wrong about most things, but this way of thinking is most entertaining to me.

[@lawrencedoliveiro9104]

32:27 But the trouble with garbage-collected languages is their incredible appetite for memory. This is why Java apps need to run in a fixed heap size, to ensure that the GC does kick in sometime. Otherwise, on a Linux system, for example, it keeps on gobbling more and more memory until you wake up the Dreaded OOM Killer, and then you die. CPython, on the other hand, can currently implement long-running tasks that keep their RAM usage within reasonable limits, without any special configuration of resource controls on your part. You would give that up by moving to a pure GC architecture.

[@gloweye]

The question isn't, how do we get rid of the GIL, but how do we get rid of the Java layer in between.

[@jon2kx]

I wish they would just hard segment python. So many of us just don't give a shit about maintaining backwards compatibility with 3.x. Just rip the damn band-aid off so we can scale on multi-core workloads without hacks or pools.

[@vasbetontalpfa]

Note, that all of your library developers should be on this point too...

[@lawrencedoliveiro9104]

43:13 that”s probably in sysfs, e.g. on my system /sys/devices/system/cpu/cpufreq/policy«n» where «n» is the CPU number. Within each such directory there is a readonly file “scaling_available_governors” which on my machine shows “performance powersave”, and the read/writable file “scaling_governor”, which seems to default to “powersave”. So try changing it to “performance”, and see what happens. Or you could try writing to the “scaling_min_freq” and “scaling_max_freq” files, and monitor the contents of “scaling_cur_freq”. Or maybe “cpuinfo_{min,max,cur}_freq” -- not sure what the difference is...

[@vasbetontalpfa]

Are these experiment implementations available/open?

[@konstantindimitrov2019]

6:40 Then.. why not benchmark on a raspberry pi or some low-end pc... :)