SAMD21 で各種ソフトを動かしてみたが性能不足で評価終了

前回は外部デバイスに対してでしたが内部の話です.

Wavpack Tiny Decoder (CPUの性能不足)

tiny decoder は Makefile を調整して ARM 用にしたぐらいですが、リンクも問題なく、動かすことができました.

ソースツリーに含まれている ARM 用のアセンブラソースは使えませんでした. これ ARM7TDMI 用で Cortex M0 用ではないし、自分は ARM のアセンブラが読めないのですすめられないです.

内部のタイマーを利用しながら 75 compact disc frames (=1秒間) を decode したところ 2.9 秒もかかりました. 1 秒間のデータを展開するのに 3 秒間かかるのでは使えません. 実は Cortex M0+ 48MHz ではだめかなと予想しててその通りでした.

一応なんですが hybrid mode で作ったデータでは 0.75 秒間程度の計測値がでてますので、ファイルシステムなしとか他に重い割り込み処理を入れないとか条件付きでは一応使えるという値です. アセンブラのソースをいれても4倍以上の処理速度がでるとは思えません.

LZ4 (decode できてない)

PC 側で encode するのはとても簡単だったのですが、decode のまともな C のコードを用意できてません.

LZ4 のサイトに多種の decoder への言及がありますが、ARM Cortex assembly decoder はリンクはできたけどちゃんと動きませんでした. C decoder (tiny) はどうも 80386 依存のコードになっていて実用的ではないです. LZ4 の公式の decoder の C ソースはちょっとみましたが、OS がある前提でかなり safety に作られてて MCU 用には各種手続きを削る手間があり、やってません.

LZF (実用可能)

こちらは無難な C の関数で fall-through の Warning を止めれば、コンパイル、リンク、Decode すべてできました.

計測方法は手抜きで 0x800 bytes (1/75秒)の data を decode して 75 倍した時間で 0.094 秒でした.

考察

CPU の性能不足なので SAMD21 での評価はこれで終了とし、SAMD51 など Cortex M4 あたりで評価をやり直す必要があります.

LZ4 は top page がぱっとみ素晴らしいんですが、 decode できないとか、アセンブラじゃ PC 上のテスト用環境でも動かせないとかで悪い方に予想外でした. msys で pacman からとってこれるとか PC 向けのパッケージ管理はよかったです.

LZF は LZ4 の性能比較対象にもありますけど、こっちのほうがいいかなと今のところは思います.

そもそも data sector を圧縮する意義はあるのかという話もあります.