或るプログラマの一生

こんなコードを書くと、Visual C++ 2005 ではエラーになります。

#include <stdio.h>
class A { public: static const float a = 1.0; };
int main(void)
{
    printf("%f\n", A::a);
    return 0;
}

a.cpp(2) : error C2864: 'A::a' : スタティック const 整数データ メンバ以外をクラス内で初期化することはできません

構造体とかならしょうがないとして、float ぐらい初期化させてくれよと思うわけです。

またアクセスできなくなりました。ぐぅ。

さすがに諦めて HDD にするべきだと思いますが、3.5 インチ HDD だとうるさいことは前回に分かったので、今回は余ってる 2.5 インチ HDD を回そうと思います。一応 SATA なんですが 160GB のやつなので中古ショップが買ってくれないんですよ（＾＾；

性能向上

• 「デコード速度優先」でエンコードされた映像のデコードを高速化した。5% から 10% 程度。
• x64 バージョンで、「圧縮率優先」でエンコードされた映像のデコードを高速化した。1% 程度。
• ULY2: x64 バージョンで、RGB からのエンコードを高速化した。2% 程度。

何を変更したかは定かではない。

たまに聞かれるので。

Ut Video Codec Suite の Mac 版の QuickTime コーデックコンポーネントは ARGB (k32ARGBPixelFormat) と RGB (k24RGBPixelFormat) でしか入出力できませんが、これは ARGB 以外でコーデックとやり取りできるソフトを持っていないのでテストできないからです。QuickTime Player 7/X でも iMovie でもダメ。

厳密に言うと RGB もサポートできないことになりますが、そこはまあ大丈夫だろうと思って使えるようにしてあります。

今度はロードストア命令を測定してみました。

Ut Video Codec Suite 12.1.0 では AVX 命令を使って高速化しました。

さて、このコード、（狭い意味で） AVX になって追加された命令を使っているわけではなくて、レガシー SSE 命令の VEX プレフィックス版を使っているだけです。レジスタが足りないとかそういった問題も無いので、AVX 版をレガシー SSE 版に容易に書き変えることができ、しかも Sandy Bridge 上では実行速度は変わりません（計測誤差未満）。

性能向上

• ULRG,ULRA,ULY2: AVX 命令が使用可能な環境で、ネイティブな色空間からのエンコードを高速化した。x86 の場合は 10% 程度、x64 の場合は 12% 程度。
• ULRG,ULRA,ULY2: AVX 命令が使用可能な環境で、「圧縮率優先」でエンコードされた映像のネイティブな色空間へのデコードを高速化した。x86 と x64 ともに 5% 程度。

気になったので測定してみました。

• Play ストアでアプリを更新するときに apk と説明文等を atomic に更新できなかった（結果として、新しい apk と古い説明文の組み合わせで公開される状態になり得ていた）。いくらなんでもできないわけがないので操作が悪いだけだと思うが、どうやるんだろう。
• 初版を公開するときは反映までに「数時間かかる」が、更新の時は反映はかなり早い模様。なんでこういう差が発生するのかはよく分からんが。Play ストアは事前審査は無いはずだし。

やべっ、あまり技術ネタじゃない。