いくつかのマシンビジョンの問題におけるElbrus-4CとElbrus-8Cの比較

この記事では、画像認識技術がElbrus-4Cおよび新しいElbrus-8Cでどのように機能するかを示します：いくつかのマシンビジョンの問題を検討し、それらを解決するアルゴリズムについて少し話し、ベンチマークの結果を示し、最後にビデオを示します。

Elbrus-8C-VLIWアーキテクチャを備えた新しい8コアプロセッサMCST。 1.3 GHzの周波数でエンジニアリングサンプルをテストしました。 おそらく、シリアルリリースで増加します。

Elbrus-4CとElbrus-8Cの特性を比較しましょう。

	エルブルス-4C	エルブルス-8S
クロック周波数、MHz	800	1300
コアの数	4	8
サイクルごとの操作数（コアごと）	23まで	25まで
コアごとのL1キャッシュ	64 kb	64 kb
コアごとのL2キャッシュ	2 Mb	512 kb
L3キャッシュ共有	-	16 Mb
RAMの構成	最大3チャネルのDDR3-1600 ECC	最大4チャネルのDDR3-1600 ECC
技術プロセス	65 nm	28 nm
トランジスタ数	9億8600万	2730百万
SIMD幅の説明	64ビット	64ビット
マルチプロセッサのサポート	最大4プロセッサ	最大4プロセッサ
生産開始年	2014	2016年
オペレーティングシステム	Elbrus OS 3.0-rc27	Elbrus OS 3.0-rc26
LCCコンパイラーのバージョン	1.21.18	1.21.14

Elbrus-8Cでは、クロック周波数が1.5倍以上に増加し、コアの数が2倍になり、アーキテクチャ自体が改善されました。

したがって、たとえば、Elbrus-8Cは、SIMDを除く1クロックあたり最大25命令を実行できます（Elbrus-4Cの場合は23に対して）。

重要 ：Elbrus-8Cの特別な最適化は実行していません。 EMLライブラリが関与していましたが、私たちのプロジェクトでのElbrusの最適化の量は現在、他のアーキテクチャよりも明らかに少ないです：数年の間に徐々に成長し、私たちはElbrusプラットフォームに取り組んでいます もちろん、時間のかかる主な機能は最適化されていますが、残りは手に届きません。

RFパスポート認識

もちろん、パスポート、運転免許証、銀行カード、その他の文書の認識を提供する製品Smart IDReader 1.6の発売により、新しいプラットフォームの開発を開始することにしました。 このアプリケーションの標準バージョンでは、1つのドキュメントを認識するときに4つ以下のストリームしか効果的に使用できないことに注意してください。 モバイルデバイスの場合、これで十分ですが、デスクトッププロセッサのベンチマークでは、マルチコアシステムのパフォーマンス評価が過小評価される可能性があります。

Elbrus OSのバージョンと提供されたlccコンパイラは、ソースコードに特別な変更を加える必要がなく、問題なくプロジェクトをまとめることができました。 新しいバージョンではC ++ 11が完全にサポートされていることに注意してください（Elbrus-4Cのlccの最新バージョンにも含まれています）。これは朗報です。

まず、 ここですでに説明したロシア連邦のパスポートの認識がElbrus-8Cでどのように機能するかを確認することにしました。 2つのモードでテストしました。別のフレーム（anywhere-mode）でのパスポートの検索と認識、およびWebカメラ（webcamモード）からのビデオでの認識です。 エニウェアモードでは、パスポート反転認識は1つのフレームで実行され、パスポートはフレームの任意の部分にあり、ランダムに方向付けられます。 ウェブカメラモードでは、写真付きのパスポートページのみが認識され、一連のフレームが処理されます。 パスポートの線は水平であり、パスポートはフレーム間でわずかにずれていると想定されています。 異なるフレームから受信した情報が統合され、認識の品質が向上します。

テストでは、1つのストリームで開始して並列化を開始するときに、各モードで1000個の画像を取得し、平均認識時間（画像の読み込みを考慮しない時間）を測定しました。 得られた稼働時間を下の表に示します。

モード	Elbrus-4C、s /フレーム	Elbrus-8S、S /フレーム	加速時間
どこでもモード、1ストリーム	4.57	2.78	1.64
どこでもモード、最大スレッド	3.09	1.78	1.74
ウェブカメラモード、1ストリーム	0.81	0.49	1.65
ウェブカメラモード、最大ストリーム	0.58	0.34	1.71

シングルスレッドモードの結果は、予想される結果と非常に一致しています：周波数の増加による加速（および4Cと8Cの周波数多重度は1300/800 = 1.625）に加えて、アーキテクチャの改善によるわずかな加速が顕著です。

スレッドの最大数で開始する場合、両方のモードの加速は1.7でした。 Elbrus-8Cのコアの数は4Cの2倍であるように思われます。 それでは、追加の4コアによる加速はどこにありますか？ 実際には、認識アルゴリズムは4つのストリームのみを積極的に使用し、それ以上のスケーリングは不十分であるため、パフォーマンスの向上は非常にわずかです。

次に、両方のプロセッサのすべてのコアをフルロードすることを決定し、いくつかのパスポート認識プロセスを開始しました。 各認識呼び出しは前の実験と同じ方法で並列化されましたが、ここではパスポートの処理時間にはファイルからの画像の読み込みが含まれていました。 時間測定は、同じ千のパスポートで実行されました。 完全にロードされたElbrusの結果を以下に示します。

モード	Elbrus-4C、s /フレーム	Elbrus-8S、S /フレーム	加速時間
どこでも	1.38	0.43	3.2
ウェブカメラ	0.47	0.19	2.5

エニウェアモードの場合、取得した加速度は予想される加速度に約3.6倍に近づきましたが、ファイルからの画像の読み込み時間を考慮に入れたため、到達しませんでした。 ウェブカメラモードの場合、読み込み時間の影響はさらに大きく、したがって、加速度はより緩やかであることが判明しました-2.5倍。

車の検出

特定のタイプのオブジェクトの検出は、技術的なビジョンの古典的なタスクの1つです。 これは、人、人、放棄されたオブジェクト、または明白な特徴的な兆候を持つ他のタイプのオブジェクトの検出です。

この例では、同じ方向に動いている車を検出するタスクを取ることにしました。 このような検出器は、自動車両制御システム、ナンバープレート認識システムなどで使用できます。 ためらうことなく、私たちはオフィスの近くの自動レコーダーを使用して、トレーニングとテスト用のビデオを撮影しました。 検出器として、カスケードViola-Jones分類器を使用しました[1]。 さらに、複数のフレームを連続して観察する車の位置に、見つかった車の位置の指数平滑化を適用しました。 検出は、フレーム全体を占有しないROI（関心領域）の長方形でのみ実行されることに注意してください。これは、車の内部とフレームに完全に収まらない車を検出しようとする意味がほとんどないためです。

したがって、このアルゴリズムは次の手順で構成されました。

1. フレームの中央でROI長方形を切り取ります。
2. カラーROI画像をグレーに変換します。
3. ビオラ・ジョーンズ徴候の推定。
   
   この段階では、Haarウェーブレットを迅速に計算するために、画像がスケーリングされ、補助フィーチャ（有向境界など）のマップが構築され、すべてのフィーチャの累積合計が計算されます。
4. 複数のウィンドウでViola-Jones分類器を起動します。
   
   ここでは、特定のステップで、分類器が起動される長方形のウィンドウが移動します。 分類子が肯定的な回答をした場合、オブジェクトが検出されました。 ウィンドウ内の画像は車に対応しています。 この場合、オブジェクトが配置されている画像領域が洗練されます。一次検出の近くで、同じサイズのウィンドウが選択されますが、ステップは小さく、分類器の入力にも送られます。 見つかったオブジェクトはすべて、さらに処理するために保存されます。 この手順は、入力画像のいくつかのスケールに対して繰り返されます。
   
   実際、この段階はタスクの主要な計算の複雑さを構成し、そのために並列化が特に実行されました。 tbbライブラリを使用して、有効なスレッド数を自動的に選択しました。
5. 検出器を適用した後に取得した検出の配列を処理します。 取得された検出の多くは非常に近く、同じオブジェクトに対応する可能性があるため、検出を十分に大きな交差領域と組み合わせます。 その結果、検出された車の位置を示す長方形の配列を取得します。
6. 前のフレームと現在のフレームの検出の比較。 長方形の交差面積が現在の長方形の面積の半分以上である場合、同じオブジェクトが検出されたと考えられます。 数式によってオブジェクトの位置を滑らかにします：
   
   x _i = x _i +（1-α） x _{i -1}
   
   y _i = y _i +（1-α） y _{i -1}
   
   w _i = w _i +（1-α） w _{i -1}
   
   h _i = h _i +（1-α） h _{i -1}
   
   ここで、（ x 、 y ）は長方形の左上隅の座標、 wとhはそれぞれその幅と高さ、αは実験的に選択された定数係数です。

入力データ：サイズ800x600ピクセルの一連のカラーフレーム。

以下、fps（1秒あたりのフレーム数）を推定するために、10回のプログラム開始時の平均動作時間を使用しました。 この場合、記録されたクリップを操作していたため、画像処理時間のみが考慮され、画像は単にファイルから読み込まれ、実際のシステムでは、たとえばカメラから取得できます。 検出は非常にまともな速度で動作し、Elbrus-4Cでは15.5 fps、Elbrus-8Cでは35.6 fpsが得られることが判明しました。 Elbrus-8Cでは、すべてのコアがピークに関与していますが、プロセッサーの負荷は完全にはほど遠いです。 これは明らかに、この問題のすべての計算が並列化されたわけではないという事実によるものです。 たとえば、Viola-Jones検出器を適用する前に、各フレームのかなり重い補助変換を実行し、システムのこの部分は順番に機能します。

さあ、デモンストレーションの時間です。 アプリケーションインターフェイスとレンダリングは、標準のQt5ツールを使用して実行されます。 それ以上の最適化は実行されませんでした。

エルブルス-4C

エルブルス-8S

視覚的ローカリゼーション

このアプリケーションでは、特異点に基づいて視覚的なローカリゼーションを実証することにしました。 GoogleストリートビューパノラマとGPSを使用して、システムにGPS座標やその他の外部情報のデータを使用せずにカメラの位置を見つける方法を教えました。 このようなシステムは、ドローンやロボットのバックアップナビゲーションシステムとして使用して、現在地を特定したり、GPSのないシステムで作業したりできます。

最初に、GPS座標を使用してパノラマデータベースを処理しました。 約0.4 km ^ 2モスクワ通りをカバーする660枚の画像を撮影しました。

次に、特別なポイントを使用して画像の説明を作成しました。 各画像について：

1. YAPE（Yet Another Point Detector）アルゴリズムによって3フレームスケール（フレーム自体、フレームの4/3倍に縮小されたフレーム）の特別なポイントを見つけ、それらのRFD記述子を計算しました[2]。
2. その座標、特異点のセット、記述子が保存されました。 その後、現在のフレームの特異点の記述子をデータベースの記述子の値と比較するため、ハミング距離をメトリックとして使用して記述子をツリーに保存すると便利です。 保存されたデータの合計サイズは15 MBをわずかに超えていました。

ここで準備が完了しました。次に、プログラム中に直接行われることに移りましょう。

1. カラー画像をグレーに変換します。
2. 自動コントラストを実行します。
3. YAPEアルゴリズムを使用して3つのフレームスケール（係数1、0.75、および0.5）の特別なポイントを検索し、それらのRFD記述子をカウントします。 これらのアルゴリズムは部分的に並列化されていますが、計算のかなりの部分に一貫性がありました。 また、Elbrusプラットフォーム用にまだ最適化されていません。
4. 取得された記述子のセットについて、ツリーに格納されている記述子の中で類似した記述子の検索が実行され、いくつかの最も類似したフレームが決定されます。 さまざまな記述子の場合、tbbを使用してツリー検索が並列化されます。 同時に、ビデオの最初の5フレームについて、最も近い10個のフレームを選択し、5フレームのみを取得します。
5. 車両の軌道は通常連続的であるため、選択されたフレームは「外れ値」を除去するために追加のフィルタリングを受けます。

入力データ：サイズ800x600ピクセルの一連のカラーフレーム。

このようなシステムは、Elbrus-4Cで3.0 fps、Elbrus-8Cで7.2 fpsを生成します。

仕組みを示します。

エルブルス-4C

エルブルス-8S

おわりに

便宜上、エルブラスの主な特徴とプログラムで得られた結果を表にまとめています。

テスト	エルブルス-4C	エルブルス-8S	加速時間
車の検出	15.5 fps	35.6 fps	2.3
視覚的ローカリゼーション	3.0 fps	7.2 fps	2.4
パスポート、どこでもモード、s /フレーム	3.09	1.78	1.74
パスポート、ウェブカメラモード、C /フレーム	0.58	0.34	1.71
パスポート、エニウェアモード、s /フレーム、フルプロセッサロード	1.38	0.43	3.2
パスポート、ウェブカメラモード、C /フレーム、フルプロセッサロード	0.47	0.19	2.5

現在の形式のアプリケーションでは4スレッド以上を効果的に使用できないため、パスポート認識の結果はかなり控えめであることが判明しました。 同様の状況は、車の検出と視覚的位置の場合です。アルゴリズムには比類のないセクションがあるため、コア数の増加に伴う線形スケーリングを期待する必要はありません。 ただし、すべてのプロセッサコアをロードするアプリケーションに制限がない場合、3.2倍の増加が見られます。これは、理論上の3.6倍に近い値です。 平均して、タスクセットでのMCSTプロセッサの世代間のパフォーマンスの差は約2〜3倍であり、これは非常に楽しいことです。 周波数を上げてアーキテクチャを改善することによってのみ、1.7倍以上のゲインが得られます。 ICSTは、年間5％を追加するという戦略でIntelに急速に追いついています。

全負荷でのテスト中、プロセッサアーキテクチャの成熟度を示すフリーズやクラッシュの問題は発生しませんでした。 Elbrus-8Cで開発されたVLIWアプローチにより、さまざまなコンピュータービジョンアルゴリズムのリアルタイム操作を実現できます。EMLライブラリには、コード自体を最適化しないユーザーの時間を節約する非常に堅実な数学関数のセットが含まれています。 結論として、別の実験を行い、1台のElbrus-8Cプロセッサーで3つのデモンストレーション（ローカライズ、車の検索、顔の検索）を同時に開始し、平均プロセッサー負荷は約80％でした。 コメントはありません。

会社とMCSTおよびINEUM Brookの従業員に、Elbrus-8Cを試して祝福する機会を与えてくれたことに感謝します-8はまともなプロセッサ以上のものであり、成功を祈っています！

使用したソース

[1] P.ヴィオラ、M。ジョーンズ、「単純な機能のブーストされたカスケードを使用した高速オブジェクト検出」、CVPR 2001の議事録。

[2] B. Fan、Q。Kong、T。Trzcinski、ZH Wang、C。Pan、およびP. Fua、「バイナリ機能記述のための受容フィールド選択」、IEEE Trans。 画像プロセス、Pp。 2583–2595、2014。