Fix typo

day6/README.md

@@ -469,7 +469,7 @@ conf000.dat
 同期コストはほぼ変わらないため、相対的に並列化効率は良くなる。この場合は、12スレッドで並列化効率76%、24スレッドで41%である。
 サイズを増やせば増やすほど効率が高くなることが想像できよう。
 
-一般論として、スレッド並列において同期コストが見えてしまった時、そのコストをなんとかしようと努力するのは、苦労のわりに実入りが少ない。なので、そういう時には計算するモデルを見直し、同期コストが見えないほど重い計算をすれば良い。繰り返しになるが**並列化効率で困ったらウィースケーリングに逃げてサイズで殴れ！**。せっかく「並列化」という武器を手に入れたのだから、その武器を手に入れる前の敵とばかり戦うのではなく、その武器が最大限輝く敵を探す方が有益である。
+一般論として、スレッド並列において同期コストが見えてしまった時、そのコストをなんとかしようと努力するのは、苦労のわりに実入りが少ない。なので、そういう時には計算するモデルを見直し、同期コストが見えないほど重い計算をすれば良い。繰り返しになるが**並列化効率で困ったらウィークスケーリングに逃げてサイズで殴れ！**。せっかく「並列化」という武器を手に入れたのだから、その武器を手に入れる前の敵とばかり戦うのではなく、その武器が最大限輝く敵を探す方が有益である。
 
 本当はOpenMPについてもう少し真面目に、たとえばNUMA最適化やLoop Fusion/Fission/Collapseなども扱おうかと思ったのだが、正直面倒くさくなった。個人的な感想で申し訳ないのだが、ディレクティブベースの最適化はコンパイラが何をやっているかが分かりづらく、隔靴掻痒の感があってどうしても好きになれない。
 
@@ -510,7 +510,7 @@ OMP_NUM_THREADS=24 record ./gs_omp1.out
 ![バリア命令のアセンブリ](fig/perf2.png)
 
 非常に単純なコードだが、気になる命令がある。`lock`だ。実は`lock`は命令ではなく、命令のプリフィックスである。「後に続く命令をアトミックにしてください」という修飾語のようなものだ。
-`lock`の後には、`inc`や`xchg`、そしてここで出てくる`subl'など、いわゆる「read-modify-write」命令が入る。
+`lock`の後には、`inc`や`xchg`、そしてここで出てくる`subl`など、いわゆる「read-modify-write」命令が入る。
 「read-modify-write」とは、「メモリから何かを読み出し、修正して、書き戻す」という一連の動作である。普通はこの動作はアトミックにならない。
 アトミックとは「不可分である、分けられない」という意味である。アトミックでない場合、この一連の動作の合間に他のスレッドの動作が割り込んでくる可能性がある。
 マルチスレッドでこういうことが起きるといろいろ困ることがある。よく言われるのが銀行のATMの例だ。今、100万円の貯金がある口座から、2つのATMからほぼ同時に1万円を