SLIDE 1
Everyday Efficiencies
Todd L. Montgomery @toddlmontgomery
StoneTor
Why should we care? Understanding (In)Efficiencies Efficiencies anyone can do
Everyday Efficiencies
Everyday Efficiencies Todd L. Montgomery @toddlmontgomery Everyday - - PowerPoint PPT Presentation
Everyday Efficiencies Todd L. Montgomery @toddlmontgomery Everyday - - PowerPoint PPT Presentation
StoneTor Everyday Efficiencies Todd L. Montgomery @toddlmontgomery Everyday Efficiencies Why should we care? Understanding (In)Efficiencies Efficiencies anyone can do https://www.nature.com/articles/d41586-018-06610-y
SLIDE 2
SLIDE 3
https://www.forbes.com/sites/forbestechcouncil/2017/12/15/why-energy-is-a-big-and-rapidly-growing-problem-for-data-centers/#344456665a30 https://www.datacenterdynamics.com/opinions/power-consumption-data-centers-global-problem/ https://www.nature.com/articles/d41586-018-06610-y
SLIDE 4
Efficiency/Performance Non-Functional Requirement
SLIDE 5
Performance Quality Robustness Safety Stability Usability
https://en.wikipedia.org/wiki/Non-functional_requirement
SLIDE 6
https://en.wikipedia.org/wiki/Non-functional_requirement
SLIDE 7
When not met is the system not “Non-Functional”?
SLIDE 8
“Non”-Functional Requirements Are Unspoken / Incomplete Functional Requirements
SLIDE 9
Performance (Quality/Security/etc) At best, an afterthought!
SLIDE 10
It* isn’t an Issue … Until it (suddenly) is
* - Performance/Quality/Security…
SLIDE 11
And then… It is often too late
SLIDE 12
In the age of cloud… Just throw machines at it
SLIDE 13
Universal Scalability Law
2 4 6 8 10 12 14 16 18 20 1 2 4 8 16 32 64 128 256 512 1024
Speedup Processors
Amdahl USL
SLIDE 14
That Real Quote on “Premature Optimization” and the root of all evil
SLIDE 15
https://en.wikiquote.org/wiki/Donald_Knuth
SLIDE 16
https://en.wikiquote.org/wiki/Donald_Knuth
SLIDE 17
https://en.wikipedia.org/wiki/Pareto_principle
Pareto Principle 80/20 Rule
SLIDE 18
Let Data Guide “Where”
SLIDE 19
“But it doesn’t have to be fast!!!”
SLIDE 20
“But it doesn’t have to be fast!!!” Doesn’t have to be SLOW either!
SLIDE 21
“But it doesn’t have to be fast!!!” “But it doesn’t have to be secure!!!” “But it doesn’t have to ____!!!” “But it doesn’t have to WORK!!!??“
SLIDE 22
We seem to assume speed/security/quality/etc. is a “special” characteristic added… later
SLIDE 23
“But it doesn’t have to be ____*!!!” “…It’s not my fault!”
* - Fast/Work/Secure…
SLIDE 24
Other Engineering Disciplines Top speed of Sedan vs. F1
SLIDE 25
2x? 3x? 10x? Do our systems do 100M, 30M, 3K, or 300 tps?
SLIDE 26
Why are things inefficient?
SLIDE 27
Not Enough Time? Too “Lazy”? Gap(s) in Knowledge? Too Much Complexity?
SLIDE 28
End Result Bad Design Choices
SLIDE 29
Design
SLIDE 30
Performance Quality Security Start with Design
SLIDE 31
Everyday Efficiencies Be Lazy Don’t reward bad ideas Don’t be Naive
SLIDE 32
Good Engineering is Laziness Too lazy to do something complicated Never too lazy to stop making it better
SLIDE 33
Don’t reward bad ideas Don’t let bad ideas stay around Don’t be afraid to move on Don’t be afraid to try something new
SLIDE 34
Absolutes are for the naive
SLIDE 35
Always use X! Never use Y! Better: Favor X over Y
SLIDE 36
Concrete Suggestions
SLIDE 37
Ownership, Dependency, & Coupling Complexity Kills Layers of Abstraction are not free Manage Your Resources
SLIDE 38
Understand Your Tools (OS, language, CPU, disk, libs, etc.) The Compiler is BETTER than you Idioms Matter
SLIDE 39
Abstract Later Design for Composition
SLIDE 40
Counted vs. Uncounted Loops Predictable Branches Simple Conditionals Stack Allocation Favor Arrays over Lists Primitive Data Structures
SLIDE 41
Everyday Efficiencies Be Lazy Don’t reward bad ideas Don’t be Naive All starts with Design
SLIDE 42
Twitter: @toddlmontgomery
Thank You!
Questions?
StoneTor