link もっと前
   2019年 7月 18日 -
      2019年 7月 9日  
link もっと後

link 未来から過去へ表示(*)
link 過去から未来へ表示

日々

link permalink

除算命令

今まであまり CPU アーキテクチャの違いを感じたことはありませんが、除算命令を触っていたところ、アーキテクチャによってかなり動きが違っていて面白かったので、メモしておきます。

プログラムは下記のとおりです。

-1 による除算

#include <stdio.h>
#include <limits.h>

void f(int a, int b)
{
        printf("mul:%08x * %08x = %08x\n", a, b, a * b);
        printf("div:%08x / %08 = %08x\n", a, b, a / b);
}

int main(int argc, char *argv[])
{
        f(INT_MAX, -1);
        f(INT_MIN + 1, -1);
        f(INT_MIN, -1);     //乗算、除算の動作は未定義
        f(INT_MAX, 0);      //除算の動作は未定義
}

初めに断っておくと、コメントを打った箇所については、C 言語上の仕様上、動作が未定義です。つまり、どんなことでも起こり得ます。不定な結果が返ることもあるし、プログラムが停止することだってあります。

未定義動作も色々

このプログラムを x86 (x86_64, Ryzen 7 2700), ARM (AArch64, Cortex A53), RISC-V (RV64GC, SiFive FU540) の Linux 上でそれぞれ実行してみます。

各アーキテクチャでの実行結果

#### x86_64 ####

mul:7fffffff * ffffffff = 80000001
div:7fffffff / ffffffff = 80000001
mul:80000001 * ffffffff = 7fffffff
div:80000001 / ffffffff = 7fffffff
mul:80000000 * ffffffff = 80000000
Floating point exception


#### AArch64 ####

mul:7fffffff * ffffffff = 80000001
div:7fffffff / ffffffff = 80000001
mul:80000001 * ffffffff = 7fffffff
div:80000001 / ffffffff = 7fffffff
mul:80000000 * ffffffff = 80000000
div:80000000 / ffffffff = 80000000
mul:7fffffff * 00000000 = 00000000
div:7fffffff / 00000000 = 00000000


#### RV64GC ####

mul:7fffffff * ffffffff = 80000001
div:7fffffff / ffffffff = 80000001
mul:80000001 * ffffffff = 7fffffff
div:80000001 / ffffffff = 7fffffff
mul:80000000 * ffffffff = 80000000
div:80000000 / ffffffff = 80000000
mul:7fffffff * 00000000 = 00000000
div:7fffffff / 00000000 = ffffffff

当然ながら、動作が定義されている演算は、どのアーキテクチャでも同じ結果です。当たり前ですね。

  • INT_MAX * (-1) = INT_MIN + 1
  • INT_MAX / (-1) = INT_MIN + 1
  • (INT_MIN + 1) * (-1) = INT_MAX
  • (INT_MIN + 1) / (-1) = INT_MAX
  • INT_MAX * 0 = 0

一方で動作が未定義の演算は、かなり挙動が変わります。

  • INT_MIN * (-1) = INT_MIN
  • INT_MIN / (-1) = クラッシュ (x86_64), INT_MIN (AArch64, RV64GC)
  • INT_MAX / 0 = クラッシュ (x86_64), 0 (AArch64), -1 (RV64GC)

個性が出ますね。

x86 の除算命令の奇妙な仕様

先ほどの例で x86 上で INT_MIN / (-1) の除算がクラッシュする原因は idiv 命令の仕様です。

Intel の命令仕様書(Intel Architectures Software Developer Manual: Vol 2)の IDIV - Signed Divide のページを見ると、保護モード例外 #DE が発生する条件として、

  • ソース・オペランド(除数)が 0 である場合
  • デスティネーションに対して符号付きの結果(商)が大きすぎる場合

この 2条件が挙げられています。INT_MIN / (-1) は結果が 32bit で表現できないため、後者に引っ掛かるわけです。

異常な演算に対して例外を発生させる設計思想なら分かりますが、乗算命令は異常な結果でも素通しなのに、除算命令は異常な結果だと例外発生します。片手落ちの不思議な仕様です。変なの……。

[編集者: すずき]
[更新: 2019年 7月 19日 00:41]
link 編集する

コメント一覧

  • hdk 
    x86の除算例外は8086/8088の頃からありました。乗算については、8ビット同士を掛けて16ビットを出すか、16ビット同士を掛けて32ビットを出すかしかなかったので、異常な結果というのがそもそもなかったんですよね。(下位ビットだけ使うのはCコンパイラーの勝手なので。) 今はIMUL命令のオペランドが増えて同一ビット幅の答えを返す命令もありますが、例外がないのは名残か、あるいは、同じく例外がないシフトと足し算の命令の代わりに使われることを意図したかでしょうか。想像ですが。 
    (2019年07月20日 00:23:50)
  • すずき 
    MUL については、結果が倍のビット幅になっていたからという理屈もわかるんですが、加算、減算はオーバーフローしたらOFをセットするだけなのに、「除算だけ」オーバーフローで例外を発生させるのは、変な仕様です。。。 
    (2019年07月20日 10:56:45)
  • すずき 
    OFをセットして例外を出したければINTOでオーバーフロー例外(#OF)を発生させるのがx86の仕様に思えるのですが、除算だけ特別というかわざわざ除算例外(#DE)なんて用意しているのも不思議です……。 
    (2019年07月20日 11:02:10)
  • hdk 
    加算減算は符号のありなしどちらも命令が同じですから、オーバーフローで即例外ってわけにはいかないですね。まぁ確かに除算も不正な解を出してフラグを立てる実装もありそうですが、除算回路が止まっちゃうのかなーという気も... ちなみにAAM命令でも0を指定すれば#DE発生させられます。 
    (2019年07月24日 07:25:16)
  • すずき 
    AAM(ASCII Adjust AX After Multiply)って使ったことないですが、乗算系の命令でも #DE 発生するんですね。
    一貫性が無い感じが x86 らしいといえばらしいです。。。 
    (2019年07月24日 22:22:19)
  • hdk 
    あっ、AAMはマニュアルのオペレーションを見ていただくとわかりますが中身は除算命令ですので、乗算系とは言えない気がします。DIV命令と違って8ビットを8ビットで割って8ビットの商と余りを出すので(全部符号なし整数)、0除算以外に例外が発生する条件はありません。 
    (2019年07月25日 00:02:22)
open/close この記事にコメントする



link permalink

埼玉を洪水から守る

首都圏外郭放水路 庄和排水機場(埼玉県春日部市)の調圧水槽と第一立坑(たてこう)の見学に行きました。


庄和排水機場の外観

首都圏外郭放水路とは、洪水多発地域の中川流域(埼玉県の東部)を洪水から保護するため、中川、綾瀬川といった中小河川の水を地下経由で引き込み、ポンプで引き上げて江戸川に放流する仕組みです。


首都圏外郭放水路の概要

ちなみに国の施設でして、管轄は国土交通省(サイトへのリンク)です。

見学

見学コースの一つである、調圧水槽は、地下神殿との呼び名もあるほどで、広大な空間とたくさんの柱があります。

柱の役割がわかっていなかったのですが、係の方の説明によると、周りの地下水の浮力で調圧水槽が浮き上がってしまうので、重い天井と柱で、水槽を下に押しつけているそうです。


調圧水槽

第一立坑は高さ 70mの大迫力で、一番上の壁沿いに組まれた足場から下を見ることができます。私は高いところが苦手でして、非常に怖かったです。足が進まないし、変な汗が止まりません。

怖すぎて壁際にずっとしがみついていたため、写真を撮る余裕がありませんでした。一緒に行ったみなさまが高いところが平気なようで、写真をバシバシ撮っていましたので、一枚恵んでもらいました。


第一立坑(たてこう)

高いところ(立坑)はもう懲り懲りですが……、今回参加したコースとは別の見学コース(排水ポンプ室に入れる)もあるらしいので、別コースにもぜひ行ってみたいですね。

[編集者: すずき]
[更新: 2019年 8月 25日 23:50]
link 編集する

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link permalink

OpenVX on OpenCL

会社の人に OpenVX の別実装があることを教えてもらったので、試してみました。

以前、ソフトウェア実装の OpenVX ライブラリを動かしました(2018年 11月 14日の日記参照)が、AMD の OpenVX の実装(GitHub へのリンク)を使うと、GPU で OpenVX を動かすことができます。

AMD の OpenVX 実装ではありますが、OpenCL を使うので GPU は Radeon である必要はなく、Intel の GPU でも OK です。これが共通 API たる OpenCL の良いところですね。私は現状 Radeon を持っていませんので、Intel の内蔵 GPU で動かしてみようと思います。

動かし方

まず OpenVX ライブラリをビルドします。Debian であれば opencl-c-headers 辺りが必要になるはずです。また GPU ドライバとして Intel GPU ドライバの OSS 実装である beignet を使います。Debian であれば beignet-dev, beignet-opencl-icd 辺りのパッケージでインストールできます。

AMD OpenVX ライブラリのビルド
$ git clone https://github.com/GPUOpen-ProfessionalCompute-Libraries/amdovx-core
$ cd amdovx-core

$ mkdir build
$ cd build
$ cmake ../
$ make -j4

テストには前回も活躍した OpenVX アプリを使用します。OpenCV のバージョンは 3.2 です。もし古いバージョンの OpenCV を使っている場合は -lopencv_videoio オプションを外してください(おそらく「そのようなライブラリは存在しない」とエラーが出る)。

OpenVX サンプルアプリケーションのビルド
g++ solution_exercise1.cpp -Wall -I../include \
  -lopencv_video -lopencv_videoio -lopencv_highgui -lopencv_imgproc -lopencv_core \
  -lopenvx -L/path/to/amdovx-core/build/lib

前回とほぼ同じですので、さほど難しくないと思います。

GPU の実力

ビルドできましたので、実行……をする前に、vxProcessGraph の前後に時間計測のコードを入れておきます。

時間計測のパッチ

diff --git a/tutorial_exercises/solution_exercise1/solution_exercise1.cpp b/tutorial_exercises/solution_exercise1/solution_exercise1.cpp
index c7b8e21..ebc07e5 100644
--- a/tutorial_exercises/solution_exercise1/solution_exercise1.cpp
+++ b/tutorial_exercises/solution_exercise1/solution_exercise1.cpp
@@ -30,6 +30,8 @@
  *          Kari Pulli             <kari.pulli@gmail.com>
  */
 
+#include <sys/time.h>
+
 ////////
 // Include OpenCV wrapper for image capture and display.
 #include "opencv_camera_display.h"
@@ -368,6 +370,8 @@ int main( int argc, char * argv[] )
     // Process the video sequence frame by frame until the end of sequence or aborted.
     for( int frame_index = 0; !gui.AbortRequested(); frame_index++ )
     {
+        struct timeval st, ed, el;
+
         ////////********
         // Copy the input RGB frame from OpenCV to OpenVX.
         // Use vxAccessImagePatch and vxCommitImagePatch APIs (see "VX/vx_api.h").
@@ -407,8 +411,11 @@ int main( int argc, char * argv[] )
         //      if the frame_index == 0 (i.e., the first frame of the video
         //      sequence), otherwise, select the feature tracking graph.
         //   2. Use ERROR_CHECK_STATUS for error checking.
+        gettimeofday(&st, NULL);
         ERROR_CHECK_STATUS( vxProcessGraph( frame_index == 0 ? graphHarris : graphTrack ) );
-
+        gettimeofday(&ed, NULL);
+        timersub(&ed, &st, &el);
+        printf("ProcessGraph:%d.%06d[s]\n", (int)el.tv_sec, (int)el.tv_usec);
 
         ////////********
         // To mark the keypoints in display, you need to access the output

実行環境は下記のとおりです。

  • CPU: Pentium J4205/1.50GHz
  • Mem: DDR3L-1600 8GB x 2
  • GPU: Intel HD Graphics 505/250MHz(J4205 内蔵)

最初にソフトウェア版のライブラリを実行します。

OpenVX サンプルアプリケーション(ソフトウェア版 OpenVX)
$ LD_LIBRARY_PATH=/path/to/openvx1.1/out/LINUX/x86_64/release/ ./a.out

OK: FILE ../../tutorial_videos/PETS09-S1-L1-View001.avi 768x480
LOG: [ status = -1 ] Hello there!

ProcessGraph:0.254740[s]
ProcessGraph:0.183655[s]
ProcessGraph:0.181082[s]
ProcessGraph:0.180022[s]
ProcessGraph:0.182914[s]
ProcessGraph:0.180622[s]
...

最初のフレームは HarrisCorner による角検出、それ以降のフレームはトラッキングに要した時間です(そういう内容のデモです)。トラッキングに大体 180ms 程度、掛かっている様子がわかります。

次に内蔵 GPU で実行します。

OpenVX サンプルアプリケーション(GPU 版 OpenVX)
$ DISPLAY=:1 LD_LIBRARY_PATH=/path/to/amdovx-core/build/lib ./a.out

OK: FILE ../../tutorial_videos/PETS09-S1-L1-View001.avi 768x480
LOG: [ status = -1 ] Hello there!

LOG: [ status = 0 ] OK: OpenVX using GPU device#0 (Intel(R) HD Graphics Broxton 0) [OpenCL 2.0 beignet 1.3] [SvmCaps 0 0]

ProcessGraph:0.030192[s]
ProcessGraph:0.016439[s]
ProcessGraph:0.015872[s]
ProcessGraph:0.015629[s]
ProcessGraph:0.015629[s]
ProcessGraph:0.015679[s]
...

トラッキングに 16ms 程度しか掛かりません。正直言って GPU としてはローエンドの下の方ですが、J4205 の CPU 処理と比較すると圧倒的に速いです。GPU 恐るべしですね。

[編集者: すずき]
[更新: 2019年 7月 16日 02:26]
link 編集する

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link もっと前
   2019年 7月 18日 -
      2019年 7月 9日  
link もっと後

管理用メニュー

link 記事を新規作成

合計:  counter total
本日:  counter today

link About www.katsuster.net
RDF ファイル RSS 1.0
QR コード QR コード

最終更新: 10/13 23:20

カレンダー

<2019>
<<<07>>>
-123456
78910111213
14151617181920
21222324252627
28293031---

最近のコメント 5件

  • link 19年09月01日
    すずき 「私も正直びっくりです。間違って違う製品を...」
    (更新:09/04 23:39)
  • link 19年09月01日
    hdk 「車向けの製品の中でも、車載コンピューター...」
    (更新:09/02 23:20)
  • link 19年07月18日
    hdk 「あっ、AAMはマニュアルのオペレーション...」
    (更新:07/25 00:02)
  • link 19年07月18日
    すずき 「AAM(ASCII Adjust AX ...」
    (更新:07/24 22:22)
  • link 19年07月18日
    hdk 「加算減算は符号のありなしどちらも命令が同...」
    (更新:07/24 07:25)

最近の記事 3件

link もっとみる
  • link 19年10月06日
    すずき 「[RISC-V のバイナリダンプを逆アセンブルする] 相変わらず空...」
    (更新:10/13 23:20)
  • link 19年10月12日
    すずき 「[台風 19号] あの台風 15号(Faxai)(2019年 9月...」
    (更新:10/13 22:04)
  • link 19年09月08日
    すずき 「[台風 15号] 超強力な台風 15号(Faxai)が来るというこ...」
    (更新:10/13 22:03)

こんてんつ

open/close wiki
open/close Java API

過去の日記

open/close 2002年
open/close 2003年
open/close 2004年
open/close 2005年
open/close 2006年
open/close 2007年
open/close 2008年
open/close 2009年
open/close 2010年
open/close 2011年
open/close 2012年
open/close 2013年
open/close 2014年
open/close 2015年
open/close 2016年
open/close 2017年
open/close 2018年
open/close 2019年
open/close 過去日記について

その他の情報

open/close アクセス統計
open/close サーバ一覧
open/close サイトの情報