Errata

Surname typo. It is "Juraj Michalak", should be "Juraj Michalek".

> ls -l /proc/$PID>/map_files

Wouldn't this command originally look something like the following?

ls -l /proc/$PID/map_files

Note from the Author or Editor:
Yes, thanks for finding this!

In this paragraph, you mentioned that the wasted memory size is 10 TB. However, it seems like there might be a typo in your calculation. 1MB * 100 times * 100 desktops, it would actually amount to about 10 GB, not 10 TB. Is that correct?

Note from the Author or Editor:
Yup, I simplified this sentence in errata. Thanks!

> os.ReadFile and bytes.Split are short enough, so the compiler can copy the
whole body of the Sum function.

Wouldn't it be correct for ’whole body of the Sum' to be '... to the Sum' in this sentence?

Note from the Author or Editor:
Nice catch! I would rather say "os.ReadFile` and `bytes.Split` functions are short enough, so the compiler can copy their whole body to the `Sum` function."

Thanks!

The filenames in the prompt (v1.txt, v2.txt, v3.txt) do not match the output. Which one is correct?

Note from the Author or Editor:
Yup, thanks! Clarified that and in Example 10-14

> Yes! If we don’t invoke the returned context.CancelContext function, ...

'CancelContext' is a typo for 'CancelFunc' ?

Note from the Author or Editor:
Correct!

In the numerous bullet point #1, it says:

> Variables a, b, and c are not used, so they cause a compilation error.

However, variable c is used for the initialization of variable d in example 2-7. As the code comment says, the variable not used here is d.

Note from the Author or Editor:
Yes, it should be "Variables a, b and d are not used."

Thanks!

> Use the value receiver (no func (g Group) SomeMethod()) if your method does not modify the Group state.

"No" just before `func` doesn't make sense here. I assume this should be "e.g." like what in the second bullet point. (i.e. this part is going to be "e.g. func (g Group) SomeMethod() )

Note from the Author or Editor:
Yes, it should be "e.g.," instead of "no"


Thanks!

> Make sure you try writing your own basic Go program, write a unit test, and use loops, switches, and concurrency mechanisms like channels and routines.

The last word "routines" should be "goroutines".

Note from the Author or Editor:
Correct, thanks!

> -gcflags="-m=<number> builds the code while printing the main optimization decisions

I think the closing double quotation is missing; i.e. the option should be -gcflags="-m=<number>".

The title of the collection models have been swapped. The first one should be Pull and the second one Push

Note from the Author or Editor:
Wow, interesting how this happened (post production?). Anyway, thanks a lot for noticing. You are totally right.

It should be doOperation instead of cooperation function

Note from the Author or Editor:
Great finding thanks!

> if we don’t have the data in the registers, the CPU has to fetch it from L-caches,　which might take one nanosecond. If L-caches contain data the CPU needs, our single statement might take 50 ns.

This sentens says 'cached data is slower than non-cached data'. but isn't this the opposite ?

Note from the Author or Editor:
You are right, there is a typo, it should be " if we don't have the data in the registers, the CPU has to fetch it from L-caches, which might take one nanosecond. If L-caches does not contain that data either, our single statement might take 50 ns."

Thanks!

> e.g., in the description of the pull report

I think this is typo of "the pull request".

Note from the Author or Editor:
Yes, thanks!

Step 5. contains “Then I benchmark again ( see step 5)…
I believe it should reference “step 4” instead

Note from the Author or Editor:
Yes, thanks!

> even use the embedded `tool pprof` like a viewer to analyze them.

I assume the sentence should be "even use the embedded `go tool pprof` like a viewer to analyze them. I think "go" is dropped from the line.

Note from the Author or Editor:
Correct, thanks!

> … to achieve a throughput of at least 10 * N nanoseconds. The baseline results give us 50 * N nanoseconds.

From my understanding throughput should be measured in units per time. Per Example this would be “ at least one line per 10 nanoseconds”. The baseline results give us 1/5 line per nanosecond”.
Since the section is about latency I believe it would be clearer to use “ a latency of at most 10 * N nanoseconds”

Note from the Author or Editor:
Yes, good point, thanks!

> e.g., we read ...\n12 and 34/n... in two different chunks.

"/n" after 34 should be "\n" (line break character)

Note from the Author or Editor:
Correct, should be:

e.g., we read ...`\n12` and `34\n`... in two different chunks

> we might read less than 10KB of bytes, so we need to process only n of them. We process all lines found in our 10 KB buffer in each loop iteration.

It's written as "10kb," but it is actually "8kb"?

Note from the Author or Editor:
nice catch thanks!

> We still don’t see the actual work, like parsing integers, since this work has outnumbered the overhead.

I think the last part of this sentence is the opposite. I suspect that this sentence tries to mean "We still don't see the actual work, like parsing integers, since the overhead outnumbered this work." The following paragraph also says:

> As a result, parsing and additions are faster than the communication overhead.

Note from the Author or Editor:
Nice catch, agree. Fixed it to:

```
We still don't see the actual work, like parsing integers, since the overhead have hidden it. This time the overhead is caused by three elements:

`runtime.schedule`:: The runtime code responsible for scheduling goroutines.
`runtime.chansend`:: In our case, waiting on the lock to send to our single channel.
`runtime.chanrecv`:: The same as `chansend` but waiting on a read from the receive channel.

Essentially, coordination and distribution of the work take more CPU resources than the work itself.
```

Thanks!