haskellfoundation / hs-opt-handbook.github.io Goto Github PK

link

relate to polymorphism and specialization. Be sure to show Stg and Core and give precise instructions on when we know something has not fused.

Add a here there be dragons quote for Rules. These come with some real downsides.

Change to the smaller distribution to save CI.

what it is and why you want it during benchmarking. It is a band aid

I believe we can indeed use dtrace because of Ben's DWARF symbol implementation. Can we? Should we? This is the chapter to figure that out and write it down if it is indeed possible and useful.

chapter should also relate to fusion and a discussion of the overhead caused by too much parallelism

link:

• see related work on unpacked sum types: https://gitlab.haskell.org/ghc/ghc/-/wikis/unpacked-sum-types

This chapter should also show the changes in Core and Stg

Should have:

- good patterns
- bad patterns and how to fix them
- description of all information dumped by core
- possibly description of unarisation?
- description of slow_ap and fast_ap and other machine fundamentals
- no-update or update lambda

for this and #13 make sure it connects to the user's vision of their code.

Need an example for the slow programs section that shows a high impedance between the program domain and the problem domain evinced through the lack of composable functions.

This should be a case study.

Show core and stg.

Chapter for emitting and understanding flamegraphs in the context of GHC. Perhaps this moves to the GHC section because it relies on -prof?

some links:

• https://github.com/fpco/ghc-prof-flamegraph
• https://github.com/llelf/flamingra

https://chiplicity.readthedocs.io/en/latest/Using_Sphinx/UsingBibTeXCitationsInSphinx.html#rst-biblio-ref

links:

• https://github.com/input-output-hk/nothunks
• https://youtu.be/7t6wt7ByBWg

A user should be able to look at a ADT definition and know how many machine words are needed to represent that ADT in the worst case

According to the sphinx docs we should be able to do something like:

html_sidebars = { '**':
                  ['localtoc.html',
                   'relations.html',
                   'searchbox.html'
                   ]
                }

in conf.py, unfortunately for whatever reason this makes the landing page for the book (and every page actually) a blank white screen on chrome and firefox 🤷

This ticket is done when:

• We have a fine grained table of contents in the sidebar
• It actually works without nuking all content in the book.

I suspect this is a css issue because the page source still contains the content of each .rst file. I bet the sidebar is expanding to the whole screen or something strange like that.

Write section in Forward.

Relevant part of the Proposal, I've tweaked some stuff and we'll probably need to refine this section

3. What makes Haskell programs slow down (in order of importance)
3.1 Doing more work than necessary <=> too much allocation
3.2 Fusion and why it sometimes fails
3.3 Too much polymorphism
3.4 Bad datastructures

This section is a list of things to disable/change to reduce noise in measurement. It should also link to similar lists and provide shell one-liners to achieve the things in the list.

references:

• https://easyperf.net/blog/2019/08/02/Perf-measurement-environment-on-Linux

• describe worker/wrapper
• show a case when the optimization doesn't fire
• show how to perform manually with a concrete example
• take that concrete example and create a generic example
• show the Core and Stg difference for both when worker/wrapper fires, when it doesn't and when done manually.

May it be a light to you in dark places, when all other lights go out.

see

• Brenden Gregg's excellent site: https://www.brendangregg.com/perf.html
• the docs: https://perf.wiki.kernel.org/index.php/Main_Page
• more docs: https://www.ibm.com/docs/en/linux-on-systems?topic=performance-getting-started-perf-command

links:

• https://hackage.haskell.org/package/weigh

mostly tuning the garbage collector.

combine these because of similar api

link:

• https://hackage.haskell.org/package/inspection-testing

Again, don't rewrite the manual but this is the place to discuss:

• -prof
  and associated tools such as:
• profiteur
• viewprof
• ghc-prof
• profiterole

Write section in foreword

The simplest of ways. Perhaps combine this with another tool if it is too short?

Just adapt the ghc wiki page

This used to be important, not sure if GHC 9.X optimizes these away now. It might so need to verify. Case study on IntMap is here though, see the source code of containers for details.

Be sure to show Stg and Core too.

discuss when to use foldl vs foldr vs both the strict versions. Cite Alexis' legendary github comment.

Described by this blog post

The tools we use have a profound (and devious!) influence on our thinking habits, and, therefore, on our thinking abilities.

see:

• the docs: https://valgrind.org/

read them, love them, they are quite good!

just adapt wiki page or my blog post for tweag

Chapter on which GHC flags to use. Don't rewrite the user manual just add a lot of supporting material!

Write this section in the forward

Chapter on how eta-expansion can change performance.

• should show the core and stg
• need benchmarks for this
• might add it to canonical programs section
• consider describing the oneShot monad trick

References from around the web:

• https://mail.haskell.org/pipermail/haskell-cafe/2022-June/135383.html
• https://discourse.haskell.org/t/memoization-performance/4709

this might be a section in a future excessive allocation chapter

This chapter should also show the Core and Stg to tie into direct observations.

Use nix flakes!

This should be a step-by-step list of how to debug a performance issue including some scientific method such as crafting hypothesis. There should be a list of key questions relating such as "is this error deterministic or stochastic" and stuff like that. Perhaps we start with a "What do we know" then "craft a hypothesis" then "test the hypothesis"

1.1.1 heap profiling (most importantly what to look for, e.g., classic
triangle implies memory leak): -hT -hC -hy etc.

Be sure to describe in detail what the output means and how to interpret. A reader should be able to immediately gain insight into the runtime behavior of their program and pin-point the hot-spot.

Section should be small bite size snippets of recommendations for performance:

1. Use strict data
2. unpack strict fields if you don't need laziness
3. let GHC optimize for you, except in extremely hot loops where your effort is worth it
4. only use lists as a stack
   etc.

each one should have a variable and name associated so they can be linked throughout the text.

Should be accompanied by a case study. Perhaps on unordered-containers?

• show the indirection that makes this a performance anti-pattern
• provide guidance on how to what to do.

from the proposal

1.5 Direct Observation: Reading Core (and relating core to program behavior in detail)
1.5.1 Preliminaries: z-encoding, dumping and navigating core 
1.5.2 What allocation in Core looks like
1.5.3 Bad patterns in Core
1.5.4 Good patterns in Core
1.5.5 Demand analysis
1.5.6 Simplifier data in Core
1.5.7 Occurrence analysis 
1.5.8 Others?

For excessive closure allocation. See LeventErkok/sbv#572

be sure to update the Programs of consistent Lethargy Excessive closure allocation section to link to the case study