コグノスケ

OpenCLのOSS実装poclを調べる その3 - デバイス数の取得処理

目次: OpenCL

独自アクセラレータのテンプレート実装pocl/lib/CL/devices/accelはデバイスタイプがCUSTOMになっているのが最大の難関ですが、その他にも色々問題があります。

最初に遭遇する問題はデバイス数を取得する処理のエラー処理が間違っていることです。現状のコードだとちょっと特殊な環境変数を渡さないと動きません。

// pocl/lib/CL/devices/devices.c

static unsigned device_count[POCL_NUM_DEVICE_TYPES];

...

cl_int
pocl_init_devices ()
{

...


  /* Init operations */
  for (i = 0; i < POCL_NUM_DEVICE_TYPES; ++i)
    {

...

      /* Probe and add the result to the number of probed devices */
      assert(pocl_device_ops[i].probe);
      device_count[i] = pocl_device_ops[i].probe(&pocl_device_ops[i]);    //★デバイス数を取得する★
      pocl_num_devices += device_count[i];
    }

...

  dev_index = 0;
  /* Init infos for each probed devices */
  for (i = 0; i < POCL_NUM_DEVICE_TYPES; ++i)
    {
      if (pocl_devices_init_ops[i] == NULL)
        continue;
      str_toupper (dev_name, pocl_device_ops[i].device_name);
      assert(pocl_device_ops[i].init);
      for (j = 0; j < device_count[i]; ++j)    //★デバイス数42億と誤解したまま処理しようとしてクラッシュする★
        {


// pocl/lib/CL/devices/accel/accel.cc

unsigned int pocl_accel_probe(struct pocl_device_ops *ops) {
  //★POCL_DEVICESという環境変数が見つからないとき、-1というエラー値を返す★
  //★本来エラー値である -1だが、デバイス数として解釈され42億になってしまう★
  int env_count = pocl_device_get_env_count(ops->device_name);
  return env_count;
}


// pocl/lib/CL/devices/devices.c

/**
 * Get the number of specified devices from environment
 */
int pocl_device_get_env_count(const char *dev_type)
{
  const char *dev_env = getenv(POCL_DEVICES_ENV);
  char *ptr, *saveptr = NULL, *tofree, *token;
  unsigned int dev_count = 0;
  if (dev_env == NULL)
    {
      return -1;    //★ここにくる★
    }
  ptr = tofree = strdup(dev_env);
  while ((token = strtok_r (ptr, " ", &saveptr)) != NULL)
    {
      if(strcmp(token, dev_type) == 0)
        dev_count++;
      ptr = NULL;
    }
  POCL_MEM_FREE(tofree);

  return dev_count;
}

このような実装になっておりaccelのデバイス数が42億（！）と解釈されてしまい、42億回デバイスを列挙しようとしてクラッシュします。バグのような気がしますけど、サンプル実装ですのであまり文句を言っても仕方ありません。

環境変数POCL_DEVICES="pthread -1 CUDA -1 accel 1" のようにデバイス数を明示的に渡せば回避可能です。最終的にはpocl_accel_probe() が正しくデバイス数を返すような実装を追加する必要があるでしょうが、この場は環境変数で切り抜けます。

OpenCLのOSS実装poclを調べる その2 - 独自アクセラレータのテンプレート実装を眺める

目次: OpenCL

CPUでもGPUでもないデバイスでOpenCLを動かすとしたらどうしたら良いでしょうか？答えとしては、その1で紹介したとおり、CL_DEVICE_TYPE_ACCELERATORを実装すれば良いです。が、イチから作るのはとっても大変です。

poclのテンプレート実装

素晴らしいことにpoclにはテンプレートらしき実装がpocl/lib/CL/devices/accelに用意されています。やりたいこととは微妙に違うことが後々わかりますが、イチから作るよりははるかにマシです。このテンプレートを改造しましょう。

テンプレートの名前はaccelでいかにもアクセラレータに見えますが、デバイスタイプはCL_DEVICE_TYPE_ACCELERATORではなくCL_DEVICE_TYPE_CUSTOMです。CUSTOMは「コンパイルが可能なデバイス」ではなく、ビルトインカーネルのみを実行するデバイスです。ユーザー定義のカーネルを実行することは考えられていません。

ユーザー定義カーネルが実行できることが独自アクセラレータの売りですから、何とかしてCUSTOMではなくACCELERATORになるように実装を改造する必要があります。これはなんとも先が長そうです……。

memsetのベンチマーク（RISC-V 64, U74-MC編）

目次: ベンチマーク

（参考）コード一式はGitHubに置きました（GitHubへのリンク）

Linuxが動くRISC-Vボードを買ったので、RISC-V 64でもmemsetをやってみました。環境はボードがSiFive HiFive Unmatchedで、SoCがSiFive Freedom U740で、コアがU74-MCです。動作周波数は書いてないですね。OSはSiFive独自？環境のFreedom USDKです。メモリはDDR4-2400のようです（Schematics hifive-unmatched-schematics-v3.pdfより）。

特徴的な点は、

• glibc C実装が最速
• アセンブラ実装がない（O2のglibc C実装と同じ性能）

あと個人的に残念だった点としては、U74コアの速度です。前世代のHiFive Unleashedに搭載されていたU54コアはCortex-A53の足下にも及びませんでした（2019年5月27日の日記参照）。

U74はCortex-A72レベルとまでは言いませんが、Cortex-A53は超えてくると期待していましたが、少なくともmemsetに関しては負けています。半分くらいの速度しか出ていません……。

gcc -O3 -fno-builtinの測定結果（SiFive U74-MC編）

gcc -O2 -fno-builtinの測定結果（SiFive U74-MC編）

RISC-V 64 CPU第2号が我が家に来た

目次: RISC-V

SiFiveのHiFive Unmatchedを購入しました。現状、世界最速のLinuxが動作するRISC-V 64bit SoC とのことです。

ボードにはSDカードが付属しておりSiFive独自環境のFreedom USDKがインストールされています。ボード上にはUSB接続のシリアル端子があり、電源を入れればLinuxが起動し、ユーザroot、パスワードsifiveでログインできるようになっています。

ぱっと見はPCと同じmini-ITXマザーボードですけど、バックパネルを見るとSDカードの差し込み口、USBシリアル用のmicroB端子が出ていて、どちらかといえばSBC（シングルボードコンピュータ）です。PCっぽさがありません。

HiFive Unmatchedのバックパネル

本当はグラフィックカードを装着してGUIを使うべきですが、昨今のグラフィックカード品薄＆異常な値上がりのおかげで全く買う気が起きないので、しばらくシリアルコンソールで使おうと思います。

インストールされているカーネルは、
Linux unmatched 5.11.10 #1 SMP Wed Apr 7 17:37:34 UTC 2021 riscv64 riscv64 riscv64 GNU/Linux
でした。5.11はStableカーネルではあるものの、既にEOLです。まあ、開発用ボードだしこんなもんか。

購入時の同じ罠

Crowd Supplyから購入しました。本体 $679, 消費税が7,100円、合計で7万円くらいでした。HiFive Unleashedほどではないにせよ、SBCにしては良いお値段です。

UPSが米国→日本まで持ってきて、国内はクロネコヤマトが運びます。受け取りの際に、消費税を着払いでクロネコに払う必要があります。私は消費税のことを忘れていて、何だこの金は？？と混乱しました。Unleashedのときと全く同じでした。海外からものを買うことがほとんどなくて、消費税の存在をすぐ忘れちゃうんですよね……。

TRONが世界標準？？

Quoraのとある項目なぜTRON OSが「非常に優れていたが外圧で潰された」とか「組み込みで世界標準OSだ」とかいう誇張された伝説をいまだに信じている人が大勢いるのですか？ - Quora が話題になっていました。そんな話を信じている人が居るんですね。TRONが世界標準……私の知らない世界線でTRONが覇権を獲ったのでしょうか……。

松下電器（おそらく日本一のTRON推しの会社でした）に居た自分すら、そんなこと思ったことありませんでした。

その松下電器でさえBTRONはもちろんiTRONすらギブアップです。いまやレコーダーやテレビのOSはLinux/BSDカーネルを採用しています。iTRONアプリも残ってはいますが、過去資産の作り直しは面倒＆旨味がないのが理由だったと思います。

メモ: 技術系の話はFacebookから転記しておくことにした。

ベンチマーク - まとめリンク

目次: ベンチマーク

一覧が欲しくなったので作りました。

• 最速のyes
• 不安定なyes
• yesの高速化（パイプ限定）
• C言語でSEGV
• ELFバイナリでSEGVその1 - 92バイト
• ELFバイナリでSEGVその2 - 64バイト
• デノーマルフラッシュ
• デノーマルフラッシュの速度改善効果
• マイクロアーキとシングルスレッド性能
• FizzBuzzを速くする1（自作アルゴリズム）
• FizzBuzzを速くする2（高速アルゴリズムの紹介）
• FizzBuzzを速くする3（CPUを変えてみよう）
• FizzBuzzを速くする4（うまくいかないこともある）
• FizzBuzzを速くする5（SIMD最適化の紹介）
• FizzBuzzを速くする6（1桁落とし）
• FizzBuzzを速くする7（コンパイラによる違い）
• SIMDを使ったお手軽最適化 - その1
• SIMDを使ったお手軽最適化 - その2
• 100万回のHello, World!
• 100万回のHello, World! - バイナリサイズを削って遊ぼう
• 100万回のHello, World! - バイナリサイズを削って遊ぼう、究極編その1
• 100万回のHello, World! - バイナリサイズを削って遊ぼう、究極編その2

メモリクリアでおなじみmemset()関数の自作。

• memsetのベンチマーク（x86_64, Ryzen 7 2700編）
• memsetのベンチマーク（AArch64, Cortex-A72編）
• memsetのベンチマーク（AArch64, Cortex-A53編）
• memsetのベンチマーク（RISC-V 64, U74-MC編）
• muslのmemset関数
• memsetに一番効く最適化
• ぼくの考えた最強のmemset
• バイトをコピーするSIMD命令
• glibcのmemsetのクセ
• glibcのmemsetは強かった

Nクイーン問題の自作。

• C言語でNクイーン問題
• C言語でNクイーン問題、一意解
• C言語でNクイーン問題、高速化
• JavaScriptでNクイーン問題
• スクリプト言語始めました（PythonとRubyでNクイーン問題）
• インタプリタon Java VM（PythonとRubyでNクイーン問題）
• JavaScriptでNクイーン問題、その2