ちょっと探した結果、整数前提の場合は以下のコードが最も簡潔ぽい。ただしあまり速くない(らしい)。
$val = 1234567890; 1 while $val =~ s/(\d+)(\d\d\d)/$1,$2/; # 変換後 $val = "1,234,567,890" になる。
「perl 数値 3桁区切り」でググると、perlのコードとして一番上に出てくるのが間違った物だったりして困る。
amaman氏(アマレココの作者)が、ちょっと前にAMV2コーデックを発表しました。AMV2コーデックについては後日書くとして、今回はその比較ベンチマーク記事にあった Ut Video Codec Suite のベンチマーク結果についてです。
Read the rest of this entry
- 性能向上
-
- 共通: エンコードをほんのわずかだけ高速化した。
- 共通: デコードをほんのわずかだけ高速化した。
readme ファイル/(英語) インストーラ(msi 形式) ソース
「より速いコーデック」はあきらめることにしましたが、実装過程で細かい変更を行ったので、それをリリースすることにします。
エンコードテーブルやデコードテーブルを生成する処理を劇的に高速化しました(具体的な数値に関しては忘れました)。それがどれくらい効いてくるのかという話になるわけですが、テーブルの生成は全体の 1% 程度でしかないので、せいぜい 0.5% 程度の高速化になります。たぶん計測誤差に埋もれます。
Huffyuv と本質的には同じ処理を、とりあえずエンコードの部分だけ実装したんですが、計測したところ期待したような速さにはなってなくて、Huffyuv と同じ速さにしかなってませんでした。ループの回り方が以前の Ut Video Codec Suite のものと若干異なるのですが、期待した速度になっていないのはそれが原因なのかも…(確証なし)。すごい苦労して実装して速度が同じとか徒労感で泣ける。
これ以上のアセンブラレベルでの最適化は無理っぽいので、このままだと「Huffyuv より圧縮率が悪くてエンコード速度が同じ」というものが出来上がってしまいます(デコード速度は作っていないのでまだ不明)。これじゃ作る意味ないよなぁ…。あきらめて、書いたコードを捨てて YUV420 対応に進むべきなんでしょうか。