"Performance Matters" by Emery Berger

>There was a really interesting talk at Strange Loop this year about how quirks in code layout fool programmers into chasing their tails thinking they’re improving performance when they’re not. I think the author may be referring to this talk: this video

> deleting this one line of code can have a dramatic effect on seemingly unrelated performance micro-benchmarks. Some numbers get better (e.g. +5%), some numbers get worse (e.g. -10%). The same micro-benchmark can get faster on one C compiler but slower on another There's a fundamental disconnect that makes it difficult for humans to reason about performance in computer programs. Because the speed of light is so slow, computer architecture as we know it will always rely on cache and OoO to be fast. The human brain does seem to work out of order, but it's only used to thinking about a world that runs in order. When we use theory of mind, we don't model other people's minds, we use our own as a model for theirs; see mirror neurons[1]. Because of this, standard code benchmarks are not very useful, unless they can demonstrate order-of-magnitude speedups. Even something like a causal profiler[2][3][4], which attempts to control for the volatile aspects of performance, is of limited use; it cannot control for all variables and its results will likely be invalidated by the same architectural variation it tries to control for. Instead (with respect to performance) we should focus on three factors: - Code maintainability - Algorithmic complexity - Cache coherency Everything else is a distraction. 1. link 2. this video 3. link 4. link

> I originally missed your point about "multiples of" That wasn't my point, but the claim of the poster I was replying to, and it was exactly this claim that I think is unsupportable. Has some software gotten faster? Sure. But mostly software has a gotten slower and the rarer cases of software getting faster have been outpaced significantly by HW. > You want examples where software has sped up at a rate faster than hardware "several multiples": that in some/many areas software has improved performance by several multiples of the improvement in hardware performance over the last 20 years > [JavaScript] JIT compilers have improved The original JITs were done in the late 80s early 90s. And their practical impact is far less then the claimed impact. link As an example the Cog VM is a JIT for Squeak. They claim a 5x speedup in bytecodes/s. Nice. However the naive bytecode interpreter, in C, on commodity hardware in 1999 (Pentium/400) was 45 times faster than the one microcoded on a Xerox Dorado in 1984, which was a high-end, custom-built ECL machine costing many hundred thousands of dollars. (19m bytecodes/s vs. 400k bytecodes/s). So 5x for software, at least 45x for hardware. And the hardware kept improving afterward, nowadays at least another 10x. > [compilers] Parsing isn't as simple as it seems [..] Parsing is not where the time goes. > 2005-era swift running faster Swift generally has not gotten faster at all. I refer you back to Proebsting's Law and the evidence gathered i

We really don't know what causes perf differences, layout has more of an effect than -O1 to -O3. "Performance Matters" by Emery Berger this video

> changing my username breaks $product. this video Discussing a performance regression due to longer username due to username being in ENVIRONMENT variable which changes memory layout of process.

I understand where you are coming from, but without comparing the generated assembly, we are comparing an implementation of bounds checks. I think we should have a bounds check instruction and operates concurrently. I should play around this with this using a couple RISC-V cores. > Performance matters! this video by Emery Berger Another, yesbut, encryption and compression are and will handled by on die accelerators.

You're probably thinking of "Performance Matters" by Emery Berger, a Strange Loops talk. this video

One of my previous struggles has been profilers blaming whatever code is the first bit of code to force some memory into cache. We devs could take turns and claim to have improved our own code by a huge margin simply by rearranging the order of calls so ours was not first. Then pass the baton; global performance utterly unchanged, everyone gets to "optimize" their own code. Something like link might be the way forward. this video