FP and Performance
Beyond Big
“O” Notation
Jamie Allen
Director of Consulting
Who Am I?

• Director of

Consulting for

• Author of

Effective Akka

@jamie_allen
2
Big “O” Notation

3
Many Developers Don’t Look Further

4
Reactive Applications

5
What is Performance?
Latency

Throughput

Footprint

6
Power Consumption!

7
There are no standards
The only rules you must follow is your
non-functional requirements!

8
We Love Functional Programming!
• But what is it?
•Just first class functions?
•Referential transparency?
•Immutability?
•C...
Abstractions!
• They help us
reason about
our logic
• Decoupling
• Simplicity
• Correctness
• Reuse

10
Double Edged Sword
• We live in a world of abstractions
already!
•Languages on the JVM are DSL for bytecode
•Bytecode is a...
JVM == Imperative
• The JVM is built to execute imperative
logic very fast
• The more we stray from imperative logic
const...
Penalties
• Increased allocations
• More bytecode executed to perform
tasks
• Less control over runtime performance

13
There Is A Fine Line Here
• We love to write “elegant” code, but this
is defined by your personal aesthetic
•Some people lo...
Rap Genius

15
What About The Environment?

16
We Can’t Ignore the Cost!

17
Languages Impose Constraints
• “Choose-a-phone” languages versus those
with strictly defined language constructs

18
Languages “Pick” Abstractions For You
• Example: CSP versus Actor models
•Why must we choose?
•Why can’t we have both in l...
We Need to be Treated Like Adults!
• Every program will behave differently
• Choosing a language that imposes strict
rules...
How Many Libs Have Performance
Tests?
• Very few
• You give up
control of your
ability to optimize
when you use
libraries
...
Asynchrony
• A wonderful tool for leveraging cores on
a machine
• Not faster than a single thread per se
• We must pay att...
Hardware
From the bottom up, computers
understand queues and message passing

23
Things to Avoid
• Parallel Collections
• STM
• Returns out of closures
• Boxing
• Lambdas! :)

24
Digression: Don’t Use OSX
• It’s lousy for doing performance analysis
• The JVM has issues, particularly with
visibility

...
Tools Also Have Issues
• Many tools only give you information
after the JVM is at a safepoint
• What does that tell us abo...
Tools That I Trust
•
•
•
•

jHiccup (pauses and stalls)
Java Microbenchmarking Harness
PrintGCStats (post-mortem tool on G...
Pinning to Cores
• Use numactl for pinning to cores and
sockets
• taskset pins to cores only, no control
over cross-socket...
JVM Flags to Use
• Pay close attention to the output from:
• +PrintGCDetails
• +PrintGCDateStamp
• +PrintGCCause
• +PrintG...
Don’t Overuse Memory Barriers
• Volatile variables aren’t required for
every field
• Think about how to organize updates to...
Thank You!

31
Upcoming SlideShare
Loading in …5
×

20140228 fp and_performance

1,365 views

Published on

0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,365
On SlideShare
0
From Embeds
0
Number of Embeds
62
Actions
Shares
0
Downloads
23
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

20140228 fp and_performance

  1. 1. FP and Performance Beyond Big “O” Notation Jamie Allen Director of Consulting
  2. 2. Who Am I? • Director of Consulting for • Author of Effective Akka @jamie_allen 2
  3. 3. Big “O” Notation 3
  4. 4. Many Developers Don’t Look Further 4
  5. 5. Reactive Applications 5
  6. 6. What is Performance? Latency Throughput Footprint 6
  7. 7. Power Consumption! 7
  8. 8. There are no standards The only rules you must follow is your non-functional requirements! 8
  9. 9. We Love Functional Programming! • But what is it? •Just first class functions? •Referential transparency? •Immutability? •Category theory? 9
  10. 10. Abstractions! • They help us reason about our logic • Decoupling • Simplicity • Correctness • Reuse 10
  11. 11. Double Edged Sword • We live in a world of abstractions already! •Languages on the JVM are DSL for bytecode •Bytecode is an abstraction over macro instructions •Macro instructions are an abstraction over micro instructions 11
  12. 12. JVM == Imperative • The JVM is built to execute imperative logic very fast • The more we stray from imperative logic constructs, the more we pay in terms of performance 12
  13. 13. Penalties • Increased allocations • More bytecode executed to perform tasks • Less control over runtime performance 13
  14. 14. There Is A Fine Line Here • We love to write “elegant” code, but this is defined by your personal aesthetic •Some people love prefix notation and sexpressions •Some people see beauty in c-style constructs 14
  15. 15. Rap Genius 15
  16. 16. What About The Environment? 16
  17. 17. We Can’t Ignore the Cost! 17
  18. 18. Languages Impose Constraints • “Choose-a-phone” languages versus those with strictly defined language constructs 18
  19. 19. Languages “Pick” Abstractions For You • Example: CSP versus Actor models •Why must we choose? •Why can’t we have both in libraries? •Why can’t both be relevant to solving problems in an application? 19
  20. 20. We Need to be Treated Like Adults! • Every program will behave differently • Choosing a language that imposes strict rules forces us to make ugly choices 20
  21. 21. How Many Libs Have Performance Tests? • Very few • You give up control of your ability to optimize when you use libraries 21
  22. 22. Asynchrony • A wonderful tool for leveraging cores on a machine • Not faster than a single thread per se • We must pay attention to Amdahl’s Law 22
  23. 23. Hardware From the bottom up, computers understand queues and message passing 23
  24. 24. Things to Avoid • Parallel Collections • STM • Returns out of closures • Boxing • Lambdas! :) 24
  25. 25. Digression: Don’t Use OSX • It’s lousy for doing performance analysis • The JVM has issues, particularly with visibility 25
  26. 26. Tools Also Have Issues • Many tools only give you information after the JVM is at a safepoint • What does that tell us about our memory consumption or thread stacks? 26
  27. 27. Tools That I Trust • • • • jHiccup (pauses and stalls) Java Microbenchmarking Harness PrintGCStats (post-mortem tool on GC output in file) GC: • jClarity Censum • GarbageCat • VisualVM with Visual GC plugin • htop (visualize user vs kernel usage) • dstat (replaces vmstat, iostat and ifstat) • --cpu, --mem, --aio, --top-io, --top-bio • OProfile (system wide Linux profiler) 27
  28. 28. Pinning to Cores • Use numactl for pinning to cores and sockets • taskset pins to cores only, no control over cross-socket communication, which has latency penalties, but useful for laptop tests 28
  29. 29. JVM Flags to Use • Pay close attention to the output from: • +PrintGCDetails • +PrintGCDateStamp • +PrintGCCause • +PrintGCApplicationStoppedTime • +PrintTenuringDistribution (age of objects in survivor spaces) • +PrintSafepointStatistics (reason and timings) • +PrintFlagsFinal (show entire JVM config) • +PrintAssembly (must use +UnlockDiagnosticVMOptions) 29
  30. 30. Don’t Overuse Memory Barriers • Volatile variables aren’t required for every field • Think about how to organize updates to fields and then update ONE volatile var last to publish all 30
  31. 31. Thank You! 31

×