So You Wanna Go Fast?
•
16 likes•6,358 views
This document contains the transcript from a presentation titled "So You Wanna Go Fast?" by Tyler Treat. Some of the key topics discussed include measuring performance using tools like pprof, how different language features in Go like channels, interfaces, and memory management can impact performance, and techniques for writing concurrent and multi-core friendly code in Go like using read-write mutexes. The overall message is that performance depends greatly on the specific situation and trade-offs must be considered between concurrency, memory usage, and execution speed. Measuring first is emphasized to guide any optimizations.
Recommended
More Related Content
Viewers also liked
Viewers also liked (20)
Similar to So You Wanna Go Fast?
More from Tyler Treat
More from Tyler Treat (9)
Recently uploaded
Recently uploaded (20)
So You Wanna Go Fast?
- 1. Wanna Go So You Fast? Strange Loop 2017 @tyler_treat
- 3. @tyler_treat this one weird trick Make your code faster with
- 4. @tyler_treat this one weird trick Make your code faster with
- 6. @tyler_treat Spoiler Alert: Go is not a systems language…
- 7. @tyler_treat but that doesn’t mean you can’t build internet-scale systems with it.
- 8. @tyler_treat
- 9. @tyler_treat This is a talk about how to write terrible Go code.
- 11. @tyler_treat Because this is a talk about trade-offs.
- 12. @tyler_treat - Messaging Nerd @ Apcera - Working on nats.io - Distributed systems - bravenewgeek.com Tyler Treat
- 14. @tyler_treat matter? Why does this talk
- 17. @tyler_treat You have to be mindful of performance when it matters.
- 19. @tyler_treat@tyler_treat Where bad things hideWhere we’re usually looking
- 24. @tyler_treat Overview - Measuring performance - Language features - Memory management - Concurrency and multi-core
- 25. @tyler_treat Overview - Measuring performance - Language features - Memory management - Concurrency and multi-core
- 26. @tyler_treat Disclaimer: Don’t blindly apply optimizations presented.
- 27. @tyler_treat tl;dr of this talk is “IT DEPENDS!”
- 29. @tyler_treat Measurement Techniques - pprof - memory - cpu - blocking - GODEBUG - gctrace - schedtrace - allocfreetrace - Benchmarking - Code-level: testing.B - System-level: HdrHistogram (https://github.com/codahale/hdrhistogram) bench (https://github.com/tylertreat/bench)
- 31. @tyler_treat The only way to get good at something is to be really fucking bad at it for a long time.
- 32. @tyler_treat Benchmarking… a great way to rattle the Hacker News fart chamber.
- 33. @tyler_treat Overview - Measuring performance - Language features - Memory management - Concurrency and multi-core
- 35. @tyler_treat “Instead of explicitly using locks to mediate access to shared data, Go encourages the use of channels to pass references to data between goroutines.” https://blog.golang.org/share-memory-by-communicating
- 37. @tyler_treat@tyler_treat USE CHANNELS TO COORDINATE, NOT SYNCHRONIZE.
- 42. @tyler_treat Is defer still slow?
- 44. @tyler_treat The Secret Life of interface{}
- 45. @tyler_treat type Stringer interface { String() string } https://research.swtch.com/interfaces
- 46. @tyler_treat type Stringer interface { String() string } type Binary uint64 https://research.swtch.com/interfaces
- 47. @tyler_treat type Stringer interface { String() string } type Binary uint64 200 b := Binary(200) https://research.swtch.com/interfaces
- 48. @tyler_treat type Stringer interface { String() string } type Binary uint64 func (i Binary) String() string { return strconv.FormatUint(uint64(i), 2) } 200 b := Binary(200) https://research.swtch.com/interfaces
- 49. @tyler_treat type Stringer interface { String() string } https://research.swtch.com/interfaces s := Stringer(b) Stringer tab data
- 50. @tyler_treat s := Stringer(b) Stringer tab data . . . itable(Stringer, Binary) type fun[0] type(Binary) (*Binary).String type Stringer interface { String() string } https://research.swtch.com/interfaces
- 51. @tyler_treat tab data 200 Binary s := Stringer(b) Stringer . . . itable(Stringer, Binary) type fun[0] type(Binary) (*Binary).String type Stringer interface { String() string } https://research.swtch.com/interfaces
- 52. @tyler_treat
- 60. @tyler_treat $ go test -bench=. -gcflags="-m"
- 61. @tyler_treat $ go test -bench=. -gcflags="-m"
- 63. @tyler_treat $ go test -bench=. -gcflags="-l"
- 69. @tyler_treat@tyler_treat SSA backend & remaining type conversions inlined x.(*T) inlined
- 71. @tyler_treat
- 75. @tyler_treat $ go test -bench=. -gcflags="-S"
- 76. @tyler_treat $ go test -bench=. -gcflags="-S"
- 77. @tyler_treat $ go test -bench=. -gcflags="-S"
- 78. @tyler_treat Key Insight: If performance matters, write type-specific code.
- 79. @tyler_treat Overview - Measuring performance - Language features - Memory management - Concurrency and multi-core
- 81. @tyler_treat
- 84. @tyler_treat What’s going on here?
- 88. @tyler_treat How is sync.Pool so fast?
- 93. @tyler_treat Overview - Measuring performance - Language features - Memory management - Concurrency and multi-core
- 94. @tyler_treat “We generally don’t want sync/atomic to be used at all…Experience has shown us again and again that very very few people are capable of writing correct code that uses atomic operations…” —Ian Lance Taylor
- 95. @tyler_treat
- 96. @tyler_treat@tyler_treat Subscribers Messages Fast Topic Matching http://bravenewgeek.com/fast-topic-matching/
- 97. @tyler_treat@tyler_treat Subscribers Messages Fast Topic Matching http://bravenewgeek.com/fast-topic-matching/
- 104. @tyler_treat@tyler_treat G1 G1 1. Assign a generation, G1, to each I-node (empty struct). Ctrie
- 105. @tyler_treat 1. Assign a generation, G1, to each I-node (empty struct). 2. Add new node by copying I-node with updated branch and generation then GCAS, i.e. atomically: - compare I-nodes to detect tree mutations. - compare root generations to detect snapshots. @tyler_treat G2 G1 Ctrie
- 108. @tyler_treat The Go race detector doesn’t protect you from doing dumb stuff.
- 112. @tyler_treat Side note: unsafe is, in fact, unsafe.
- 113. @tyler_treat “Packages that import unsafe may depend on internal properties of the Go implementation. We reserve the right to make changes to the implementation that may break such programs.” https://golang.org/doc/go1compat
- 114. @tyler_treat
- 115. @tyler_treat Key Insight: Struct layout can make a big difference.
- 117. @tyler_treat https://github.com/Workiva/go-datastructures/blob/master/queue/ring.go @tyler_treat
- 149. @tyler_treat RWMutex1 RWMutex2 RWMutex3 RWMutexN…memory 24 bytes
- 150. @tyler_treat RWMutex1 RWMutex2 RWMutex3 RWMutexN…memory 24 bytes 64 bytes (cache line size)
- 151. @tyler_treat RWMutex1 RWMutex2 RWMutex3 RWMutexN…memory 24 bytes 64 bytes (cache line size) Cache rules everything around me
- 154. @tyler_treat padding … 64 bytes (cache line size) memory 24 bytes RWMutex1 Cache rules everything around me
- 158. @tyler_treat Go makes concurrency easy enough to be dangerous.
- 160. @tyler_treat The standard library provides general solutions (and they’re generally what you should use). 1
- 161. @tyler_treat Seemingly small, idiomatic decisions can have profound performance implications. 2
- 162. @tyler_treat The Go toolchain has lots of tools for analyzing your code—learn them. 3
- 163. @tyler_treat Go’s compiler and runtime continue to improve. 4
- 164. @tyler_treat Performance profile can change dramatically between releases. 5
- 165. @tyler_treat Relying on assumptions can be fatal. 6
- 166. @tyler_treat Code is marginal, architecture is material. 7
- 167. @tyler_treat Peeking behind the curtains can pay dividends. 8
- 168. @tyler_treat Above all, optimize for the right trade-off. 9
- 169. @tyler_treat Thanks!