Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add section about Haskell execution model #95

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

hsyl20
Copy link
Collaborator

@hsyl20 hsyl20 commented Jan 2, 2024

This adds a section about Haskell compilation pipeline and execution model.

Copy link
Collaborator

@doyougnu doyougnu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This still isn't finished. I'll have to add an entry for TSO into the glossary.

The last section is a good segue into the rest of the book and I think it should lead link into other chapters and the establishing paragraph for Measurement and Observation.

src/Measurement_Observation/haskell_model.rst Outdated Show resolved Hide resolved
src/Measurement_Observation/haskell_model.rst Outdated Show resolved Hide resolved
Comment on lines +22 to +23
In addition, lazy evaluation makes control-flow and memory usage difficult to
understand.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
In addition, lazy evaluation makes control-flow and memory usage difficult to
understand.
And finally, lazy evaluation can make control-flow and memory usage difficult to
understand.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This one is up to you. I just wanted to soften the claim because it makes it seem like this is an inherent feature of lazy evaluation and I'm not sure I agree with that.

src/Measurement_Observation/haskell_model.rst Outdated Show resolved Hide resolved
understand.

In this chapter we describe the compilation pipeline and the execution model.
For each stage of the pipeline we list what can be measured at runtime.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
For each stage of the pipeline we list what can be measured at runtime.
We'll begin from the familiar world of the Haskell language and descend into the depths of the machine. Then, for each stage or `intermediate representation<https://en.wikipedia.org/wiki/Intermediate_representation>`_ in the pipeline we'll list what can be measured at runtime.

src/Measurement_Observation/haskell_model.rst Outdated Show resolved Hide resolved
src/Measurement_Observation/haskell_model.rst Outdated Show resolved Hide resolved
Comment on lines +119 to +120
objects: e.g. the heap object that represents `10 :: Int64` uses 24 bytes
instead of 16 bytes without profiling. Because of this, you may find that your
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
objects: e.g. the heap object that represents `10 :: Int64` uses 24 bytes
instead of 16 bytes without profiling. Because of this, you may find that your
objects: e.g. the heap object that represents `10 :: Int64` uses 24 bytes without profiling, however with profiling this same object will use 16 bytes. Because of this, you may find that your

Comment on lines +122 to +123
code without this profiling enabled. **You have to be aware of the compilation
options you use when you make some runtime measurements.**
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
code without this profiling enabled. **You have to be aware of the compilation
options you use when you make some runtime measurements.**
Therefore **Be careful. You have to be aware of the compilation
options you use when you make some runtime measurements.**

Core: a simple and explicitly typed functional language. Types are basically
Haskell types. Type-class dictionaries are passed explicitly as records,
type-applications are used everywhere needed, coercions (proofs that we can
convert a type into another) are first class values, etc.
Copy link
Collaborator

@doyougnu doyougnu Jan 3, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
convert a type into another) are first class values, etc.
convert a type into another) are first class values, etc.
Core is a good intermediate representation to observe the effect of polymorphism and optimization passes on your code. Core should also be used as a first stop on the journey into the pipeline because it is the intermediate representation that will be closest to the familiar Haskell code. See the :ref:`Reading Core <Reading Core>` chapter for more.

layout for the target architecture. Then assembly code (textual) is generated
for the target architecture and an external assembler program generates machine
code (binary) for it. Finally an external linker is used to transform the
resulting code objects into a single executable or library.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We're missing a paragraph that states:

  • what information can I get by reading Cmm that I cannot get by reading STG and Core?
  • and then a link:
`:ref:`Reading Cmm <Reading Cmm>` 

to the reading cmm chapter.

doyougnu added a commit to doyougnu/hs-opt-handbook.github.io that referenced this pull request Jan 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants