Utah C++ Programmers

When the C language was created for PDP-11 minicomputers, performance profiling was easy. Typically there was no memory hierarchy, so accessing memory was a uniform cost regardless of the access pattern. Registers were faster than memory, hence the (now deprecated) register modifier keyword for variables to hint to the compiler that a variable should be kept in a register. The C language mapped itself quite readily to the PDP-11 instruction set, so there weren't often times when you needed to coax the compiler into using a more efficient sequence of assembly instructions and rarely did you need to write assembly language for performance reasons.

Those days are long gone, however. Current CPU architectures are full of performance tricks that interact with each other and memory access has a hierarchical cost depending on how far away the memory is from the inner workings of the CPU. Given this complex state of affairs, the chances are that your intuition is wrong when it comes to judging the performance of a chunk of code.

So if our intuition is of no use, what do we do? The answer, of course, is to measure the actual performance of code alternatives in order to pick the one that works best for our work loads.

This month, Richard Thomson will give us an introduction to "microbenchmarking" using Google's benchmark library. In microbenchmarking, we are measuring the performance of small units of code -- a function, loop, etc. This is similar to a unit test as compared to an integration test.

This will be an online meeting, so drinks and snacks are on you!

TBD

This will be an online meeting, so drinks and snacks are on you!

TBD

This will be an online meeting, so drinks and snacks are on you!

TBD

This will be an online meeting, so drinks and snacks are on you!