航海日誌 Starlog

ネットをググるとMac OS X 10.4.11/PowerPCでMaximaを使うのはちょっとめんどうみたいな感じがしたのだが、実はこの環境で動くバージョンのSage(バージョンが少し古いが)をダウンロードしてくると、Sage上でMaximaを使うことができる。

Sageの標準環境であるWebブラウザ上での操作では遅くてやっていられないが、メニューバーのSageのアイコンからコンソール版のMaximaを呼び出すと速度は快適。

clamavのバージョンが0.97.8から0.98に上がった。Mountain Lionの入ったMacBook Proでは問題なく0.98をビルドできたが、Tigerの入ったPowerMac G3ではエラーとなる。

clamavをTiger/PowerPCでビルドする時は、Tigerのgcc4.0のバグを回避するためにgcc3.3を使ってコンパイルしている。今回もgcc3.3を指定しているので、gcc4.0のバグ絡みではない。

makeで次のエラーが出ている。
Making all in clamd
  CC     thrmgr.o
In file included from thrmgr.c:32:
../shared/output.h:44: error: parse error before "logg_size"
../shared/output.h:44: warning: data definition has no type or storage class
make[2]: *** [thrmgr.o] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
となっている。

他の手はないかと思ってネットを検索すると、このページでLLVM 2.3を入れる必要があると書いてある。このページにはインストール方法も書いてあるのだが、うちのマシンだとLLVM 2.3のmakeでエラーが出る。少し前にこのマシンでMacportsを使ってgnumeric 1.12.xをインストールしようとした時もLLVMがビルドできずにインストールできなかった。

うちの環境固有の問題かもしれないが、とりあえずTiger/PowerPCでclamav 0.98はビルドできなかった。

LibreOffice 3.4.xのPowerPC版の日本語言語パックをMac OS X Tiger 10.4.11上でインストールしようとすると、インストーラが立ち上がりかけてすぐに終了してしまい、インストール出来ない。

ググッてみると、PowerPC版とTigerの組み合わせで発生するらしく、PowerPC + Leopardだと大丈夫らしい。LibreOffice本体はTigerでも問題なく動くので、インストーラの問題。

Tiger上で言語パックのインストーラを動作させる方法は今のところ見つけていない。言語パックのインストーラでコンテキストメニューでパッケージの内容を表示として、中のファイルをやはりパッケージの内容を表示したLibreOFfice内の同じ場所にコピーしていく。言語パック内には空のフォルダも多いので、コピーするファイルはそれほど多くない。

http://www.rpm-mozilla.org.uk/にFirefox 2.0.0.21の非公式版のPowerPC G4最適化版が上がっている。

適当に落とした言語パック(ja-JP-mac.xpi)のバージョンが2.0.0.22preだったけど、これでいちおう日本語のメニューになっている。

Altivec最適化LAME 3.98の速度を比べてみた。変換元ファイルはAIFFファイルでサンプルレート32kHz, 108秒, カンテレの演奏。変換オプションは-V4でフレーム数は3091だった。

比較したのはAltivec最適化版LAME 3.98 2008/7/13版で、コンパイラがgcc3, gcc4, gcc4.2.1のもの。マシンは500 MHzのPowerPC 7410を載せたPowerMac G3 266DT（いわゆるベージュG3）、Panther。比較用に、Windows XPでrarewaresから落としたものも測ってみた。なお、rarewaresにあるMac OS X用バイナリは10.4以降対応のようで、実行しようとすると

dyld: ./lame can't open library: /usr/lib/libncurses.5.4.dylib  (No such file or directory, errno = 2)
Trace/BPT trap

というエラーが出てしまう。したがって、10.3.9で使える唯一のLAME 3.98エンコーダかもしれない＞Altivec最適化版LAME

以下は、同じエンコードを5回行った時のplay/CPUの値。 Mac OS XもWindows XPもマルチタスクOSなので、LAMEコマンドがOSから貰うCPU timeはCPUの全ての時間ではないため、実際のエンコード時間は演奏時間をこの数値で割った値よりも長くなる。

先週から今週にかけていろいろなソフトがアップデートされた。

Camino 1.6.2（mozillaの公開用ディレクトリにはアップされているけど、公式ページの方の更新はまだかも）
Firefox 2.0.0.15
　CaminoもFirefoxもGecko 1.8.1.15に。

ClamAV 0.93.3
　0.93.2は公開されたとたん取り消しに。0.93.3は0.93.2にあったバグをフィックスしたもの。
うちではclamav-updateを使っているけど、そのままの設定では7/9の朝には自動アップデートされていなかった。7/9の夕方にこちらの記事を見てclamav-update.confのダウンロード元URLを修正したら、夜になって自動でアップデートされていた。

LAME binary for Mac OS X
7/4に3.98の正式版が出て、7/12にgcc 4.2.1でビルドされたものが追加された。3.98b8まではプロセッサ毎に別れたバイナリだったのだけど、正式版からはintelプロセッサにも対応したユニバーサルバイナリに。ファイルサイズが2.2 MBもあって、5種類(intel, G5, G4-744x/745x, G4-7400/7410, G3)のバイナリが全部入っているという事みたい。今までは400KBぐらいだったから。
この人のLAMEのすごいところは、単に各プロセッサの最適化フラグを付けてコンパイルしたなんて言う半端なものじゃなくて、サイトの記述を引用すると

* ベクトル化
      o FFTルーチンをベクトル化
      o MDCTルーチンをベクトル化
      o 心理音響解析ルーチンをベクトル化
      o 量子化ルーチンをベクトル化
      o 量子化ノイズ計算ルーチンをベクトル化
      o ハフマン符号化のためのビットカウントルーチンをベクトル化
      o PCM入力ルーチンをベクトル化
      o replaygain計算ルーチンをベクトル化
* アルゴリズムの変更
      o x3/4の計算に近似+ニュートン法を使用
      o Logの計算に近似多項式を使用
      o 量子化係数の計算に近似多項式を使用

というような高速化を行っている。ベクトル化はAltiVecやSSEのあるG4以降やCoreプロセッサで大幅な速度向上をもたらすのだけど、アルゴリズムの変更の方はベクトル演算器を持たないG3でも速度向上の効果がある。以前G3, G4, Pentium D等でLame 3.97の速度を比べた時にこの人のG3用バイナリの速度が妙に速いと思っていたのだけど、こういう秘密があったのね。

私が普段使うオプション(-V4あたり)だとgcc3版よりもgcc4版の方が速かったのだけど、gcc 4.2.1でビルドしたものがどの程度速いのか、後で比べてみよう。

という事で比べてみた。・・・gcc 4.2.1版は、Mac OS 10.3.9 Panther上では

dyld: ./lame can't open library: /usr/lib/libncurses.5.4.dylib  (No such file or directory, errno = 2)

というエラーが出て動かなかった。これは以前iTunes-LAME 2.0.9(34)に同梱されていたlameでも出たエラー。libncurses.5.4.dylibはTigerには含まれていてPantherには含まれていないファイル。10.4.x以上でないとだめなのね・・・。

2008/7/13 20:14追記
作者の方がgcc 4.2.1版もMac OS 10.3.9で起動できるように修正してくれました。感謝しつつダウンロードしてます。速度の計測は、また後日。

先日測ったエンコード速度は他のソフトが動いていたり、時間帯が異なるなど、条件が一定ではなかったので、今度は各種バージョンをまとめて測ってみた。各バージョンを順に実行し、CPU/playの値を記録。3回測って平均した。CPUはPowerPC 7410 500MHzで、使ったlameはG4 7400版、オプションは-V5 --vbr-new。ちなみに、処理時間をストップウォッチ等で測って曲の長さと比較して速度を求めると、この数値よりも悪い。これはlameが自分が使ったCPU時間で計算しているためだと思う。

この速度なら、速いだけが取り柄のiTunesのMP3エンコーダと変換速度でも十分勝負できそうだ。

tmkkさんがlame 3.98b8の5/3版をアップした。4/23版との違いは、大幅な高速化。4/23版や3.97ではG4で85%、G5では60%程度の高速化（対通常版比）だったのが、5/3版ではG4で85〜105%程度、Gで80〜95%程度の高速化だとか。

実際、同一のaiffファイルを3.97, 3.98b8 4/23, 3.98b8 5/3でエンコードしてみたら、以下のような処理速度になった（速度はlameが表示するplay/CPU）。いずれもtmkkさんのAltiVec最適化版。ノーマル版が手元に無いので同じデータで比較できないのだけど、以前測った記録だとAltiVec最適化版の3.97はノーマル版の1.65倍ぐらいの速度だった。CPUはPowerPC 7410 500MHz。

エンコード速度はオプションによって変わるので、これはあくまでも一例という事で。大雑把に言って、最新のものでは今まで使っていた3.97 2006/10/22版に比べて1.2〜1.3倍速くなったようだ。すごい。

2008/5/4追記
3.97も5/3版に更新されていた。これも記入。前の版に比べて1割ぐらい速くなった模様。

2008/5/7追記
5/6に3.97と3.98b8が更新されていたので追加。変換した曲は同一だけど、遅くなっている。今度はまとめて速度を比べてみよう。ついでに3回ぐらい測って平均を取って。　ということで、測り直した結果はこちら。

AltiVecに最適化されたLame 3.98beta8がtmkkさんのところにアップされていた。うちのはPowerPC 7410なので、G4(7400/7410)用のものをダウンロード。

私のマシンは自分のホームのライブラリフォルダのiTunes/ScriptsフォルダにiTunes-LAMEをインストールしてある。このiTunes-LAMEをCtrl+クリックして「パッケージの内容を表示」して開き、Contents/Resourcesに入っているlameと解凍したlameを置き換える。

gcc3でコンパイルしたものとgcc4でコンパイルしたものがあり、とりあえず1曲だけ-V5 --vbr-newでエンコードしたらgcc4の方が速かった。

ところで、iTunes-LAMEではこのlame 3.98b8を使うとエンコードの進行状況のプログレスバーや残り時間の表示がまともに働かなくなる。コマンドラインでlameを使うと時間表示まわりは3.97と一緒なのだけど・・・よくわからん。使えるからいいか (^^;)

AltiVec非対応なLAME3.96での速度比較でわかった通り、基本的にはG4と言ってもクロックが速いだけのG3と言えなくもない。ただし、Mac OS X Pantherの動作速度についていえば、クロックが上がった以上に速く感じる。すでにJaguarでQuartzの2DレンダリングがAltiVecを使って高速化されているということなので、この辺が効いているのだろうと思う。ベージュG3のビデオカードはQuartz Extremeには対応していないのでCPUの仕事はまだかなり多いのだろうけど (^^;)　それでもG3比で体感速度は3倍位なので、現状で十分満足 (^^)