Ruby Conf 2008 Second Afternoon/Evening
What Every Rubyist Should Know About Threads by Jim Weirich
Concurrency is becoming bigger as computers get more cores. If you look at a graph of clock speed they flattened out in 2003.
Past performance gains:
So if clock speed is not going up at a rapid pace anymore, now what?:
Applications will need to be concurrent to exploit multicore machines. 100 CPU machines are on the horizon. Race conditions are trouble:
If thread one has this:
shared_variable += 1
And thread two wants to do the same thing:
shared_variable += 1
What if the first thread looks up the shared_variable and find that it's 25 but before it can change it the second thread reads the value (still 25 because it hasn't changed). Now the first thread will add one (shared_variable becomes 26) and write the result back to memory, then the second thread will add one to the stale number (25) and write 26 back to the shared memory. The output of those two threads running should have been 25 + 1 + 1 = 27 and yet the output was 26. Not good.
To fix this you need to disable context switching when touching a shared object and then re-enable it afterward:
m = Mutex.new
m.synchronize do
shared_variable += 1
end
Now all is well. However, this is trickier than it sounds -- if you have multiple objects interacting it's difficult to see where things must be synchronized. Also, you can get into situations where a circular relationship causes a deadlock:
1 waits on 2 waits on 3 waits on 1
Nothing can happen because threads are all waiting on each other.
To make your project thread-safe you must:
To sum up: Threading is hard.
Jim gently pointed out that if you really want to avoid race conditions you might want to use a language that was designed from the ground up to avoid these problems like Erlang, Clojure, or Haskell.
Using Metrics to Take a Hard Look at Your Code by Me
Good crowd. Everyone seemed pretty interested and there were a bunch of questions. I consider the talk a success. Except that I left my video adapter on the stage. And my laser pointer slide advancer thingy. What? I was nervous!
Ruby Kata and Sparring by Micah Martin
Micah used to be very serious bout martial arts and he thinks the becoming a good developer has some parallels with becoming a good martial arts practitioner. Micah's martial arts teacher didn't look very impressive, but he was a master. You'd be on the floor before you knew the fight had started. He got there through disciplined practice. To become a master coder you need to practice outside the office.
Kata - detailed choreographed patterns of movements. In matial arts you practice series of punches, kicks, blocks, etc.
Dave Thomas:
http://www.codekata.com
Uncle Bob:
http://butunclebob.com/ArticleS.UncleBob
What about performance? Every time you try for a belt you perform your Kata. This does three things:
The publicness of the performance motivates the student.
It's also a measurement of skill.
And it shows respect for your art.
Micah then performed a live coding kata for us. He has been practicing implementing Langston's Ant in Ruby. He bowed before starting and then cranked out some code TDD style.
Sparring is common in martial arts. In Ruby you have the Ruby quiz and the Rails Rumble. Micah announced another contest starting... Now!
The Battleship Tournament ends on Ends Nov 30, 2008. The challenge is to build a computer AI to play Battleship, but winning against other AI's is not everything. The winner will be determined by winning matches and the quality of the code as measure by various metrics. If you're interested check out these URL's:
http://sparring.rubyforge.org/battleship
http://github.com/slagyr/battleship
After having a number of drinks at the Pivotal Labs party I finally made to the hotel's lazy river (which is sort of a simulated river that goes in a big circle). Drunkenly doing laps around some palm trees while resting in an inner tube is a good time.
Concurrency is becoming bigger as computers get more cores. If you look at a graph of clock speed they flattened out in 2003.
Past performance gains:
- clock speed (not so much anymore)
- execution optimize
- cache results
So if clock speed is not going up at a rapid pace anymore, now what?:
- hyperthreading
- multicore (the new saviour)
- caching
Applications will need to be concurrent to exploit multicore machines. 100 CPU machines are on the horizon. Race conditions are trouble:
If thread one has this:
shared_variable += 1
And thread two wants to do the same thing:
shared_variable += 1
What if the first thread looks up the shared_variable and find that it's 25 but before it can change it the second thread reads the value (still 25 because it hasn't changed). Now the first thread will add one (shared_variable becomes 26) and write the result back to memory, then the second thread will add one to the stale number (25) and write 26 back to the shared memory. The output of those two threads running should have been 25 + 1 + 1 = 27 and yet the output was 26. Not good.
To fix this you need to disable context switching when touching a shared object and then re-enable it afterward:
m = Mutex.new
m.synchronize do
shared_variable += 1
end
Now all is well. However, this is trickier than it sounds -- if you have multiple objects interacting it's difficult to see where things must be synchronized. Also, you can get into situations where a circular relationship causes a deadlock:
1 waits on 2 waits on 3 waits on 1
Nothing can happen because threads are all waiting on each other.
To make your project thread-safe you must:
- Protect every shared memory access with a synchronize
- Be aware of extended situations
- Have a strategy in place for deadlock
- Evaluate every line in every library you use to make sure they follow the above steps
To sum up: Threading is hard.
Jim gently pointed out that if you really want to avoid race conditions you might want to use a language that was designed from the ground up to avoid these problems like Erlang, Clojure, or Haskell.
Using Metrics to Take a Hard Look at Your Code by Me
Good crowd. Everyone seemed pretty interested and there were a bunch of questions. I consider the talk a success. Except that I left my video adapter on the stage. And my laser pointer slide advancer thingy. What? I was nervous!
Ruby Kata and Sparring by Micah Martin
Micah used to be very serious bout martial arts and he thinks the becoming a good developer has some parallels with becoming a good martial arts practitioner. Micah's martial arts teacher didn't look very impressive, but he was a master. You'd be on the floor before you knew the fight had started. He got there through disciplined practice. To become a master coder you need to practice outside the office.
Kata - detailed choreographed patterns of movements. In matial arts you practice series of punches, kicks, blocks, etc.
Dave Thomas:
http://www.codekata.com
Uncle Bob:
http://butunclebob.com/ArticleS.UncleBob
What about performance? Every time you try for a belt you perform your Kata. This does three things:
The publicness of the performance motivates the student.
It's also a measurement of skill.
And it shows respect for your art.
Micah then performed a live coding kata for us. He has been practicing implementing Langston's Ant in Ruby. He bowed before starting and then cranked out some code TDD style.
Sparring is common in martial arts. In Ruby you have the Ruby quiz and the Rails Rumble. Micah announced another contest starting... Now!
The Battleship Tournament ends on Ends Nov 30, 2008. The challenge is to build a computer AI to play Battleship, but winning against other AI's is not everything. The winner will be determined by winning matches and the quality of the code as measure by various metrics. If you're interested check out these URL's:
http://sparring.rubyforge.org/battleship
http://github.com/slagyr/battleship
After having a number of drinks at the Pivotal Labs party I finally made to the hotel's lazy river (which is sort of a simulated river that goes in a big circle). Drunkenly doing laps around some palm trees while resting in an inner tube is a good time.
Comments
You didn't seem nervous at all.
Rest assure that your talk was a success. (I even blogged about it :)
I am definitely going to get involved in metric_fu. I see a lot of potential there.
Btw, I am the guy that brought up possible historical data and chart showing the code health over time.