One of the things I liked from "The Pragmatic Programmer" about concurrency was that he also says that it can make it easier to reason about your problem when you free yourself from certain ordering problems.
40k views, 1k likes and only 29 comments, most of which are boring. This is probably one of the most important, relevant, compelling, authentic videos on the subject of "How to program intelligently" After 30 years of coding experience I am prepared to go back to square one because I know it makes sense. The stuff at 33.30 "ASYNC is the future...ASYN maxes CPU, Existing code and libraries, ASYNC means you will have to re-tool..." is pure gold.
I looked at this a few months ago as a python newbie...few months later this all makes sense and am excited to make the complete transfer to async with my future projects. lots of web app / automation ideas
I still find it supersad that gevent does not get the awareness it deserves, imho. No other language offers the convenience of converting a syncronously written program, threaded or not, cooperatively async - with a single line of code, which patches *all* blocking ops into non blocking, taking care of all the callback handling behind the scenes. This is beautiful. Example: His test question at 34:45 - we had that, had to stop blocking on a telnet/ssh using threaded framework, partially 3rd party, partially from us, since number of comm. sockets increased into the 100ks - one import gevent + patch and that was it. No other change. Paradise, imho.
From what I got out of the talk, the difference between threads and async/await for existing codebases comes down to these two alternatives: - changing all the bits of code that could leave shared scopes or output in an inconsistent state if other tasks interrupt them, or - changing the bits that would ‘block’ other tasks by doing I/O or holding the CPU for so long that it feels like ‘it hangs’. The message repeated in the talk, then, is that the former is easier, since the changes just involve wrapping the access to shared state/effects with locks on some convenient level. In the async/await version, they would usually require diving all the way down the call graph and replacing the I/O call, or the entire library call it's hard-coded in. But isn't it much easier to iteratively _find_ idly waiting I/O calls and other things that cause noticeable slowdowns, than it is to find all places that touch references to the same sets of mutable object attributes until you feel safe that it's correct?
46:30 ...and it happend : airplane, automatic control of flight (plus non-disciplined / non-experienced devs (=cheap), conflict of interest in auditing and authorizing the new feature, etc.)
I find *multiprocessing.Barrier* and *threading.Barrier* useful because unlike .join(), these don't expect the process or thread to be terminated. Also, of course use a Queue instead if that'll conveniently do the job.
Haha async / co-routines were used lots in the 1970s and 1980s. Its just that people forgot about them because the goto was removed from Python and Java, and C's longjmp was weird...
You don't need goto to do async/coroutines; and in fact, it wouldn't really help in implementing async/coroutines anyway. And goto wasn't "removed from Python", it never has goto.
I don't think it was lightly covered, 30% of a 1.25 hour video is still a lot more coverage than a 15 minute video talking exclusively about it. Obviously there's still more to explore
The code part with fuzz all over doesn't have a race condition, due to GIL there will be the lock on the counter whenever any thread is trying to upgrade. The final value of the counter would always be the same. Race condition means final value changes may be because two threads read the same value while incrementing. If one wants to print Counter value sequentially as Raymond is trying to do, they can simply synchronize the function.
I alwasy listen that fallacy that locks are expensive to acquire. A lock is effectively 1 single assembly instruction, test and set, on a modern CPU. There are other issues that are serious, but to say locks are expensive to acquire is simply wrong.
Test set and a loop when the test fails. Also, that test and set instruction is one of the most expensive assembly instruction, because it causes the CPU core to need to interrupt all the other CPU cores and synchronize to make sure that the none of the other cores are doing anything to the value and the test and set completes atomically. Which means that every time you do this, it slows down all the other cores, and it causes all sorts of effects to the CPU caches. Not a big issue when you have just 1 lock and acquire only occasionally, but if you start having fine grained locks everywhere, test-and-set are no longer cheap.
I don't know if I'm just not getting something or the video just didn't age well... but his arguments against threading don't seem correct. Threading has been done for a looooong time. It may causes bugs? Yes, but normal code may too. Testing will never cover all bugs indeed (as he says about the race conditions) but this is true to normal non-threading code too! So should we abandon code at all because of the possibility of messing up???? One of his points in 16:00 is that if threading doesn't have a race condition then you probably wouldn't need threads at all... This is so wrong! Any experienced back-end developer already came up with situations were he needed to implement a lock to avoid a race condition and situations were this simply isn't needed (eg, if I need to populate an object were each part of the object doesn't depend on the others and the order of insertion doesn't matter then multi-threading is absolutely safe! In a game, for example, the rendering of trees is independent of the rendering of animals or other characters, if you used to play MMOs more than 15 years ago with slow PC's and internet connection you know what i'm talking about). Furthermore many new languages have found ways to share state (with the programmer being in charge of the security of memory and data) between "threads". Golang has goroutines, Rust has its thread and scope system, Erlang has its processes inside the JVM, even modern C++ had found a way to make the code easier to detect race conditions although about this one I've only heard of. For what I know many languages have found ways to deal with the threads problem in safer and lighter ways, this panic is unnecessary.
Good talk as always but think about it: All that doubling of python internals and skills requirements to learn async for reducing 20% CPU compared to Threads - and around 0% compared to gevent? In the beginning he said correctly that loading all local cores is anyway just a niche use case, a step before real distributed computing. So think about it: You really want to do all that to you, for 20% gain instead of rather architecting in distributed computing, when threads don't cut it? Or stick with greenlets and keep simple beautiful python code, which does distribution already, w/o you even care when handling sockets or IPCs? I rather stick with the latter.
To be somewhat pedantic: Failing to acquire the lock is only the symptom (called deadlock), it is the failure to *release* a lock that is the root cause that will screw everything up.
Oh, i see Raymond Hettinger - i press "Like" :-) Thanks for upload!
Raymond is a pleasure to watch and listen to, and makes Python awesome.
I'm a simple man.. I see Raymond Hettinger, I click the video
One of the things I liked from "The Pragmatic Programmer" about concurrency was that he also says that it can make it easier to reason about your problem when you free yourself from certain ordering problems.
when he said an easy problem even for high school students. I learnt my first for loop when I was 25 and fell in love with programming.
40k views, 1k likes and only 29 comments, most of which are boring.
This is probably one of the most important, relevant, compelling, authentic videos on the subject of
"How to program intelligently"
After 30 years of coding experience I am prepared to go back to square one because I know it makes sense. The stuff at 33.30 "ASYNC is the future...ASYN maxes CPU, Existing code and libraries, ASYNC means you will have to re-tool..." is pure gold.
30 yrs of coding! your view of the world must be wonderful!
I looked at this a few months ago as a python newbie...few months later this all makes sense and am excited to make the complete transfer to async with my future projects. lots of web app / automation ideas
What an excellent talk. I wish they had let him delve into the detail of that last piece of code.
What a wonderful and insightful orator and educator.
I still find it supersad that gevent does not get the awareness it deserves, imho. No other language offers the convenience of converting a syncronously written program, threaded or not, cooperatively async - with a single line of code, which patches *all* blocking ops into non blocking, taking care of all the callback handling behind the scenes. This is beautiful.
Example: His test question at 34:45 - we had that, had to stop blocking on a telnet/ssh using threaded framework, partially 3rd party, partially from us, since number of comm. sockets increased into the 100ks - one import gevent + patch and that was it. No other change. Paradise, imho.
This craziness is how I came to understand why functional programming has value.
From what I got out of the talk, the difference between threads and async/await for existing codebases comes down to these two alternatives:
- changing all the bits of code that could leave shared scopes or output in an inconsistent state if other tasks interrupt them, or
- changing the bits that would ‘block’ other tasks by doing I/O or holding the CPU for so long that it feels like ‘it hangs’.
The message repeated in the talk, then, is that the former is easier, since the changes just involve wrapping the access to shared state/effects with locks on some convenient level. In the async/await version, they would usually require diving all the way down the call graph and replacing the I/O call, or the entire library call it's hard-coded in.
But isn't it much easier to iteratively _find_ idly waiting I/O calls and other things that cause noticeable slowdowns, than it is to find all places that touch references to the same sets of mutable object attributes until you feel safe that it's correct?
Just brilliant!!! He just captured my attention the whole time.
Great talk. Great teacher. Distills the lesson for good summary.
46:30
...and it happend : airplane, automatic control of flight
(plus non-disciplined / non-experienced devs (=cheap), conflict of interest in auditing and authorizing the new feature, etc.)
Hope to see you in Montreal again!
there must be a harder way!
"so we can get paid for it" that made me laugh. :)
What other convention speaker do you know who has their own catch phrase?
Best explanation about differences and use cases!
Python is extremely popular in the gaming community . . just not for run time code :D It's used a TON for production pipelines and tool writing
Nice talk. Only at 57:40 it was a bit confusing when you scrolled to the code using locks while still talking about queues.
I find *multiprocessing.Barrier* and *threading.Barrier* useful because unlike .join(), these don't expect the process or thread to be terminated. Also, of course use a Queue instead if that'll conveniently do the job.
Haha async / co-routines were used lots in the 1970s and 1980s. Its just that people forgot about them because the goto was removed from Python and Java, and C's longjmp was weird...
You don't need goto to do async/coroutines; and in fact, it wouldn't really help in implementing async/coroutines anyway.
And goto wasn't "removed from Python", it never has goto.
This blew away my mind!
Happened to see this. I learned so much out of it.😮
"How can we make this hard, co we can be paid for it?" quote worth remembering
"an electonical computer" woah mr fancy pants with his electricity.
Are slices available somewhere? Great talk!
What happens when I pull the plug on the printer? Does it stop then?
Very interesting talk, too bad asyncio was so lightly covered, very good nonetheless.
I don't think it was lightly covered, 30% of a 1.25 hour video is still a lot more coverage than a 15 minute video talking exclusively about it. Obviously there's still more to explore
The code part with fuzz all over doesn't have a race condition, due to GIL there will be the lock on the counter whenever any thread is trying to upgrade. The final value of the counter would always be the same. Race condition means final value changes may be because two threads read the same value while incrementing. If one wants to print Counter value sequentially as Raymond is trying to do, they can simply synchronize the function.
Very interesting and instructive! Now it would be really great if we could actually get the code examples. The Dropbox link doesn't work.
Dropbox changed public links. Moved to pybay.com/site_media/slides/raymond2017-keynote/index.html
thanks , is this editor vim or emacs
where is the guy that share the timestamps?
Is there a worse way though?
I learned something new!
I alwasy listen that fallacy that locks are expensive to acquire. A lock is effectively 1 single assembly instruction, test and set, on a modern CPU. There are other issues that are serious, but to say locks are expensive to acquire is simply wrong.
Test set and a loop when the test fails. Also, that test and set instruction is one of the most expensive assembly instruction, because it causes the CPU core to need to interrupt all the other CPU cores and synchronize to make sure that the none of the other cores are doing anything to the value and the test and set completes atomically. Which means that every time you do this, it slows down all the other cores, and it causes all sorts of effects to the CPU caches.
Not a big issue when you have just 1 lock and acquire only occasionally, but if you start having fine grained locks everywhere, test-and-set are no longer cheap.
Seem the slides was removed in dropbox , If any guy have links to download it ??
Link works now.
44:35
CAHACAHACAA
that reminded me of my faulty multithreaded code
Slides link returns "File not found". Help !!!
someone killed the thread right as it was uploading :(
hahaha they must have encapsulated that thread in a daemon threadkiller because every time I try i it fails
Dropbox public links died. Moved to pybay.com/site_media/slides/raymond2017-keynote/index.html
Thanks the link works fine now
The interesting part starts somewhere around 45:00.
it hangs.. means 卡了？
Does anyone know how to create html files with keynotes just like the ones used by Raymond?
I think it's generated using Sphinx Read The Docs Theme
@@amhokies thanks! :)
Seeing him cough now in corona times was surprisingly painful..
I don't know if I'm just not getting something or the video just didn't age well... but his arguments against threading don't seem correct. Threading has been done for a looooong time. It may causes bugs? Yes, but normal code may too. Testing will never cover all bugs indeed (as he says about the race conditions) but this is true to normal non-threading code too! So should we abandon code at all because of the possibility of messing up????
One of his points in 16:00 is that if threading doesn't have a race condition then you probably wouldn't need threads at all... This is so wrong! Any experienced back-end developer already came up with situations were he needed to implement a lock to avoid a race condition and situations were this simply isn't needed (eg, if I need to populate an object were each part of the object doesn't depend on the others and the order of insertion doesn't matter then multi-threading is absolutely safe! In a game, for example, the rendering of trees is independent of the rendering of animals or other characters, if you used to play MMOs more than 15 years ago with slow PC's and internet connection you know what i'm talking about).
Furthermore many new languages have found ways to share state (with the programmer being in charge of the security of memory and data) between "threads". Golang has goroutines, Rust has its thread and scope system, Erlang has its processes inside the JVM, even modern C++ had found a way to make the code easier to detect race conditions although about this one I've only heard of. For what I know many languages have found ways to deal with the threads problem in safer and lighter ways, this panic is unnecessary.
He looks rather like a protoype Siemens CEO than like a nerd :D
Aber sein amerikanischer Akzent verrät ihn.
(But his American accent gives him away.)
Slides url isn't working any longer, fyi
Fixed.
Oh god the joke at 46:38 did not age well
could have been something he heard on the grapevine honestly
There are those who believe that if you mix threading and forking that you are living in a state of sin and deserve whatever happens to you.
slides are a dead link
It's working now.
pybay.com/site_media/slides/raymond2017-keynote/index.html
Good talk as always but think about it: All that doubling of python internals and skills requirements to learn async for reducing 20% CPU compared to Threads - and around 0% compared to gevent?
In the beginning he said correctly that loading all local cores is anyway just a niche use case, a step before real distributed computing.
So think about it: You really want to do all that to you, for 20% gain instead of rather architecting in distributed computing, when threads don't cut it? Or stick with greenlets and keep simple beautiful python code, which does distribution already, w/o you even care when handling sockets or IPCs?
I rather stick with the latter.
01:11:17 Ahh my eyes.
OH WOW! I did not know that if you fail to acquire a lock then you can screw the program! scary!
To be somewhat pedantic:
Failing to acquire the lock is only the symptom (called deadlock), it is the failure to *release* a lock that is the root cause that will screw everything up.
hahahha im an unreasonable person
this guy is hilarious
Totally misleading in the way he puts things in perspective. Not a single word on I/O. Confuse Threading and being Statefull. I am outraged.
Excellent talk but there was a lot of time spent on fucking and unfucking up threading and a not a whole lot of asyncio.
Unreasonable people invent their own programming languages. And all programmers depend on the unreasonable people.
If you marry nine wifes, you can have a baby every month.
or have all babies at the same month asynchronously.
Username checks out.
python == noob;
So boring
He looks rather like a protoype Siemens CEO than like a nerd :D