Core i7に100%のCPU負荷

1 of 3123Next»
blog20091019-Corei7100PercLoad

フィリピン出張で移動時の暇つぶしにPSPを購入、HDDビデオに撮りためた番組を変換して観ています。h.264の圧縮率と画質の良さを知ってしまい手放せなくなったためffmpegで変換していたりするわけですが、やっぱりh.264への圧縮速度は遅くCore2Duo 1.8GHzで30fps、Core i7 920 2.66GHzで100~110fpsと言ったところでしょうか。

Core i7はCore2Duoに対してクロック1.5倍・物理コア数2倍とこれだけで3倍の処理能力が期待でき、それを裏付けるようにfpsは3倍強の差があるのでまぁこんなものなのかなぁと思ってたのですが、Core2DuoのCPU負荷がほぼ100%なのに対してi7は50%~65%位しか行きません。ハイパースレッドって1つの物理コアを2つの論理コアに見せかけるわけだから、目一杯動かしても100%にならないのかな・・・

しかしCore i7の負荷をよく見ると1つの論理コアが95~100%の負荷がかかっているのに対し他のは50%前後、もしかしてこの100%の論理コアで走ってるスレッドがボトルネックになってる!?

試しにCore i7でffmpegを2つ走らせたところCPU負荷がほぼ100%となり、合計処理速度は150~170fpsとCore2Duoの5倍以上。化け物だ、このCPU・・・・

1 of 3123Next»

— posted by mu at 01:06 am   commentComment [0]  pingTrackBack [0]

カキフライカレーを食べるために帰国

そんなわけはなくw

抗うつ剤が切れたので、5週間のマニラ生活を終えて帰国。でも来週水曜にまたマニラに戻るって、どうよ?

そんな生活なのでココイチLink のカキフライカレーをやっと食べました。うん、汁はあまり出なかったけど今年のカキも合格点です。出張生活なので、今年は食べる回数が減りそうだなぁ。

そんなカキフライカレーお預け状態に我慢できなかったというわけではないのですが、定宿にしているマニラダイアモンドホテルの日本食料理屋で、2度ほどカキフライカレーを裏メニューで作らせて見ました。衣の状態、カレールーの濃さ、カキの質などココイチのそれとは違いますが、なかなかいけます。機会があれば、ご注文ください。レギュラーメニュー化を目指してますw

カキフライカレーで通じない場合は、カツカレーの豚の代わりにカキを使うように言えばいいかと思います(最初そうやって注文しました)。

— posted by mu at 10:47 pm   commentComment [0]  pingTrackBack [0]

.NET Remoting Server→Clientで例外

以前.NET Remotingで双方向通信Link をやる方法を調べてまとめておいたのですが、要約するとクライアント側にあるdelegateオブジェクトを.NET Remotingを通じてサーバに渡しておけば、サーバーがそのdelegateを呼ぶことによってクライアント側の関数が呼び出されるというもの。

しばらくこの方法で使用していたのですが、このdelegateを呼び出す時によく分からないタイミングで
This remoting proxy has no channel sink which means either the server has no registered server channels that are listening, or this application has no suitable client channel to talk to the server.
などという非常に長いメッセージを持つ例外が発生、サーバー→クライアントの呼び出しが失敗してしまいました。

このメッセージをキーワードにして検索すると、文字数が多いため結構ピンポイントで同じ問題を扱っている海外サイトにヒット。どうやらdelegateを呼び出す時にサーバー側がクライアントのどのポートにどのプロトコルで通信すればいいのか分からなくなるらしいです。

今回はサーバーへの接続を開始する前にクライアント側で以下の処理をして、クライアントが受け付けるチャンネル(sink)を宣言しました。
int portnum = 10000;
string name = "RemoteClient";
SoapServerFormatterSinkProvider sinkProvider = new SoapServerFormatterSinkProvider();
sinkProvider.TypeFilterLevel = System.Runtime.Serialization.Formatters.TypeFilterLevel.Full;
ChannelServices.RegisterChannel(new HttpServerChannel(name, portnum, sinkProvider), false);
上記はHTTPプロトコルでSOAP形式でシリアライズ、クライアントが受け付けるポートは10000ということになりますので、TCP接続やBinaryシリアライズなどは適当に読み替えてください。英語ですが検索すれば、TCP接続やBinaryシリアライズの方が例はたくさん見つかります。

この例のようにクライアント側に書くコードですが、やっていることはサーバのそれ。サーバーがクライアントのdelegateを呼び出すという形をとってますが、その実はサーバーとクライアントが立場を入れ替えてソケット通信しているということなのでしょう。

Cook ComputingLink の内容によると、この例外はdelegateだけでなく何らかの参照がサーバに渡され実体はクライアントだけにしかない場合に発生するとのこと。まぁ、冷静に考えてみればそうかな。

それまで問題なく動いていたプログラムが突然この例外を発生するようになり、以後ほぼ全てのサーバー→クライアント方向の通信が例外発生。どのタイミングでだめになるんですかねぇ。リース時間などと関係あるのだろうか、調べてる時間ない orz

[参考] [2009/10/4 追記]構成ファイルだと以下の内容で動作しましたが、いまひとつ自信なし。MSのサイト行っても<channels>以下に具体的にどう書けばいいのか、ほとんど書いてないんですよねぇ・・・
<configuration>
  <system.runtime.remoting>
    <application name="Client">
      <channels>
        <channel ref="http" port="10000">
          <clientProviders>
            <formatter ref="soap" typeFilterLevel="Full" />
          </clientProviders>
          <serverProviders>
            <formatter ref="soap" typeFilterLevel="Full" />
            <provider ref="soap"/>
          </serverProviders>
        </channel>
      </channels>
    </application>
  </system.runtime.remoting>
</configuration>

— posted by mu at 07:32 pm   commentComment [0]  pingTrackBack [0]

T: Y: ALL: Online:
ThemeSwitch
  • Basic
Created in 0.0114 sec.
prev
2009.10
next
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31