dpboxをOpenBSD対応してみたのでGitHubに上げてみたんですが、現状はgmakeが通ってバイナリが得られるだけで、問題点は山積みです。

一応、OpenBSD-6.3/amd64で使われるgcc-4.2(gcc), gcc-4.9.4(egcc), clang-5.0.1(cc)で、多少は警告が減ったかな程度には手を入れています（これ以上減らすにはちょっと手がかかるので今のところは放置）。

gmake installによるインストールへの対応は未着手です。NetBSDのpkgsrcだと/usr/pkg/{bin,libexec,sbin,share}にファイルを置きますが、アンインストールの手間を考えると、当面は/usr/local/dpboxに全てを放り込む方が良さそうに思えます。

…それ以前に、dpboxってxfbbみたいにFWD-BBS用のホストプログラムという認識で良いんですよね？（ぉぃ）60.25kg(10:30)

direwolfをOpenBSD対応してみたのでpull request投げてみたんですが（まだ採択されてないけど）、OSSだとうまく動かないのでPortAudio経由でsndioを叩くようにしています。

で、PortAudioからどういう風にOpenBSDのオーディオデバイスが見えてるのかなーというのが気になったので、こんなコードを書いて実行したら、こう。VMware Playerに突っ込んであるDebian9だとこんな感じ。

なんとなく、PortAudio使わずにsndioネイティブで動くコードを書かないと駄目なんじゃないかなーという気がしているのですが…どうしましょうかね。59.10kg(22:25)

09-Jan-2019補足：NetBSD-8の状況を調べる必要があったので、その結果も置いときます。コードのコメントに、NetBSDでのビルド方法・実行方法も追加しています。

Intel Atom N270を載せたWindows XP時代のNetBook、こいつでdirewolfべんちまーくをしてみます。乱暴にまとめると、こんな感じ（Cortex-A7/A8は1008MHzでの話）

• NEON/SSEありの場合、Cortex-A8は1333MHzのAtomに僅かに劣り、Cortex-A7は1066〜1333MHzの間くらい
• NEON/SSEなしでVFP/FPUのみの場合、Cortex-A8ではAtomにはまったく勝てず、Cortex-A7なら1333MHzのAtomには勝てるが1600MHzには僅かに負ける
• AtomではFPU無しの測定は不可（Debian/armhfと同様に、OpenBSD/i386ではFPUの使用が前提となっている）、よってVFP/FPU無しでの比較はできない

以下、数字の羅列。

• Atom N270 OpenBSD-6.3 clang-5.0.1 (@1600MHz)

• Atom N270 OpenBSD-6.3 clang-5.0.1 (@1333MHz)

• Atom N270 OpenBSD-6.3 clang-5.0.1 (@1066MHz)

• Atom N270 OpenBSD-6.3 clang-5.0.1 (@800MHz)

イマドキのPC並みとは決して言えないものの、ある程度の性能があるボードが安く買えるというのは非常に恵まれた時代になったものだなあと月並みな感想を書いて、このシリーズは締めることにします。60.60kg(14:20)

もはやpcDuinoとは全然関係ないOrange Pi PC(Allwinner A20, Cortex-A8 + VFPv4 + NEON)でOpenBSD-6.3/armv7を動かして、direwolfべんちまーくを。

pcDuinoやBanana Piと異なり、Orange Pi PCではU-Boot起動時にCPUの動作クロックが表示されないのでU-bootのメモリダンプを使ってCCUレジスタを見てみました。

• CPUX_AXI_CFG_REG(0x01c20050)=0x00200102→CPUはPLL_CPUXの出力を使用
• PLL_CPUX_CTRL_REG(0x01c20000)=0x90001b21→P=1, N=28, K=3, M=2
• PLL Output=(24MHz×N×K)/(M×P)→(24×28×3)/(2×1)=1008MHz

念のためpcDuinoのCCMレジスタも見てみます。

• CPU_AHB_APB0_CFG_REG(0x01c20054)=0x00020112→CPUはPLL1の出力を使用
• PLL1_CFG_REG(0x01c20000)=0xa1005510→P=1, N=21, K=2, M=1
• PLL Output=(24MHz×N×K)/(M×P)→(24×21×2)/(1×1)=1008MHz

Orange Pi PCとpcDuinoが同じ1008MHzのクロックで動いているようなので、今までのベンチマークからCortex-A7とCortex-A8のシングルコア動作におけるパフォーマンスの比較ができそうです。

二台目のI-O DATAEX-LD2071TBが届いたので、早速OpenBSD機に繋げて使っています（置き場所はどうにかなりました）。既にWindows機に繋げているのと同じモニタのはずなのに何故か慣れずに目が疲れるのですが、何故なんでしょう…？

30-Jun-2002から使用していたSONY SDM-M61には、長い間本当にお世話になりました。ありがとうございます。59.70kg(21:30)

ひたすらベンチマークです。pcDuino(Allwinner A10, Cortex-A8@1008MHz + VFPv3 + NEON)でOpenBSD-6.3/armv7、clang-5.0.1だとこんな感じ。-mfloat-abi=softfpを忘れると浮動小数点演算はソフトウェアでやることになるので恐ろしい結果になります。

Banana Pi(Allwinner A20, Cortex-A7@912MHz + VFPv4 + NEON)でOpenBSD-6.3/armv7だと、こう。こちらも-ffast-math -mfpu=neonだと-mfloat-abi=softfpの指定が無いので浮動小数点演算はソフトウェアで以下略。

pcDuinoでDebian9.4(armhf)のベンチマークは前回も行っていますが、今回はThumb-2ではなくARMバイナリで再度ベンチマークしてみました。armhfというだけあって、-mfloat-abi=hard以外の選択肢は選べないようになっています（つまり、VFP/NEON無しの性能が分からない）。

結果を見る限りでは、なんとなくこんな感じに見えます。

• Cortex-A7のVFPは速い
• NEONの効果は大きい
• （direwolfの場合は）-mfpuでどのVFPを指定してもあまり変わらない
• -mfloat-abiはsoftfpよりhardの方が速いと言われているが、分からない
• -mthumbより-marmの方が速いと言われているが、Thumb-2だとARMとの差は非常に小さい

Cortex-A7とCortex-A8の整数演算性能がどの程度違うのかは気になるのですが、Cortex-A7の場合はマルチコアで回せるので気にする意味が無いのかもしれません（とはいえ、現状のOpenBSD/armv7はコア一つしか使わないので多少は気になる）。

最近のweb pageは横幅を1024pxで表示することを前提にしているのが多いのか、SXGAのモニタ（相変わらずSONY SDM-M61）だと非常に手狭です。今回のベンチマーク祭りで大量のコンソールを開くのも非常に大変だったので、I-O DATA EX-LD2071TBをもう一台発注しました。細かすぎて使うのはしんどくまた二台も置く場所が無い気もしますが、どうにかするしかありません…58.60kg(21:25)

例によってdistributed.net clientを動かしてベンチマークを取ろうとしていたのですが…armelとarm64はあるけどarmhfが無いので試しようがないという。比較用に取ったpcDuino以外のマシンでのベンチマークを晒してもなあ。

• Athlon64 3000+マシンでamd64/elf/uclibc
• Athlon64 3000+マシンでx86/elf/uclibc
• EdgeRouter LITE-3でmips/elf

という訳で、pcDuinoでdirewolfべんちまーくをやってみます。コンパイラはDebian9.4のデフォルト、gcc-6.3.0です。

• -ffast-mathを指定する時点で、-funsafe-math-optimizationsは指定されたものとみなされる
• Debian/armhfはThumb-2とVFPv3-D16がデフォルトのため、ARMバイナリを生成する場合は-marmの指定が必要

プログラムの性格上、NEONが必須なのはそういうものとして…VFP関連のオプションがあってもなくてもあんまり速度が変わらないのは、省略時に-mfpu=vfpv3-d16が効いている可能性があります。とはいえ、Makefile.linuxに記されているRaspberry Pi (ARMv6 + VFP2)の結果の倍程度の時間がかかっているのは何かを大きく間違えているような気がするのですが…

折角なので、以前作ったOpenBSD向けのdiffを少しメンテナンスしてみました。とりあえずベンチマークが取れる程度のバイナリが得られる、辺りを目標にしているので実際にTNCとして運用することは二の次です。運用できるようにしたいけど。59.20kg(09:40)

04-May-2018補足：direwolfのdiff、OpenBSD/armv7でNEON/VFP命令が有効になるよう修正しました。旧版はこちら。

16-May-2018補足：direwolfのdiff、色々直しています。一部のファイルのインストール先が/usr/shareとなっているのを/usr/local/shareとし、OSSだと動作がおかしいのでPortAudioを使ってsndio経由にしています。これで、AGWTerminalのActions→Connectで音が鳴るところまでは確認しています（受信動作については未テストです）。旧版はこちら。