Numbers every Scala Programmer should kn...

Writing highly performant code has always been a challenge for programmers. The correct techniques to create the best performance change and evolve in response to changes in the underlying hardware. Before the late 90s, creating faster code was often about crafting more efficient CPU instructions. For instance, it was faster to XOR a register with itself than to set a register to 0. Now, this is no longer the case and instead creating fast code is mostly about improving L2 and L3 cache hit rates, aligning data in memory and allowing hardware attached to the I/O bus to move data to main memory concurrently with the CPU. With the advent of Scala, use of immutable data has been touted as the "best practice" for how to write concurrent code. However, to systems programmers, this guideline seems strange. This talk is about why using immutablity might be the right choice for some programming teams and the wrong choice for others. When you should to follow the easier models of systems that rely on immutability verses when you might need to brave the difficulities of using synchronization and locks. And finally, when *gasp* blocking is the right thing to do, even inside of an actor. Benchmarking code used to produce numbers referenced in this talk: https://github.com/creditkarma/scala-performance-benchmarks