Chapter 4 edits

[dankamongmen]

notes:

• table 4.1: it seems L1 divides by 4 while the others divide by 2
• 4-7: you say all_loads = fb_hit + l1_hit + l1_miss, but your table has

29580 mem_load_retired.fb_hit
19036 mem_load_retired.l1_miss
497204 mem_load_retired.l1_hit

[schwarzgerat](0) $ echo $((29580 + 19036 + 497204))
545820
[schwarzgerat](0) $

but you have:

546230 mem_inst_retired.all_loads

leaving 410 unexplained

• 4.8: again, i think it predicts target, not direction
• don't like equating branch prediction and speculative execution. you can have BP without SE (for just fetch, for instance).

[dankamongmen]

normalized a lot of capitalization and units, leading to some bulk. called out things inline and in the PR notes.

[dendibakh]

@dankamongmen

notes:

• table 4.1: it seems L1 divides by 4 while the others divide by 2

Not sure if you want me to change anything in that table. Please let me know.

• 4-7: you say all_loads = fb_hit + l1_hit + l1_miss, but your table has

29580 mem_load_retired.fb_hit 19036 mem_load_retired.l1_miss 497204 mem_load_retired.l1_hit

[schwarzgerat](0) $ echo $((29580 + 19036 + 497204))
545820
[schwarzgerat](0) $

but you have:

546230 mem_inst_retired.all_loads

leaving 410 unexplained

Yeah, this is the artifact of using performance counters. The numbers may not exactly match. I will add a footnote about it in a separate commit.

• 4.8: again, i think it predicts target, not direction

Agree.

• don't like equating branch prediction and speculative execution. you can have BP without SE (for just fetch, for instance).

Agree. But did I make this mistake in this chapter? I don't remember seeing this.