Gopher in performance_tales_ms_go_cracow
- 1. Gopher in performance tales Mateusz Szczyrzyca mateusz@szczyrzyca.pl http://mateusz.szczyrzyca. pl picture from: https://golangtraining-in-web.appspot.com/
- 2. It’s about… • Performance in general • Some important basics • Interesting performance case studies • From the Gopher world’s perspective: • general basics and tips • pprof & tracer • recommendations
- 3. Preface Things are not that simple as they look like. Especially numbers. Trade offs are always a part of software performance engineering
- 4. Performance (Software) How available hardware resources are utilized by applications app ability to operate under certain conditions (low hardware resources, big amount of traffic, etc)
- 5. Basic terms • algorithm • runtime / compile time • stack & heap • GC (garbage collector) • real/user/sys time • Big-O notation • concurrency (multithreading) • parallelism • IOPs • Throughput, Latency, Response time • utilization • saturation • bottleneck • Workload
- 6. Stack vs Heap source: https://stackoverflow.com/questions/79923/what-and-where-are-th
- 7. Throughput, Latency, Response Time, Saturation
- 8. Throughput, Latency, Response Time, Saturation
- 9. Root of all evil Premature optimizations When you lose your time and efforts to make uneccessary optimalizations or choices (ex. changing tech stack) because you imagine it will be needed in the future.
- 10. Premature optimization ….is like a casual car for everyday city driving
- 11. The most difficult part Benchmar k
- 14. Real world app
- 15. Real world project timeline
- 17. Fast (cpu-bound) languages • Assembler? • C? • C++? • Rust? • Java? • Go? • Python?
- 18. Case study: Python (Japronto) source: https://github.com/squeaky-pl/j
- 19. Case study: Python (Japronto) source: https://github.com/squeaky-pl/j
- 20. Case study: Go (fasthttp) source: https://github.com/valyala/fasth
- 21. Case study: chess engines The most important factors: 1) playing strength (ELO) 2) analysis speed (nodes per sec), especially in alpha-beta prunning engines
- 22. Case study: chess engines
- 23. Case study: stockfish • it’s a chess engine (strongest alpha-beta prunning) • it’s written in C++ • it uses multithreading efficiently • It has many derivates, asmFish is one of them (written in x86 asm)
- 24. Case study: stockfish Suprisingly asmFish is neither the strongest or „fastest�� type of stockfish version.
- 25. Stockfish: the strongest because of The evaluation speed? • No: Houdini 6.03 (alpha-beta prunning) chess engine is faster (nodes per sec on same machine). But Houdini 6.03 is a slighty weaker engine. • Yes: Better chess algorithms (but the main algorithm is the same) • Leela Chess Zero: NN-based chess engine, 1000x slower in terms of nodes per sec. Currently slightly weaker than stockfish.
- 26. Stockfish vs Leela Chess Zero • Leela Chess Zero: NN-based (MCTS) chess engine, build to reflect AlphaZero DeepMind ideas (using NN and MCTS in chess) • Self learning algorithm (games between LC0 vs LC0 and LC0 vs rest of the world) • Slower more than 1000x in terms of nodes per second than stockfish due to the different algorithm • It’s playing strength it’s very close to stockfish, especially at very fast games (bullet and blitz chess)
- 27. Case study: fibonacci numbers Task: get 50th numer from the fibonacci sequence C vs Python
- 28. Case study: fibonacci numbers
- 29. Performance eaters • algorithms • doing unnecessary work (GC, logging) • non cpu-bound waiting • not using multithreading • using too many threads • slow (cpu-bound) programming language?
- 31. Go: benchmarking
- 32. Go: benchmarking
- 33. Go: pprof Package pprof writes runtime profiling data in the format expected by the pprof visualization tool. Useful for profiling CPU & Memory.
- 34. Go: pprof
- 35. Go: trace Useful for trace execution of the program over time and goroutines
- 36. Performance profiling steps 1. Measurement: • make benchmark and get results, • do profiling to determine a bottleneck, 2. Make appropiate changes in your code 3. Repeat 1) and 2) if results are still no acceptable
- 40. Go: GC Garbage Collector (GC) allows you to focus on business logic instead of memory management. However, this can lead to some performance tradeoffs in some cases. Turning off GC completely is highly not recommended unless you really know what are you doing (you risk crash of your app) GC usually does what you would have done in your code without such mechanism. GC improves slightly (usually) in every new Go version, but don’t treat this statement as a general rule
- 41. Go: GC runtime/debug – some tunning/stats options Disabling GC may improve performance if there are many short lived memory allocations but it’s not recommended overall due to it’s side effects
- 42. Go: pointer vs value Performance dilemma pointer value stack or heap (mostly) – GC traces it, exception: unsafe.Pointer (as uintptrs) stack, no GC pressure passing bigger data structures passing small values underlying value can be modified value is for read-only no thread safe (synch needed) thread safe
- 43. Go: array vs slice […]array Size is known during compile time thus not flexibe. Compiler checks validity of indexes. Good for performance (keep on stack) if you know exact size of array. []slice the rest cases that does not apply to arrays. Accessing elements out of scope results in runtime panic. Preallocated slices are better for performance.
- 44. Go: Escape analysis The compiler warns if variables will be stored on heap. It applies for dynamic data structures which size cannot be determined during compile time
- 51. Go: too few/many goroutines Sometimes not using many threads (goroutines in Go) may affect performance. The opposite scenario is also possible – using too many goroutines can impact performance negatively https://golang.org/pkg/runtime/#GOMAXP
- 52. Go: sync.Pool Use it to reduce memory allocations temporary objects than can be stored/retrievied later By allocation reduction you can reduce GC activities
- 53. Go: sync.Pool
- 54. Go: sync.Pool
- 55. Go: sync.Pool
- 57. Go: interface{ } problem
- 58. Go: interface{ } problem why? …lets find out using pprof
- 59. Go: interface{ } problem
- 60. Go: faster libs than std std lib non std (fast) lib net/http fasthttp html/template fasttemplate encoding/json gojay
- 61. Go: non discussed here • channels vs mutexes • Advanced GC tunning and GC-wise programming • struct paddings (memory saving) • unsafe.Pointer and unsafe package
- 62. Conclusions Focus on your business logic and on the architecture
- 63. Conclusions Write idiomatic and clean Go code
- 65. Conclusions Avoid using interface{} if it’s possible and use a specific type instead
- 66. Conclusions Use tests, linters, code reviews, etc
- 67. Conclusions Detect your bottlenecks and profile your code when it’s needed
- 68. Conclusions Use microoptimalisations if they are required
- 69. Conclusions Rewrite a performance-problematic part in another programming language if it offers functionality which you need. Use it when rewritting does not cost too much time and/or there is the lib in another language for you purpose
- 70. Conclusions Rewrite the entire app in a performant cpu-bound language if it won’t take too much time, all required libs are available and the effort is really worth of it
- 71. Links • https://golang.org/pkg/runtime/pprof/ • https://golang.org/pkg/runtime/trace/ • https://blog.golang.org/profiling-go-programs • https://github.com/golang/go/wiki/Performance • http://www.brendangregg.com/ • https://github.com/dgryski/go-perfbook • https://dave.cheney.net/tag/performance • http://bigocheatsheet.com/