2010年09月22日

資格試験

◆取得
・MCTS Windows Server 2008 Network(70-642)

◆今月受験予定
・MCIPT Windows7 サポート(70-685)
・XMLマスター プロフェッショナル データベース(I10-003)

◆来月受験予定
・情報処理技術者試験 システムアーキテクト
・MCITP Windows7 デスクトップアドミニストレータ(70-686)

◆再来月受験予定
・CCNP BCMSN(642-825J)
posted by Hikage. K. at 01:06| Comment(0) | TrackBack(0) | エンジニア

2009年12月23日

平成21年度 秋期 情報処理技術者試験

去年煮え湯を飲まされた旧テクニカルエンジニア・ネットワーク試験。
もう2月ほど前になりますが、今年も受けてきました。
で、12/21が合格発表です。


平成20年度 秋期
情報処理技術者試験 成績照会
ネットワーク スペシャリスト 試験

受験番号 NWxxx - xxxx の方は,合格です。

午前I 74点
午前II 87点
午後I 72点
午後II 62点


なんだよもう、ギリギリじゃないか……
元々午後IIの出来が自信なかったのだけれども、それにしたって酷い点だなおい。すげえ危なかった。
これはあれか。去年から5点分くらいしか進歩してねえって話か自分。

しかしこれで給料に技術手当が付く。その点は未だ薄給の身としては至極嬉しい限りです。
posted by Hikage. K. at 02:53| Comment(0) | TrackBack(0) | エンジニア

2008年12月15日

テクネ落ちた・・・orz

平成20年度 秋期
情報処理技術者試験 成績照会
テクニカルエンジニア(ネットワーク)試験

受験番号 NWxxx - xxxx の方は,不合格です。

午前試験のスコアは,710 点です。
午後I試験のスコアは,690 点です。
午後II試験のスコアは,585 点です。



orzorzorzorzorzorzorzorz......


午後II、午後IIが敵です。
やっぱりこの辺は業務経験無いと辛いってことでしょうか……

いや、自分の実力不足を経験のせいにしちゃいけない。

ともかく来年また頑張ろう。
posted by Hikage. K. at 12:24| Comment(2) | TrackBack(0) | エンジニア

2008年12月14日

明日はテクネの合格発表。

俺、これに受かったら焼肉食いに行くんだ・・・



などと死亡フラグそのままの書き込みをしてみる。

たぶん午後1までは通ってる気がするんですけれども、午後2がなぁ……
posted by Hikage. K. at 15:14| Comment(0) | TrackBack(0) | エンジニア

2008年08月14日

マルチスレッド処理のループの効率のお話

handle = _beginthreadex( NULL, 0, &mul_mt, arg, 0, &tid );
でスレッドを生成した後、各スレッドがループを生成して畳み込み演算処理を行います。
今回はその処理内容についてのお話。

unsigned __stdcall mul_mt(void *arg)
{
------
処理
------
}

サンプルは24万桁の乗算処理。
前にここに貼ったライブラリよりも最適化を行っているので、処理速度は向上しています。
使用CPUはAtom N270(1.6GHz)。まあWind Notebook U100なんですけどね。
マルチスレッドを使用しない場合の処理時間は約8.5秒。

各スレッド内で生成するループに関して。
例えばこうであった場合。

------------サンプル------------
for(i=thread_no;i<max;i+=cpu_num){
処理内容
}
------------ここまで------------
畳み込みの開始位置をずらして増分を1ではなくスレッド生成数(=論理CPU数)と同じにすることで分散処理を実装した方法です。
threading1.pngこんな感じ。
しかしこの方法で実装した場合、処理に要した時間は約9秒と、元の速度よりも長くなってしまいました。



対してこちらはもっと単純な例
------------サンプル------------
for(i=(max/cpu_num)*(thread_no);i<(max/cpu_num)*(thread_no+1);i++){
処理内容
}
------------ここまで------------
スレッドごとの処理領域をCPU数で割って完全に等分に区切られた区画ごとに独立して処理をさせる方法です。
threading2.pngこんな感じ。
この方法で実装した場合、処理時間は約5.5秒に縮まりました。


処理速度に差が出た理由について一考。

・区画ごとに独立しているため、後者の方がメモリアクセス効率が良かったのか?
・単純にi++のインクリメントよりもi+=cpu_numのインクリメントの処理が重いのかも?
・前者の方法では書き込みの衝突が多く起こるためスレッドセーフ処理が高コスト?

こんなとこでしょうか。
後者の方法だと分割された区画ごとに所要時間が異なってしまう可能性があるんで重い区画が割り当てられたスレッドがボトルネックになってしまう可能性はあるんですが、それは分割数をある程度調節することで回避はできるでしょう。
マルチスレッドで並列化する際には分割方法を単純にして、出来る限り各スレッドに独立した操作を行わせた方が効率は上がりそうです。
posted by Hikage. K. at 18:15| Comment(0) | TrackBack(0) | エンジニア

2008年07月27日

スレッドセーフ処理のコストのお話

例えば400万回のループを行うプログラム内で以下のような処理を実行するとします。
「looplockという名前の変数の値が0になるまで待機してから処理を行う」



そこで、ごく簡単にこういったコードを書くとしましょう。

while(looplock != 0){
}

これはlooplockが1である間ループを続けるため、上記の条件を満たしています。このコードをある処理系に組み込んだ際の実行時間は33秒でした。

それではこうしたらどうでしょう。

if(looplock != 0){
  while(looplock != 0){
  }
}

while内で条件として既に処理されているlooplock!=0を、その外側のif文で二重に条件分岐させています。
この処理は一見無駄なように思えます。しかしこのコードをwhile文のみの時と同じ処理系に組み込んだ所、実行時間は27秒。実に6秒も処理が短縮されました。


while条件はループすることを前提に作られているからでしょうか。ループがほとんど起こらない前提で使用する場合はif文に比べて圧倒的にコストが悪いようです。
マルチスレッドプログラミングに限らず、大きなループ内部では不用意にwhile文を使用することは避けた方が良さそうです。
posted by Hikage. K. at 15:04| Comment(0) | TrackBack(0) | エンジニア

2008年07月26日

古典的アルゴリズムによる多倍精度分割統治演算 by C言語

というわけで、まず手始めに古典的アルゴリズムにより非常に単純なものを作ってみた。
plusmul.zip

アセンブラなんて気の利いたものは使えない……とは言いませんが、いまいち得意ではありませんのでとりあえず得意とするC言語でこんな糞プラグラムを書いてみた次第。

unsigned charによる8bitの2進値を1桁ととって、8bitごとに桁上がり等を計算しています。

以下は実行結果。
1.png2.PNG
3.PNG4.PNG


さすがに乗算は時間がかかります。(@C2Q Q6600)
やはり畳み込みの存在がものすごく邪魔になっている模様。
FFTを使わないとありえないくらい遅いですね。
危険なので1000000桁以上の演算は実行しないでください。
というかできないようにしてある。

実行速度は遅いものの、ごく単純な処理しか行っていないのでソースは比較的短く収まっており、ぱっと見わりと理解はしやすいんじゃないかと思われます。


【n_length.h】 ...... 分割統治による多倍精度数を定義するためのヘッダファイル

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <math.h>

#define D8 128; //1 0 0 0 0 0 0 0(2)
#define D16 255; //0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1(2)
#define U16 65280; //1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0(2)

////////////////////////////////
// 1桁8ビットの多倍長型の定義
////////////////////////////////
struct{
unsigned char *base; //仮数
int origin; //中心点(小数点の位置。origin桁目の後に小数点が付く)
int len; //桁数
}typedef mpf;

////////////////////////////////
///定義の意味
/// base[3] (3バイト精度)
/// len = 3
/// origin = 1
/// 0 1 0 0 0 1 0 1 --- base[0]
/// 1 0 0 0 0 0 1 0 --- base[1]
/// 0 0 0 0 0 0 0 1 --- base[2]
///
/// この定義型の示す数は……
/// [0 0 0 0 0 1 0 1 1 0 0 0 0 0 1 0 . 0 0 1 0 0 0 0 0] (2)
/// [1410.0125](10)
///
////////////////////////////////



/////////////////
// 桁数の初期化
// input ... 入力mpf構造体
// length ... 桁数(2進)の設定
// ori ... 中心点の設定
/////////////////
extern void malloc_n_length(mpf *input, int length, int ori)
{
input->base = (unsigned char*)malloc(length);
input->len = length;
input->origin = ori;
}

/////////////////
// 初期値の設定
// in ... 入力mpf構造体
// num ... 設定する初期値(10進)
/////////////////
extern void initialize(mpf *in, double num)
{
int i;
double flt = num;
for(i=in->origin;i>=0;i--){
int power = pow(256,in->origin-i);
in->base[i] = (int)(num / pow(256,in->origin-i));
}
flt = num-(int)num;
for(i=in->origin+1;i<in->len;i++){
in->base[i] = (int)(flt * pow(256,i-in->origin));
}
}






【calc.h】 ...... 多倍精度数を加算・乗算するためのヘッダファイル

#include "n_length.h"

////////////////////////////////
// in1とin2を加算してdestに出力
////////////////////////////////
// in1 ... 入力1
// in2 ... 入力2
// dest ... 出力
////////////////////////////////
extern void n_plus(mpf *in1, mpf *in2, mpf *dest){

int i; //ループ用
// 高速な参照を実現するため、ポインタを定義し構造体への参照を省略する。
//////////////////////////////////////////////
int offset1 = dest->origin - in1->origin; //入力1とdestの桁位置合わせ
int offset2 = dest->origin - in2->origin; //入力2とdestの桁位置合わせ
int maxlen = dest->len-1; //出力の最大桁数
int len1 = in1->len, len2 = in2->len; //入力1,2の最大桁数
unsigned char *in1_data = in1->base; //入力1の実データ
unsigned char *in2_data = in2->base; //入力2の実データ
unsigned char *dest_data = dest->base; //出力の実データ
//////////////////////////////////////////////
int temp1,temp2; // 一時出力用
unsigned short out; // 一時出力用
char up = 0; // 桁上がり



for(i=maxlen;i>0;i--){
temp1 = i+offset1;
temp2 = i+offset2;
//加算が可能
if (temp1<=len1 && temp1>=0 && temp2<=len2 && temp2>=0){
out = in1_data[i] + in2_data[i] + up;
dest_data[i] = out;
if(out> 255)
up = 1;
else
up=0;
}
//in2が範囲外
else if(temp1<=len1 && temp1>=0){
dest_data[i] = in1_data[i] + up;
up=0;
}
//in1が範囲外
else if(temp2<=len2 && temp2>=0){
dest_data[i] = in2_data[i] + up;
up=0;
}
//両方範囲外
else{
continue;
}

}

}

////////////////////////////////
// in1とin2を乗算してdestに出力
////////////////////////////////
extern void n_mul(mpf *in1, mpf *in2, mpf *dest){

int i,j; //ループ用
unsigned short buf; //一時出力用
int pos; //出力位置

// 高速な参照を実現するため、外部で計算できる値は先に取っておき、
// また構造体へのアクセスはポインタを定義して参照する。
//////////////////////////////////////////////
int orig = dest->origin; //出力の小数点位置
int maxlen = dest->len; //出力最大桁数
int l1 = in1->len, l2 = in2->len; //入力最大桁数
int o1 = in1->origin, o2 = in2->origin; //入力の小数点位置
int dest_position = o1+o2-orig; //桁位置調整のためのオフセット
unsigned char *in1_data = in1->base; //入力1の実データ
unsigned char *in2_data = in2->base; //入力2の実データ
unsigned char *dest_data = dest->base; //出力の実データ

memset(dest_data,0,sizeof(dest_data)); //出力の各桁の値を0に初期化


//畳み込み乗算の開始
for(i=dest->len-1;i>=0;i--){
for(j=dest->len-1;j>=0;j--){

pos = i+j-dest_position; //出力位置を取得

//出力位置が範囲内であれば乗算を実行
if (pos>0 && pos<maxlen &&
in1_data[i]!=0 && in2_data[i]!=0){
buf = in1_data[i]*in2_data[j];

//マスクを用いて8ビットごとに分割
dest_data[pos] = buf&D16;
dest_data[pos-1] = buf&U16;
}

}
}

}
posted by Hikage. K. at 20:50| Comment(0) | TrackBack(0) | エンジニア

2008年07月14日

参考書買ってきた。

GPGPUを用いたパラレルπ作成のために池袋のジュンク堂行って参考書を買ってきた。
秋の情報処理技術者試験も迫ってるというのにこんなに読み切れるのか・・・・・・
hon.jpg


今日の散財。

ASCII社
The Art Of Computer Programming 2 日本語版
ISBN:4-7561-4543-4
\10,290
Knuth先生の超数学的なプログラミング書物。
原書の方も同じ棚にあったのでどちらにしようか迷ったのだけれど、CUDA Programming Guideと併せて両方とも英語で読み通さなきゃならないとか考えると心が折れそうになったので結局日本語版買った。
うーん高いなぁ。しかし内容はぎっしり詰まったいい本です。ずっと大事にしよう。

Softbank Creative社
DirectX シェーダプログラミング
ISBN:978-4-7973-4496-7
\2,940
CUDAによる実装だとnVidiaに限られるという弱点があるので、DirectXあたりを使って同じような機能が実装できないかと考えてみた次第なんですけれども、ざっと目を通してみてシェーダプログラムの格納領域や汎用変数領域の矮小さに愕然としてギブアップ。
ごめんなさい、やっぱCUDAでいいですか。

毎日コミュニケーションズ
CPUの創りかた
ISBN:4-8399-0986-5
\2,940
これはこの業界ではとても有名な書ですよね。
売れてる理由がいまいちピンとこなかったんですが、読んでみて成なるほどと納得できました。見た目はこんなナリしててもこの書は入門用の教本であって、内容もそれなりに知識になる事を書いてあるんですが、文体実に教本っぽくなく、いつも笑わせてくれる雑誌編集者のコラム記事の集大成みたいな感じ。読んでて普通に面白いんですよね。これは売れるわ……

技術評論社
テクニカルエンジニア ネットワーク 合格教本
ISBN:978-7741-3427-7
\3,024
こいつは今年の秋から技術手当てになって返って来るのでいわば投資です。さすがに内容的には基本情報のようにヌルくはないですが、まあなんとかする。
posted by Hikage. K. at 00:11| Comment(5) | TrackBack(0) | エンジニア

2008年07月13日

暇つぶし。

PSPちぇんじゃ。

sshot.PNG

今まで携帯動画変換君でPSP用ビデオファイル(AVC)に変換してたんですが、こいつシングルスレッドでしか動かない&多重起動が不能ということで、Core2系などのマルチコアCPUの利点を生かした高速エンコードができず、どうしても処理速度が遅くなりがちです。
だからといって内部ルーチンを弄れるほどH.264についての知識があるわけでもなく。なら並列同時処理ファイル数で攻めればいいんじゃんって事で今朝から3時間くらいかけて作成したのがこちら。

命名はPSPちぇんじゃ。例のごとく自分で使うためだけに作成したものなので十分なデバッグもしておらず、使い勝手は悪いにもほどがあるけれど一応何かの間違いで需要があった場合の事を考慮して貼り付けておきます。

PSPちぇんじゃをダウンロードする

ffmpeg.exeの置いてあるフォルダに直に放り込んで直接起動すればOK。
携帯動画変換君をお使いの方はcoresフォルダに放り込めばそのまま動く仕様になってます。

利点
・複数ファイルの同時処理が可能で、たくさんのファイルを一括変換する時に速い。
(デフォルトではCPUの論理コア数と同値。任意で設定可)

欠点
・ファイル個別のプログレス(進行状況)を表示するつくりになっていない。
posted by Hikage. K. at 11:34| Comment(3) | TrackBack(0) | エンジニア

2008年07月12日

CによるFFTを用いた2進数多倍長計算ライブラリ

「多倍長計算」で検索するとおそらく大量にHITするであろう定義の基本ライブラリの作成を30分前から始めました。


まず基礎から入ろうということで、8ビットごとに仮数を暗示的に割り当てて分割統治法で値を保持して実装しています。

で、現在こんな感じ。
test.PNG

今のところFFT(高速フーリエ変換)のアルゴリズムが未実装であり(というか30分で一からそんなもん作れるか!)、愚直にループを繰り返すように書いているため乗算処理に非常に時間がかかります。
12万桁の乗算を行うのに約7秒。まあ最初はこんなもんか……


GMPとかのライブラリを使えば手間もかからないしもっと圧倒的に速いんでしょうけれども、今回の目的はマルチスレッド化とGPGPUを用いたsuperπのmodプログラム「parallelπ」の作成が主な目的なので、最終的にライブラリを頼ることはできんのです。


しかしGPGPU使ってもシングルスレッドで走るsuperπの速度に追っ付かなかったらどうしよう・・・しかもそれかなり高い確率でありえそうで嫌だなぁ。
posted by Hikage. K. at 02:06| Comment(0) | TrackBack(0) | エンジニア

2008年05月16日

完・基本情報

本日成績発表でした。


受験番号 FExxx - xxxx の方は,合格です。

午前試験のスコアは,740 点です。
午後試験のスコアは,735 点です。

だそうです。
おかしいな何で午前の方がスコア高いんだ……
posted by Hikage. K. at 19:54| Comment(3) | TrackBack(0) | エンジニア

2008年04月20日

続・基本情報

IPAの公式サイトに解答例が掲載されてるっぽいんですが、アクセスが集中してるのか重すぎて絶賛アクセス不能中。

Service Temporarily Unavailable.


とか。もっと強い鯖と線用意しとけばいいのに。




==================================

19:30追記。ようやく解答が見られるようになった。



・・・うわあ午後の問題3つも間違えてる。
緩いとか言ったの誰だよおい。
午前は予想通りミス多し。結局15問以上も落としてた・・・orz
試験中は寝ちゃいけません。
posted by Hikage. K. at 19:09| Comment(3) | TrackBack(0) | エンジニア

2008年04月18日

基本情報を受けなきゃならなくなった。

なんか色々あって明後日の基本情報技術者試験を受ける運びとなりました。
折角の日曜なのにだるい事この上ない。

午後は1時間で終わらせれば退出できるらしいからとっとと終わらせて帰ってこよう。
posted by Hikage. K. at 01:51| Comment(3) | TrackBack(0) | エンジニア

2008年02月03日

NVIDIA CUDAを弄ってみた その2

 NVIDIA CUDAのProgramming Guideを見ながらとりあえず簡単な行列計算のプログラムを書いてみました。
で、CUDAってどのくらいの効果があるのかデモをやってみた。

実行環境は以下の通り
CPU : intel Core 2 Duo E6600(定格2.4GHz動作)
Mem : DDR2-800 1GBx2
M/B : MSI P6N SLI Platinum
VGA : XFX GeForce 8800GT(600/1800定格)

 float型のn次正方行列を2つメモリ上に確保して、単純に掛け算をやらせるといった内容です。
 下に示す実行時間は行列用メモリをhost側(PC上の通常のメモリ空間上)に確保して行列を予め用意した上で、単純に実行時間のみをCUT_SAFE_CALLのtimerで計測したもの。

 で、こちらが実行結果。対数グラフになってるので注意。
cuda1.png

 結果としては、CUDAの方は一度デバイスにデータを転送してからデバイス側のメモリ確保、演算を終了後host側にデータを書き戻すといった作業が必要になるため、256次の行列くらいまでは計算量がほとんど動かず0.12秒くらいかかってます。そのため次数の低い場面ではCPUの方が圧倒的に高速という結果に。
 ところが次数が大きくなるにつれてCPUの優位性はどんどん低くなっていき、256次でついに逆転されます。そして今回試した最大の次数である4096次の掛け算においては、CUDAが2秒程度で演算終了してるのに対し、CPUは11分強程度の時間がかかるというかなりインパクトのある結果になりました。
 演算時間にしてなんと336倍。例えQ6600を3GHzにOCしてマルチスレッドを4つ利かせたにしても、おそらくまだ80倍程度の差が出ることが予測されます。


・・・・・・ああ、現実逃避はこの辺にして論文書きに戻らないと。

---------------------------------
2x2 matrix multiplation.

GeForce 8800GT ... 123.840393[ms]
Core2Duo E6600 ... 0.001252[ms]
=================================
CPUの方が94000倍高速.
=================================

---------------------------------
4x4 matrix multiplation.

GeForce 8800GT ... 115.916733[ms]
Core2Duo E6600 ... 0.001609[ms]
=================================
CPUの方が72000倍高速.
=================================

---------------------------------
8x8 matrix multiplation.

GeForce 8800GT ... 116.341904[ms]
Core2Duo E6600 ... 0.005947[ms]

=================================
CPUの方が20000倍高速.
=================================

---------------------------------
16x16 matrix multiplation.

GeForce 8800GT ... 115.989235[ms]
Core2Duo E6600 ... 0.040821[ms]

=================================
CPUの方が2400倍高速.
=================================

---------------------------------
32x32 matrix multiplation.

GeForce 8800GT ... 115.788734[ms]
Core2Duo E6600 ... 0.318364[ms]

=================================
CPUの方が364倍高速.
=================================

---------------------------------
64x64 matrix multiplation.

GeForce 8800GT ... 117.802986[ms]
Core2Duo E6600 ... 2.549308[ms]
=================================
CPUの方が46.2倍高速.
=================================

---------------------------------
128x128 matrix multiplation.

GeForce 8800GT ... 114.547844[ms]
Core2Duo E6600 ... 20.280603[ms]
=================================
CPUの方が5.6倍高速.
=================================

---------------------------------
256x256 matrix multiplation.

GeForce 8800GT ... 119.344574[ms]
Core2Duo E6600 ... 165.865433[ms]
=================================
GPUの方が1.4倍高速.
=================================

---------------------------------

512x512 matrix multiplation.

GeForce 8800GT ... 170.160553[ms]
Core2Duo E6600 ... 1343.826416[ms]
=================================
GPUの方が7.9倍高速.
=================================

---------------------------------
1024x1024 matrix multiplation.

GeForce 8800GT ... 153.792023[ms]
Core2Duo E6600 ... 10646.773438[ms]
=================================
GPUの方が69.2倍高速.
=================================

---------------------------------
2048x2048 matrix multiplation.

GeForce 8800GT ... 368.669281[ms]
Core2Duo E6600 ... 85250.539063[ms]
=================================
GPUの方が231倍高速.
=================================

---------------------------------
4096x4096 matrix multiplation.

GeForce 8800GT ... 2031.347412[ms]
Core2Duo E6600 ... 682756.812500[ms]
=================================
GPUの方が336倍高速.
=================================


おまけ。
8800GTをオーバークロックした場合。
---------------------------------
4096x4096 matrix multiplation.

600/1500/1800 ... 2031.347412[ms]
600/1500/2000 ... 1981.686890[ms]
600/1800/1800 ... 1842.636963[ms]
600/1800/2000 ... 1786.597778[ms]
700/1800/2000 ... 1785.255005[ms]
=================================
結果はメモリクロックとシェーダクロックに引っ張られる模様。
posted by Hikage. K. at 07:20| Comment(2) | TrackBack(0) | エンジニア

2008年01月21日

NVIDIA CUDAを弄ってみた

折角GeForce8800GTなんて強力な代物があるんだからと、NVIDIA CUDA SDKを入れてみた。
そしてVS2005でテンプレートをちょっと改造してみる。

・・・が、何か見たこともない関数が沢山あるんですケド。



とりあえず2時間向き合ってわかった事。


・CudaではHOST側とDEVICE側で別々のメモリ空間が存在し、異なる関数(例えばHOST側のmalloc操作がDEVICE側ではcudaMalloc)で管理する。

・host、device、globalという関数の宣言オプションがあり、それぞれhostかdeviceか、あるいはその両方から呼び出せるかっていう話。

・試しにdevice側でmallocしてhostからdeviceのメモリに値を渡してみたけれど、512MBのメモリ程度なら一瞬で埋まる。

・device側での処理実行はgrid使う。並列処理はスレッドとブロックっていう単位で行って、この際にスレッドidやブロックidで処理分けが行えるみたいなんだけど、この辺がいまいちうまく動かない現状。おのれメモリがうまく渡せてないじゃないか。まだまだ勉強不足よのう。

・でもとりあえず奇跡的に動かせたプログラムの実行結果。
 実行環境はC2Q Q6600 @3GHz / GeForce8800GT定格

【処理内容】:
2048x1536サイズの8bitグレースケール画像に31x31オペレータの平均値フィルタをかける。

【CPUシングルスレッドで普通にループ使って書いた場合】:
実行時間29.9sec

【CPUを4スレッドで並列処理させた場合】:
実行時間7.72sec

【8800GT上で分割処理させた場合】:
実行時間6.48sec


一応、速くはなった。けど何故このコードで動いてるのか自分でも判ってない状況なので根本からやり直し。
予想では多分まだあと10倍くらいは速くなるんじゃないかと思われる。頑張れ私。
posted by Hikage. K. at 05:15| Comment(1) | TrackBack(0) | エンジニア

2007年11月17日

マルチスレッドプログラミングのテスト その2

それでは実際に画像処理がどこまで高速になるか、静止画像に対して処理を行ってみました。
使用CPUはintel(c) Core 2 Quad Q6600@2.7GHz、入力画像は2048x1536 量子化ビット各色8bitの24bitRGBビットマップ画像、OSはWindows Vista Home Basic、処理時間の計測にはclock関数を用いて10回の試行のうち最も高速であった時の時間を結果としました。

まずはグレースケール化。
1スレッド……0.0780秒
4スレッド……0.0160秒

次に、5x5オペレータの変形ラプラシアンフィルタ。
1スレッド……0.3740秒
4スレッド……0.0930秒

グレースケール化の方は処理時間が短いのでclockで正確な時間が計測し切れてない感がありますが、ラプラシアンの方ではコア数分、ほぼ4倍の処理速度が出てるのが判ると思います。
posted by Hikage. K. at 17:44| Comment(0) | TrackBack(0) | エンジニア

マルチスレッドプログラミングのテスト。

CPU使用率100%

重量級作業の友、マルチスレッドで動作するテストプログラムを走らせてみました。クァッドコアのQ6600のCPU使用率がきっかり100%まで上昇してるのが判ります。

画像処理系の高速化とかにはすばらしい効果を発揮しそうです。
posted by Hikage. K. at 03:35| Comment(0) | TrackBack(0) | エンジニア