--- a/paper/cerium.tex	Wed Feb 17 20:29:45 2016 +0900
+++ b/paper/cerium.tex	Thu Feb 18 07:20:46 2016 +0900
@@ -451,18 +451,29 @@
 データ転送の最適化が十分に成されていない可能性があるので、GPU の実行機構を見直す必要がある。
 
 \section{Cerium の問題点}
-Cerium では Task 間の依存関係を記述することで並列処理を実現する。
-しかし、本来 Task はデータが揃えば実行可能になるものである。
-Task 間の依存関係だけでは待っている Task が不正な処理を行いデータがおかしくなっても Task の終了は通知され、そのまま処理が続行されてしまう。
-その場合、どこでデータがおかしくなったのか特定するのは難しくデバッグに多くの時間が取られてしまう。
-また、Cerium の Task は汎用ポインタでデータを受け取るので型の情報がない。
-型の情報がないので Task を実行するまで正しい型かどうか判断することが出来ない。
-不正な型でも強制的に型変換され実行されるのでデータの構造を破壊する可能性がある。
-型システムによってプログラムの正しさを保証することも出来ず、バグが入り込む原因になる。
-
-Cerium の Allocator は Thread 間で共有されている。
-共有されているので、ある Thread がメモリを確保しようとすると他の Thread は終了を待つ必要がある
-その間メモリを確保することができないので処理が止まり、なにもしない時間が生まれてしまう。
-これが並列度の低下に繋がり、処理速度が落ちる原因になる。
+\begin{itemize}
+  \item Task 間の依存関係 \\
+    Cerium では Task 間の依存関係を記述することで並列処理を実現する。
+    しかし、本来 Task はデータが揃えば実行可能になるものである。
+    Task 間の依存関係だけでは待っている Task が不正な処理を行いデータがおかしくなっても Task の終了は通知され、そのまま処理が続行されてしまう。
+    その場合、どこでデータがおかしくなったのか特定するのは難しくデバッグに多くの時間が取られてしまう。
+  \item データの型情報 \\
+    Cerium の Task は汎用ポインタでデータを受け取るので型の情報がない。
+    型の情報がないので Task を実行するまで正しい型かどうか判断することが出来ない。
+    不正な型でも強制的に型変換され実行されるのでデータの構造を破壊する可能性がある。
+    型システムによってプログラムの正しさを保証することも出来ず、バグが入り込む原因になる。
+  \item Allocator \\
+    Cerium の Allocator は Thread 間で共有されている。
+    共有されているので、ある Thread がメモリを確保しようとすると他の Thread は終了を待つ必要がある
+    その間メモリを確保することができないので処理が止まり、なにもしない時間が生まれてしまう。
+    これが並列度の低下に繋がり、処理速度が落ちる原因になる。
+  \item オブジェクト指向と並列処理 \\
+    一般的に同じ入力に対して、同じ出力を返すことが保証される参照透過な処理は並列化を行いやすい。
+    一方、オブジェクト指向は保守性と再利用性を高めるためにカプセル化やポリモフィズムを重視する。
+    オブジェクトの状態によって振る舞いが変わるため並列処理との相性が悪いと言える。
+  \item Cerium の実装 \\
+    Ceirum の実装自体が並列処理を意識したものになっていない。
+    並列プログラミングフレームワークはそれ自体が並列処理を記述するための指針となるように実装されているべきである。
+\end{itemize}
 
 今回設計した Gears OS はこれらの問題を解決することを目的としている。