OpenMP - その４。

あまりにも性能が出てないので可視化してみた。何が見えたわけでもないが、GCC と ICC は異なった実装方法をしていることは確認できる。ひとまず、このまま残しておこう。

[注意]
ちなみにグラフは NY(264346 nodes 733846 arcs), クエリは P2P x 256。

OpenMP - その３。

実行結果。残念ながら、Pthreads とはかなり差が付いてしまった。特に OpenMP ですべてのコアを使わなかったときの性能が良くないのは、なぜだろうか。バグが書き方がよろしくないのか、ひとまず晒しておく。

icc : 11.1
gcc : 4.1.2

◆OpenMP [sec.]
       [1]    [2]    [4]    [8]
gcc  4.546  6.148  4.605  2.951
icc  4.631  5.350  6.073  2.918

◆Pthreads [sec.]
       [1]    [2]    [4]    [8]
gcc  4.769  2.424  1.220  0.687
icc  4.528  2.280  1.142  0.674

OpenMP - その２。

各スレッドで必要になる作業領域をどのように降るかだが、最短路ソルバーのようにループで回すが１ループがかなり大きな粒度である場合、次のようになる。これは、Pthreads の場合でもほぼ同じ。

int chunk_size = 1;
int num_threads = omp_get_max_threads();
thread_arguments *ta = initialize_threads(num_threads);

# pragma omp parallel for schedule(dynamic, chunk_size) private(i,tid)
for (i = 0; i <trials; i++) {int tid = omp_get_thread_num();
  results[i] = dijkstra(i, ta[tid]);
}

finalize_threads(ta);

OpenMP - その１。

情報をいただいたので多少気になって調べてみようかと思う。良く使用する GCC と ICC では大きな性能差があるため、スレッド起動に関して違いがあるそう。

・GCC … openmp のコンパイラ指令毎に起動している。
・ICC … スレッド起動は１度で、後はキューイング。

pthread 以上に良く分かっていないので、実験には多少調べることが必要になるだろう。OpenMP で容易にそこそこの性能が出るのなら、ちょっとした実験ができるので。


<注意>
間違っていたようなので、こちらに更新。

SENNHEISER E945。

渋谷の楽器屋さんにて、SENNHEISER E945 というマイクを試して見たところ。
すごく好みの音です。中音域が埋もれずに前に出るイメージ。
前々から試してみたくてうずうずしており、使ってみてやっぱりと納得した一本。
E945 貯金を計画中。

RAMP2009。

RAMP2009 に参加しました。
興味深い発表と懇親会のおいしいお肉。
スタッフの皆さまどうもお世話になりました。

島根県松江市。

RAMP シンポジウムで初島根。
特に両親も同時期に島根旅行という偶然も。
今まで神戸より西には行ったことがなかったので、今回で島根が最西の地に。

screen の caption と hardstatus。

前々から気になっていたこと。

screen の caption と hardstatus ってどう使い分けるものなのでしょうか？
２行使えて便利ってことですかね。

chsh -s /bin/zsh。

bash & screen でも、hardstatus の shelltitle に実行中コマンド名を表示させる方法はあることはあるし以前紹介したが、やはり多機能な zsh が良いと思い、

$ chsh -s /bin/zsh

しました。

オンラインソルバー・メモ - その４。

インターフェイスを統一したので、クエリも同じように扱えたらさらに良いだろう。

「経度:緯度,経度:緯度,...」

のようなフォーマットで扱い、これを parse してクエリファイルを作成するようなスクリプトを組めば、１組のP2P と複数組の P2P を同じように実行できるだろう。

P2P と P2Ps の submit page は共通点も多いので、うまく差分を管理できるようにすれば、今後の管理がずいぶん楽になるだろう。

オンラインソルバー・メモ - その３。

ユーザにとっても管理者にとっても複雑になってしまっている部分として、ヴァージョンの豊富さがある。大きく分けてこの組合せだけある。
入力{画像版, GoogleMaps版} - ソルバ{P2P, P2Ps(via ver.)} - 出力{画像版, GoogleMaps版}
これに IE 版、Lite版を加えるとかなりの数になってしまう。

また、現在は入力時に出力方法を決定しているが、実は両方を出力できるようにしても実行時間には大きく増加しない（パスだけならば、EPS もパスファイルも大きくない）。このことを利用し、出力時に出力方法を決定できるように、両方で出力することを考えている。

これにより、各インターフェイスが統合され、わかりやすくなるだろう。もし実行時間が感じるほど大きくなるのであれば、元の仕様に戻すつもりである。

オンラインソルバー・メモ - その２。

・選択した始点終点の処理を緯度経度にする。
JavaScript の JQuery ライブラリによって取得した画像の座標を、
ここで、

とすると、画像（地図）の大きさが変更されても、始点終点情報を変更する必要がない。

・桁が多くて見づらいが、次のようにするとよい

x = parseInt( x * 1e6 ) / 1e6;
y = parseInt( y * 1e6 ) / 1e6;

イノベーション・ジャパン2009。

今年初めて参加。発表のみの参加だったのだが、発表会場は展示会場からは離れているのと、発表毎に予約が必要なので、正直条件が悪い。次回参加するなら、展示会場がいい。

オンラインソルバー・メモ - その１。

オンラインソルバーでの作業メモ。

・直書きだった MAP 情報を統合。
これにより、MAP 情報は ID で管理できる。連想配列ばんざいです。

<?php
$MAP_DETAILS = array(
                     array("name"        => "NY",
                           "description" => "New York City",
                           "nodes"       => 264346,
                           "arcs"        => 733846,
                           "low_lat"     =>  40.3000009,
                           "high_lat"    =>  41.299997,
                           "low_long"    => -74.499998,
                           "high_long"   => -73.500016),
                     ...,
);
?>

CELL REGZA。

Cell が搭載された REGZA が東芝で開発されている模様。グラフィックス関係のアプリケーションなら、性能が期待できるので正当派の使い方だろうか。個人的に気になるところは発熱で、初代 PS3 は信じられないほど熱くなるので、これをどのようにして避けるのか。ちなみに、実家の AQUOS もかなり熱を持つ。