Mercurial > hg > Papers > 2015 > sugi-master
view paper/chapter4.tex @ 7:a9a8f37945d4
modify chapter4
author | sugi |
---|---|
date | Wed, 07 Jan 2015 13:20:56 +0900 |
parents | 295b393a7134 |
children | f948d683c29a |
line wrap: on
line source
\chapter{改善点} \label{chapter:chapter4} %この章では、分散フレームワークAliceに対して行った改善点を示す。 \section{並列環境における改善} 分散フレームワークAliceは、並列環境に対応したフレームワークである。しかし、並列環境に対応していることを確認するためにbitonic sortを作成、計測したところ、Data Segmentの更新のオーバーヘッドにより、期待した効果を得ることができなかった。その際に、行った改善点を示す。 \subsection{SEDA Architecture} SEDA Architectureとはマルチコアスレッドを用いて大量の接続を管理し、受け取ったデータを処理ごとに分けられたステージと呼ばれるスレッドに投げ、処理が終わると次のステージにデータを伝搬させていく処理方式である。 スループット重視のでありレスポンスは多段のパイプラインのせいで遅れてしまう。 Aliceに置いてSEDAを実装するにあたり、データを次のステージにへ伝搬する際、LinkedBlockingQueueを使用している。LinkedBlockingQueueは片方向の連結リストをベースとしたQueue実装である。enqueue / dequeueの操作時の排他制御にはそれぞれ別々のロックオブジェクトが使用されている。そのため、enqueueとdequeueが重なってもロック解除待ちは発生しないが、そのかわりに連結リストのNodeオブジェクトの生成操作などが発生してしまうため、enqueue操作の処理コストが高い。 さらに、非力なマシーンではSEDAの効果を得られず、スレッドを切り替えが頻繁に起こりオーバーヘッドになってしまう。 以上の理由からLocal Data Segmentに対して操作をする際はSEDAを使用せず処理を行なうように変更した。 変更前は、Local Data Segmentに対して操作する場合、putやpeekに沿ったCommandを作成するステージ(Code Segmentが実行されているスレッド)、受け取ったCommandを処理するステージ、Code SegmentにData Segmentをセットするステージ(peekとtakeの場合)の2段または3段のパイプラインで構成されていた。これらを1つのステージにまとめて処理することで、並列環境における性能を向上させた。 \subsection{Data Segment の再構成(flip 機能の追加)} \subsection{Data Segmentのデータ表現の追加} 変更前はData Segmentのデータ表現はMessage Pack for JaveのValueオブジェクトのみを用いて表現していた。 Valueオブジェクトとは、Message Packのバイナリにシリアライズできる型のみで構成されたJavaのオブジェクトであり、自己記述形式のデータ形式となっている。そのため、ArrayValueを用いることにより、ユーザーはデータを後からつなげたりすることも可能である。 このValueオブジェクトの特徴の1つに、通信に関わる際のシリアライズ・デシリアライズを高速に行えることがある。 この特徴を用いて、Remote Data Segmentに対する通信の高速化を狙っていた。 しかし、Local Data Segmentに対する通信においては逆効果である。データをLocal Data Segmentに対してputするたびにValue型に変換するコストがかかる。データをpeekする際にもValue型から元の型に変換するというコストがかかる。 この問題を解決するために、一般的なJavaのクラスオブジェクトでもデータ表現を可能にした。Local Data Segmentに対してputする場合は、Valueオブジェクトに変換せず一般的なJavaのクラスオブジェクトのままで、Remote Data Segmentに対してputする場合にのみValueに変換する。これにより、無駄な変換コストを抑えられるようになった。 \section{分散環境における改善} \subsection{Protocolの再設計}