Multithreading Code - Computerphile
ฝัง
- เผยแพร่เมื่อ 13 ธ.ค. 2018
- We take multithreaded code for granted, but what's needed to make it work properly? We need two Dr Steve Bagleys to illustrate this!
/ computerphile
/ computer_phile
This video was filmed and edited by Sean Riley.
Computer Science at the University of Nottingham: bit.ly/nottscomputer
Computerphile is a sister project to Brady Haran's Numberphile. More at www.bradyharan.com
![[Live สด] การออกรางวัลสลากกินแบ่งรัฐบาล งวดวันที่ 1 มิถุนายน 2567](http://i.ytimg.com/vi/3canzHC_d0k/mqdefault.jpg)
And the visual effects Oscar goes to...
You could even see the reflection of both of them in that monitor behind them!
@@TheRandomSpectator I mean that comes for free
@@TheRandomSpectator u noticed too
Best Computerphile video ever, I'd say. Congrats!
But was it also the most difficult Computerphile video to produce?
Who? You forgot to finish your sentence.
this is next level editing
What was the video about?
When he handed the token to the clone I was really impressed. This was great
The force is strong with this one.
Oh wow I didn't even notice that 🤣
It was so seamless, I forgot it was the same person
I get the impression the University of Nottingham once ordered 5000050000 boxes of that old style continuous feed printer paper back in the 80's and still don't know what to do with it all.
VredesbyrdNoir they feed it to the grad students
I wouldn't recommend using their washrooms.
@@pewp43 new channel: physicsphile - where physicists solve problems with single-ply toilet paper
you literally get it in giant crates for cheap.
Although they did get an Acorn A5000 out of the deal (lowest machine in the stack on the desk behind). I had (have in store still) one - great ARM machine but a bit light on RAM.
My husband works from home. He is a very intelligent programmer, he talks to me everyday. This stuff is one of them. I am just drinking coffee while listening to him. I had no idea what he is talking about every single day. Thanks for helpful video. I will watch this everyday.
Just a reminder that the point of the video wasn’t to optimize the code for finding the sum of all the numbers that add up to 1,000,000, but to break down how multi-threading works and some solutions you would use for more common scenarios. Great video!
thanks for this.
My first thought was making "a" into 2 variables and then adding the results would be faster at the expense of some memory.
Am i right is assuming this?
There is a close formula for adding numbers in order so this is really just for demonstration purposes. Sum(1 to N) = N*(N+1)/2
Wouldn't that be optimized away by the compiler with optimization flags on anyways?
You should just write your code to be readable, then only optimize if you're sure there's a bottleneck(by profiling)
@@Lightbringer7734 no one cares. This isn't a video about compilers. Sounds like you're scared of having to think for yourself
@@nickwilson3499 wut?
What still amazes me. This is "just" an educational tech related channel, were a professor/teacher is explaining stuff about computers and IT stuff.
Yet, it has 1.2 MILLION subscribes and around 20k views in a few hours.
Great job guys, you show that learning (tech) stuff is just really enjoyable!
On a way that apparently a lot of people can understand! thumbs up!
The first time I felt smart watching a Computerphile video. I saw the code and the fact that both threads use the same variable and thought "That's not gonna work as intended.".
A good Part 2 would be explaining how the mutex works, because implementing the mutex also runs into the read-modify-write problem.
Kudos for the visual effect of two Steves, especially handing the disk back and forth. Steve gets credit for his acting skills, and bonus points for having a 3 1/2" floppy disk just lying around on the desk.
That was some great editing! Good job and great video!
Not just editing, but also choreography of Steve’s movements.
The floppy disk transition was pretty clever
Yes, i want to know how that was done. Steve 1 seamlessly passed it to steve 2 as if he was real.
@@simontay4851 Are you trying to say he isn't real?
never done any video CGI but if I'd have to guess someone was sitting there accepting the disk initially, then they switched places and had real time split-screen of the previous footage running on a screen so they can verify the disk aligns on the second pass.
@@snooks5607 Still how did he deliver the disk at the precise level each time. You'd expect some altitude difference that would make the floppy disk "snap" from one altitude to another (and there is, but very, very little, which is impressive).
@@carlosmspk Any imperfections in position are masked by the outline
Insta-liked for multiple Steves :-)
Steve literally divided himself like a cell just for this example
thats some true dedication
steve just forked himself
Wow, finally after a while I understood how threads and mutexes work. The visuals are great
I want 8x Steve solving all my tech problems and projects.
Bagley is exactly like this in lectures. The only difference is he has awesome, black, heavily animated keynotes.
Max Taylor I woulda stayed in college if these guys were my professors.
That sounds amazing
He’s honestly a legend. Gutted I haven’t got any modules with him next semester.
The numberphile and computerphile people have seemingly endless amounts of feed printer paper and butcher paper for some reason
Maybe back in the 1980's, some company offered the university a great deal for a huge number of boxes of green bar paper.
The `time` process is not well equipped at all for measuring performance at the microsecond level, as you found. Many things skew the results, as a whole process needs to be spawned and torn down, and this stuff is included in the total; context switching also will bite you. I only use `time` for benchmarking when the benchmarked process is expected to run for longer than one half second.
Also, remember that there's a Bash built-in also named `time`, which is even worse than /usr/bin/time.
`gprof` or `prof stat` would have been a much better choice.
Would making the set of numbers being added together larger to make it last longer increase the accuracy of the time process?
@@sugarbooty sure, you could also measure the difference with a physical stopwatch but why make things hard for yourself. right tool for the right job.
Do we not have access to a low level high res timer?
3:00 for completeness, there's also a thing called "green threads" where OS is cut out of the resource management and it's all done by the user-space application. reasons for this vary but for one it might avoid context switching in compute intensive cases.
Having the multiple Steves talking over each other and interfering with each others task to explain what happens in multithreaded tasks was quite brilliant!
Not sure if this is an actual educational video or just the editor and Steve flexing on their editing and acting skills respectively.
i found the content clear. but I already have been dealing with locks, and programs not always giving the same result. And of course the video production itself can be educational at the same time. Win win situation.
Learned more in 15 minutes than I did in my entire university Concurrency module.
Awesome stuff as always :)
nice profile pic ^^
You went to Patriot University?
@Zero Cool Of course I was exaggerating, the course was bad and the lecturer didn't care, so I had to take things into my own hands but yes they did somewhat go over this stuff in that course just extremely poorly
@Zero Cool my professor in databases was from Russia and couldn't speak English neither the language that's spoken in my country. I don't know how he hasn't been fired yet but I assure you that you learned more in 1 hour research than the entire course.
This is your problem. You're in a university. You're not supposed to be spoonfed by the professor. You're supposed to learn to study on your own. If you expect everything to be spoonfed to you, you'll have a hard time finishing your education.
10:57 I need a 10 hour version of this.
I've always had love for parallelism and multi threading. This video explained it even more. Thank you!
Merry Christmas Computerphile!!!!
My vision for education in programming is that the students should learn multithreading right from the start - in the introduction course. That way we can form a "divide and conquer" approach to solving problems from the beginning and not struggle to fight their "linearity" in thinking afterwards.
The problem is that most of the people tend to use the methods of programming they know best, they know best whatever they used most and they used most whatever they learned first. So when we introduce parallel programming say in third or fourth course in the Bachelors degree it's already too late.
Nowadays the mainstream programming is over multicore computers and parallel thinking in problem solving is a must.
scratch has multi-threading (it is taught at primary schools).
I spent three years studying programming in college, we never once covered multi-threading. Really annoying.
T Duke Perry I stumbled upon multithreading myself during my final college assignment (not university), It was a cloud storage app programmed in windows forms(C#) I had to use multithreading for the networking aspect, ie keeping the user interface responsive while downloading/uploading files and on the server allowing multiple clients to access data simultaneously. It was never formally taught however
@@theblackwidower that's very sad to hear...
@@justgame5508 what I do in my courses is that we start directly from GUI programming (Java Swing in NetBeans). That way we directly hit the responsive interface issue in the second lecture. We usually make some simple game - like a bad guy chasing a hero around the board so the hero must be in one thread controlled by the human and the bad guy in another. We then follow the path down towards low level programming.
This is one of the best videos posted to this channel in a while. Really really great upload! I like that we actually got to see some code. I'm finishing my second year toward my degree in computer science and this is right at the level that's great for me. Cheers!
Needed this month's ago for my exams but was a great reminder! Your videos always help me and other programmers understand the concepts visually and practically!
One of the highest value channels on the platform, thanks so much for the fantastic content!!
Great to see Steve programming ! Very educational how he organizes the code and writer it!
The method of explaining how a thread works and how we can use mutex for the solution was exemplary. Great editing.
One of the best multithread examples ever!
Well done!!
explanation and visual presentation are just outta the world.
teaching every CS student wishes for
The best explanation of threads that I've even seen -- great job! Oh, and of course brilliant video production.
This video was just brilliant. Great production
This was a great video. The visualizations were awesome and I love seeing actual code.
Oh, what a great video. I wish I was introduced to it when I was learning about multithreading because it makes it look so easy despite the fact that all the things in this video I learned in a very hard way.
This is so educational, please do more videos with multithreading subject! ❤️❤️❤️
One of my favorite vids by yall guys. Thank you !
Everyone learning programming should look at your video. Great explanations as usual.
Awesome special effects, and really good topic!
i really enjoy dr. bagleys explanations. keep up the good work
Getting more in-depth knowledge on parallelism and multi threading. Thanks!
Hats off to the editor and the presenter, and one more time to the editor.
Very nicely done! We can never have enough Dr Steve Bagleys. ;)
love the two Steves!
Great job! I can see somebody had a bit of fun with this one
Even though C++ (since C++11) has added threading to its standard library, in a lot of situations am still preferring to design around forking where a parent process supervises child processes to do the real work. With copy-on-write optimization of forking, the cost is the page mapping of the process address space having to change upon context switching per kernel scheduling. But the forked child process has a private heap that doesn't have contention with other threads for access. In the age of big data processing, this tends to be more crucial - plus it's a more fault tolerant design approach for implementing self-healing software services that need to run robustly 24/7 (child processes are vastly easier to scavenge successfully than a failing thread of execution which can tend to destabilize the entire program). I prefer this so much to multi-threading that I wrote a custom Java launcher called Spartan that enables (easily) breaking my Java programs into child processes - just as with C and C++, I can write a single Java program that splits itself into a parent and (one or more) child processes for logic execution. And the Java heap gets problematic (perf-wise) when dealing with more than 4 to 6 GB of memory objects - is really better to run concurrent, heavy data-centric processing in multiple child processes instead of one Java process using threading in a single heap that starts going well beyond 6 GB of memory utilization. Oh, and here's another optimization of this approach - the Java child process just does a System.exit() when its done so that there's no attempt to garbage collect multi GB of objects - in fact with Spartan, its feasible to launch the Java child process such that garbage collection is turned off - just allocate memory until done but never bother to reclaim it - the OS does that when the process exits. In Golang, it's a different story - pretty much have to go with model that's baked into the language. It's light weight compared to other language threading models, and garbage collection these days now works much, much better.
When I was first at work 40 years ago, we used to call operations that interrupts or the threads can't interfer with Atomic operations. These days nobody has a clue what I'm talking about.
Atomic operations are used in real-time computation, when you can't afford mutexes slowing things down or making response times unpredictable, and to prevent priority inversions. There is std::atomic now, and std::memory_order. Of the PC applications that people use daily, games are the most performance-critical and hence require these kind of features.
Very helpful. I'm proficient in shell scripting and powershell overall for my work life, and recently started learning C. This helped me sort out a problem with one of my projects, so thank you for that. =)
Best 15 minutes I've ever spent today
The presentation and editing in this video is the best I've found on TH-cam when it comes to explaining and demonstrating multithreaded execution. Amazing job Dr. Bagleys and Computerphile.
I'm a computer engineering student and one of the concerns I had when learning about and experimenting with multithreaded programming was the _real_ performance gain. As was shown in the video, the summation example didn't benefit a ton from being multithreaded. I assumed that a lock like a mutex creates a major bottleneck in your code that really makes it no faster than the single-threaded, sequential case. Moving the lock to the end of the function to minimize its usage made a lot of sense and, at scale, I could definitely see how multithreading would be the way to go!
Interesting topic, well explained, nice editing. Thumbs up!
wowww the editing was superb! nice job computerphile nice job
The production quality is Insaneeeeee
Loved the video! Absolutely great!
Superbs explanation. Well done! Great editing too!
Please do a video on how you had two Steves, apparently motionless wrt each other, while using a hand held camera, and interacting with each other. That was too cool for School.
How the hell was there a second identical steve in the video at the same time and how did steve 1 on the right seamlessly pass a real floppy disk to steve 2 on the left as if he was there. That is some very clever filming and editing by Sean Riley.
Sean, if you read this, please reply.
Hah, it took five times longer to edit than any other, may have to do a behind the scenes on how.... Sean
It must be the work of an enemy stand
Gauss' shortcut:
The sum of positive integers from 1 to x, where x is even is equal to: (1+x) + (2+[x-1]) + (3+[x-2]) + ... (x/2+[x/2+1]) = (1+x) + (1+x) + (1+x)..., where there are x/2 terms, or (1+x)*(x/2). The example in the famous story about Gauss was finding the sum from 1 to 100 which is equal to (101)*50 = 5050.
In this case, x=1,000,000, x/2 = 500,000 => The sum is (1+1,000,000)*(500,000) = 500,000,500,000.
Steve-P-U Huh? Sounds like a RISC-y piece of hardware ;)
Thank you so much, this is channel is helping me tremendously.
Really interesting video; explained concept of multi threading well and liked the example in code - thanks very much
Visual effects were superb
Great Video!! he explained following things
- Race Condition Problem
- solved race condtion problem using mutex.
- code inside lock and unlock is called critical section.
i have read so much about this but never seen program which explain all these concepts!!
AMAZING VIDEO!!!!!
I understand so much now 😌 Those visual effects helped a lot 🙌🏾
Visuals were sick!
This was really well made. Thanks!
Very impressive! Merry Christmas.
Find me a better channel on TH-cam, I'll wait .
Every time I come to computerphile, it blows my mind open.
Great video as usual, though this one gets a prize for cool editing effects. I was wondering; how about using two separate accumulators, one for each thread, and adding them together after the join?
You can build university with this content quality
really awesome explanation !!
can someone please explain the origin of &aLock as an argument passed in the mutex lock function?
Love the explanation, thanks other Steve!
What a great explanation!
5:07 - Basically the "Hello, World!" of multithreading in C lol. Very well explained, though! A++
Steve and other Steve complement each other very well.
Amazingly explained !
1:46 (about processes) "If you changed one memory location, it updated in the other side […]" - *NO! THAT IS WRONG!!!* The defining feature of processes was memory isolation. No changing memory in other processes unless both processes asked for it (look up shared memory). It is true that the process' memory is not necessarily copied during the fork(). The CPU's support for virtual memory allows using page faults and what is known as copy-on-write, or COW, for short. This means both processes continue to use the same memory, but set as read-only in the page tables managed by the OS, until one of them tries to write to that memory. This causes a page fault by the CPU (writing into a read-only page), but this is transparently handled by the OS which allocates a new (physical) page, copies the data and attaches it to the writing process as read/write, then the "offending" process is resumed. But this is an optimization by the OS and does not change the concept of memory isolation. I got worked up over this, sure, people make mistakes, but memory isolation versus common address space… that is basically the *defining* difference between processes and threads. E.g. here is an excerpt from the documentation of the GNU/Linux function clone():
Unlike fork(2), clone() allows the child process to share parts of
its execution context with the calling process, such as the virtual
address space, the table of file descriptors, and the table of signal
handlers. (Note that on this manual page, "calling process" normally
corresponds to "parent process". But see the description of
CLONE_PARENT below.)
One use of clone() is to implement threads: multiple flows of control
in a program that run concurrently in a shared address space.
Note how they *define* threads as "multiple flows of control … *in a shared address space* ."? I'll admit that this is tricky stuff, e.g. the distinction between threads sharing the table of file descriptors whereas fork() effectively copies this table. This means that, while after both a fork() or a clone(), both processes will have the same files opened with the same file descriptors (these are integer IDs usually), *changes* to the FDT will only be seen by a clone, not by a forked process - e.g. if one forked process closes a file descriptor, it will yet remain open in the other.
TL;DR: Your explanation of the difference was like saying "a bike is different from a trike in that it has three wheels", which is horrible, which in turn should explain my reaction.
Incredible video!
Nice explanation. We master the sequential process a long time ago. We have very good mathematical models on sequential processing but even now in 2019 we lack a good mathematical model on concurrency processing. Having a huge complex program and trying to split it in multiple threads is a nightmare. I think because we have only two hands our minds are not good at concurrency thinking. I would really like to see a programming language where the source code file has "normal code - handled by programmers" and on top of it there is a "synthetic code - handled by AI", the "synthetic code" is invisible to the programmer and it is in the same source code file. So the human job is to write the code and the AI job is to split the same code automatically. So as a human we don't need to know that the code was run in a complex concurrent fashion. This programming language can have multiple layers (Human layer + many AI layers). It is quite difficult to make a sequential looking code (TEXT) act concurrently (This just makes the code look quite complicated) .
the two hands thing doesn't even hold up. We actually can't do more than a single thing consciously. Everything else consists of routines we learned and that only need our attention when they're being stopped, started, modified etc. Take walking down the street while talking on a phone. We can walk without consciously thinking about it, we are decent at observing our surroundings without it and we can produce speech without it. We only need to think about where we want to go and the content of our speech, all the muscular functions are completely automatic. Once you think "a quick brown fox" you don't need to actively think about how to produce that sound.
And when learning to play an instrument, for example, you can quickly see how we are completely unable to coordinate both hands as long as we have to actively think about their movement.
Learned a lot for this! Thanks!
Thanks, I learnt something today. Brilliant.
very informative thank you for your brilliant work
This is really helpful thank you Hussein.
Fan from egypt😊
Some damn fine editing here :)
Love Steve's teaching
Steve Ception!! I like it, that was awesome! :)
What magic is this with the floppy disc :D:D Amazing!
Not much faster? .06 / .07 = .8, that's like 20% improvement... Anyway, as a rule of thumb; Turn off optimizations when benchmarking intentionally bad code... Also;
A much more trivial solution (sum first half into A, second half into *new variable* B and add them together in the end) distracted me from te actual point of threading, mutex, etc.
20% improvement sure, but he only ran the program a handful of times. we don't know if that result is statistically significant. i think he was looking for a more dramatic improvement right off the bat.
Some compilers might optimize the sum with the Gauss formula for sums S= n/2(a1+an) so there would be no difference in speed, or precompute the result at compile time ! One has to be aware of these optimizations before drawing results about speed etc
I was thinking the same idea about having 2 separate variables and then adding them together but you can only do that if you are running some sort of sum calculation, you can't apply that same method for more complicated code that isn't just a calculation of a sum
Please make more videos on threads 🙏 this was great ✨✨
I just had thought god uses multi threads for generation learning which we call alternate universe and this video pops up.Nice one youtube,nice one,and this multi Steve nailed it
holy moly that editing
I like this guys videos because they're a little more advanced.
Thanks for the great content. But how is locking a token to proceed with multithreading faster than just running the code on a single core? The other thread seems to have to wait, so it shouldn't be a performance boost at all to use multi threading this way. And you are adding more complexity. Are there benefits to this, that I'm missing here?
Two Steves is always better than one.
I loved second Steve!
Really interesting stuff! Thanks a lot!
This summarizes the difficulties in group work. All parties are working on the same thing, slowing down efficiency due to mutex locking.
Of course, that assumes that there is even a mutex, because most of the time it's just a single guy doing all the work, with the other parties blackmailing that thread to credit them equally.