思考のサルベージ(その14)

各工程で心がけたい思想を掘り起こしてみる

処理性能を求められるシステムでは、CPUを最大限有効に稼働させなければなりません。「空いた時間の上手な使い方」について考えてみます。

HWサポート

複数個のデータを元に複雑な演算をする必要があるとします。ソフトウェアによる演算では処理時間がかかりすぎてしまうので、この演算専用のハードウェア.Aを搭載してもいました。仕様はざっくり次のような感じです。

• データ設定レジスタにデータを設定する
• 起動レジスタに1を書き込むことで演算を開始する
• 演算が終了すると終了レジスタに1が書き込まれる。
• 終了レジスタに1を書き込むと同時に、結果レジスタに演算結果が書き込まれる。

この手のHW.Aにアクセスするドライバとしては以下のようなものも考えられます。

• 1.データ設定からHW起動までを行うstart関数
• 2.演算終了レジスタをポーリングし、演算が終了したら演算結果を返すwait関数
• 3.１と2をパッキングした、startend関数

3のstartendようなドライバであれば、HW.Aを使うSWでは、ドライバ一つ呼ぶだけで演算結果を使って次の処理に進むことができます。単純明快な処理となるので、bugを埋め込むリスクも小さくなります。

空き時間

SWによる演算より速いとはいえ、HW.Aの演算にも時間はかかります。そこで、演算結果を取得した後に続く処理に目をつけてみます。当然、演算結果が無ければ実行できない処理があります。しかし、HW.Aから取得できる演算結果の他に、後続処理で必要なデータがあるならば、HW.Aの演算終了を待つ間に他のデータの収集する処理を行っておけます。

[　　　　　　startend　　　　　 ]→[他のデータ収集]→[後続処理]

[start]→[他のデータ収集]→[wait]→[後続処理]

[他のデータ収集]がHW.Aの演算時間に収まればその分の処理時間を削減することができます。

できることできないこと

上記では単純化なモデルケースで説明しています。実際にシステムで稼働するSWはもっと複雑な実装になっているでしょうが、同様のやり方で、HWの処理時間の裏で他の処理を実行させることは可能でしょう。 ただし、注意も必要です。例えばHW.A起動中の裏で実行したい処理が別のHWを用いるような処理であれば、HW同士の同時起動に制約がないか確認する必要があります。同時起動自体は可能でもHW同士が同一メモリにアクセスするようなケースではbus接続の影響でアクセス競合が起こる可能性もあります。こうなるとHWを用いても性能を引き出せないといったことになってしまいます。こうなっては折角のHWサポートも電力を使うだけで、なんの効果も生んでくれません。

何か掘り起こせた？

空き時間を有効に使うには、HWの仕様・特性をきっちり把握する必要があります。

• 使用するHW、アクセスするメモリ等を考慮する必要があり
• 設計段階でやれることやれないことを整理しておく。

おしまい

HWサポートを一つ搭載するにもそれだけのコストをかけるということ。本当にそのサポートが必要かも含め、どうすれば性能を引き出せるかをきっちりと検討したいですね。

Easy-RSA による公開鍵基盤（PKI）

はじめに

いわゆるオレオレ的な証明書の発行のためにプライベートな認証局（CA）を構築する、なんて経験は誰もがあるはず。自分も今までは CA スクリプトなど使いながらわりと苦労して構築してたんですが Easy-RSA なるシェルで簡単に構築できることが分かったので備忘録として残しておきます。

前提:

• Easy-RSA 3.0.8
• Ubuntu 20.04.2 LTS

Fedora34でデフォルトIMEがAnthyになるですって！？？ 〜OSSかな漢字変換再考〜

え、Anthy・・・！？！？

昨年末、LinuxディストリビューションのFedora界隈でこんなディスカッションなるものがあったそうです。。。

fedoraproject.org

中身はタイトルのとおりなのですが、、、

Fedora次期バージョン（＝Fedora34）からデフォルトIMEがIBus-Anthyになる！！

とのこと。

趣味でかな漢字変換を自作している著者としては、「何事！？」と思われるお話だったのですが、よく考えると「あ〜なるほど」とある程度は納得のできるお話でした。（注：全てに納得したわけではありませんが

というわけで今回は、OSSのかな漢字変換について振り返りをしてみようと思います。

本日、話題となるかな漢字変換はこちら。

• Anthy
• Mozc
• libkkc

それでは、行ってみます！

FIRフィルタのフレーム処理

信号処理ではそのアルゴリズムによってフレーム単位で処理している場合が多いです。 フーリエ変換を行う場合は、そのサイズ（点数）でフレーム化されたりします。 このようなケースを考えたとき、フィルタもそのフレームサイズに適した形が都合が良く、高速化（最適化）に関しても利点が多いです。

思考のサルベージ(その13)

各工程で心がけたい思想を掘り起こしてみる

年末ですね。ということで開発の最後に片づける「ドキュメント整理」について考えてみます。

ドキュメント整理とは？

ドキュメント整理とは、要求仕様書とそれに対する上流工程から下流工程の設計書、試験仕様書など複数のドキュメントを紐づけて、一つの体系的なドキュメントとして完成させることですね。

どのように要求仕様、設計書を紐づけていくかはプロジェクト立ち上げの段階から規定されていることがほとんどなので、要求から設計書・試験仕様書作成し、ルールに従ってドキュメントを登録していけば、体系化させることにはそれほど手間はかからないはずです。

ルールでよくあるのは、各要求項目ごとにナンバリングして、その要求に対応するドキュメントやコードのコメントにもナンバーを記載していく、なんてのをよく聞きますね。設計仕様に記載される設計がどの要求に対応したもで、そのための試験がどの試験仕様書で表現されているか追跡できることが重要です。要求仕様、各設計書、試験仕様書が体系的に管理されていれば、機能漏れ、試験漏れを防ぐことができます。

設計変更

設計・コーディングが終わり、試験工程にはいると当然不具合が検出され、コード修正を繰り返し、製品の品質を上げていくことになります。大きな設計変更がなければドキュメント整理なんて楽なもんです。

ただ、途中で要求が追加されたり当初の機能設計ではもともとの要求にも対応できていない、なんてことも発生します。逐次設計書の修正・コード修正と段取りを踏めればよいのですが、大抵は設計追加・変更の簡単な資料を作っておいて、正式なドキュメントの修正は後回しになってしまいますね。

最新化

こうなると、ただのドキュメント整理に、設計仕様書・試験仕様書の最新化というひと手間が入ります。変更箇所が少なければそれほど辛くはないですが、不思議なもので変更が入る機能には山ほど変更がはいるんですよね。 ただし、ここでしっかりと最新化をしておけば設計資料は後継機開発の重要な財産となります。ここは覚悟を決めてしっかりと資料の最新化をしておきたいところです。

何か掘り起こせた？

• 体系的にドキュメント整理されていれば、実装漏れ、試験漏れを防ぐことができる
• 手間暇かけて最新化をしておけば、システムの財産となる。

逆に、ここができていないとせっかくの財産がいまいち役に立たないなんてことになります。流用元の設計書とコードを見比べたら、なんか違うことやってる、みたいなことも時々ありますね。

おしまい

他のメンバが後継機の初期検討に入っているのに自分だけまだドキュメント整理やってるなんてときは、なんとなくさみしくなります。

GPG キーのエクスポート/インポート

はじめに

過去の投稿「GitHub の Verified マーク」の中で GPG を使用しました。マシンの買い替えにあたり、手っ取り早く GPG キーを移行することにしたので備忘のためこの手順を残しておきます。

移行は、

1. 古いマシンで GPG キー、GPG 署名キーのエクスポート
2. 新しいマシンで GPG キー、GPG 署名キーのインポート
3. 新しいマシンで GPG キーの所有者信頼を設定する

の手順で進めます。

Audacity『ノイズ除去』の周波数特性

「Audacityのノイズ除去を検証してみる」では、AudacityのNoise Reductionが周波数を分析しているのならば、特定の周波数をノイズとした時、その周波数が消えるか？という観点で調べてみました。周波数特性についてもう少し検証してみます。