2012年02月
2012年02月29日
2月成績
■マーケットFX
1月31日 1,913,575円 → 2月29日 2,472,529円 (+558,954円)
今月増減 +558,954円
買い足す間も無く85円を超える円安でしたね。。。
大きく下げない限りポジションキープ予定です。
理想は下げる前に半分利益確定、70円台で購入なんですけど。。。
このまま増資して買い足すのが正解な感じです。
■株
1月31日 6,244,861円 → 2月29日 6,929,245円(+684,384円)
今月増減 +684,384円
こちらも買場を失いました。。。
でも、このまま上がるとも思えません。
暫く待ってれば買えると思います。
配当と優待重視で銘柄選定予定です。
■投信
中国 1月31日 3,110,997円 → 2月29日 3,503,093円 (+392,096円)
インベ欧州 1月31日 789,292円 → 2月29日 934,924円 (+145,632円)
日経 1月31日 2,213,444円 → 2月29日 2,645,453円 (+432,009円)
今月増減 +969,737円
日経インデックスが凄まじい反発力です。。。
1度は1万円見せてくれないかなぁ~(^^ゞ
無理っぽいですね。。。
■合計
1月比 +2,213,075円
■リスク資産合計
20,000,000円 → 2月29日 16,485,244円 (-3,514,756円)
損失がベンツから国産車並みとなりました。
年初からはなんと300万円戻しました。
このままあげて欲しいのですが、そんな状況では無いですよね。。。
慎重に推移を見守りたいと思います。
今日は昨日のパラレル処理時間測定結果です。
LEVEL6-3がパラレル処理時思考時間です。
実感以上の時間がかかっています。
1/8どころか8倍!幾ら何でも変ですよね。。。
同じ処理を8回実行してるのかも。。。。昨日の「パラレル成功」タイトルは取り下げかな(笑)
もうちょっと調べてみます。
投資は好調、ソフトとゴルフは不調、カメラもパッとしないですね。。。
今日は週末の名古屋オートトレンド前売りを購入しました。
また、10-11日は富士山写真撮影に行こうかと考えています。
この週は梅も満開になりそうです。
楽しいことも考えないとね。。。。
ちょっと上がった所で、これからソフト検討始めます。
睡眠不足なので今日は速めに寝ようと思います。
パラレル成功
Check関数のバグを取りパラレル処理が実行できました。
変更点:
public int Check(int pos)
{
int[] i = new int[8];
int[] j = new int[8] {0,0,0,0,0,0,0,0};
int[][] rr = {
new[] { 0, 0, 0, 0, 0, 0, 0, 0 },
new[] { 0, 0, 0, 0, 0, 0, 0, 0 },
new[] { 0, 0, 0, 0, 0, 0, 0, 0 },
new[] { 0, 0, 0, 0, 0, 0, 0, 0 },
new[] { 0, 0, 0, 0, 0, 0, 0, 0 },
new[] { 0, 0, 0, 0, 0, 0, 0, 0 },
new[] { 0, 0, 0, 0, 0, 0, 0, 0 },
new[] { 0, 0, 0, 0, 0, 0, 0, 0 }
};
int c;
int[] f = new int[8] {0,0,0,0,0,0,0,0};
int[] r_pos = new int[8] {0,0,0,0,0,0,0,0};
int id;
int[] koma = new int[8] {0,0,0,0,0,0,0,0};
int m, n;
if (color == 1) c = 2;
else c = 1;
r[0] = 0;
if (board[pos] == 0)
{
// for (d = 0; d < 8; d++)
Parallel.For(0, 8, d =>
この後8方向にそれぞれ駒がおけるかを見に行く部分がパラレル処理になります。
その結果。。。
16個(物理的には8個)のCPU使用率が50%となりました。
パラレル処理は動いているようです。
上のコードを見るとローカル変数を8個用意してそれぞれ初期化する処理も追加しています。
この関数は大量に使われますが、超短時間で処理が終わります。
パラレル処理の8個の処理時間は均等ではなく最長処理が帰ってくるまで他は待っています。
パラレル処理にもそれなりのコストがかかりそうですよね。。。
次は、パラレル処理する前ローカル変数8倍のコストを見るため時間計測した結果です。
なんと、3倍になっちゃいました(LEVEL6-1に対して-2)。
でも、8個パラレル処理すれば短くなるかもと計測したのですが、
ログファイルが空っぽでした。。。(前ファイルをメモ帳であけたままだったかも)
僕の感じでは、パラレル処理したほうが思考時間は延びた様に感じます。
これが、先ほどパラレル処理のコストかなと。。。(^^ゞ
明日時間測定をもう一度してみます。
データを残さないとね。。。
まあ、想定された事なので驚きはしませんが、
パラレル処理は別の部分で導入します。
今日は、パラレル処理練習ですね。
パラレル処理、結構簡単に実現出来るかもしれません(^^♪
コンピュータが打てる手を8つに分けて(8より少ない時は1手毎に)、パラレル処理かな。。。
それにしても梅咲かないですね。。。
今週末は別の花を撮りに行く事になりそうです。
2012年02月28日
パラレルチャレンジその1
結果は失敗でした。
どこかがバグっていますね。。。
変更前と別の結果になるので。
パラレル処理を目指したのは、
盤面上の場所から、そこが置ける場所か?計算する関数の一部です。
置けるかどうかは8方向を見に行くのですが、
そこをパラレル処理にするつもりでした。
あまりに計算時間が短いので、パラレル処理で劇的な時間短縮にはつながらないと思われます。
ではなぜ?と思うでしょうが、構造が簡単なので、パラレル処理の入門と言う意味もあります。
また、意外と効果があるかもしれないという望みもありましたが(^^♪
8スレッド以上にならないのも魅力ですよね。。。
今日はこれ位で終わりにします、もうちょっと時間が欲しいですね。
サラリーマンなのでしょうがないかな。。。
週末の名古屋オートトレンドの準備もしないと。。。
年末旅行のチケットも取らないと。。。。
でももう寝ます。。。
2012年02月26日
αβをチョイ変して50%に
無駄な計算を削除しての時間短縮はひとまず区切りをつけます。
時間対効果が多くは期待できないのではと考えたためです。
盤面構造体を変更すればさらに効果は出せると思いますが。。。
それより前に、αβに手を加えてみました。
具体的な変更は2行に1文字を追加しただけです。
// if(alpha>bc) return bc;
if (alpha >= bc) return bc; // LEVEL7-3
ここは、MIN手番でβを返す、αカット判断をする部分です。
等号が無い場合は。。。
「MIN手番(つまり人間の手番)で、以前検索した結果より大きな値が返された時、
そのブランチはそれ以上検索せずに評価値を返す。」と言う動作になります。
等号を付けると。。。
「MIN手番(つまり人間の手番)で、以前検索した結果より同じか大きな値が返された時、
そのブランチはそれ以上検索せずに評価値を返す。」と言う動作になります。
等号を付ける事によりαカットがより頻繁に発生する事になり時間短縮が出来ます。
等号は今回βカット判断にもつけました。
この2箇所の変更が今日の検討項目です。
ただ、このオプションを使うと「MINMAX検索と同じブランチを選ぶのか?」が心配です。
何となくは同じかもと思いますが、MINMAX検索では等号は入れていないので。。。
まあ、検証なしで暫く進めてみます。
今までのレベル7の読みでは。。。
おおよそ50%時間短縮が出来ました。
気をよくしてレベル8でも測定し、以前の時間と比較してみました。
このグラフの一番下が前回の測定値です。
Android→C#移植そのままでは思考時間は20倍。
今回の変更で10倍までキャッチアップできました。
この変更はAndroid版にもそのまま使えます(^^♪。
マルチコアCPUPCでこの検討を始めた趣旨はマルチスレッドプログラミングなので。。。
最終目的としては思考時間短縮で評価関数チューンをしてより強くするです。
簡単な変更で50%短縮であれば十分な成果だと思います。
本当は今日中にパラレル処理をするつもりでしたが、来週の検討に引継ぎます。。。
来週末は名古屋オートトレンドと、名古屋農業センター枝垂れ梅祭りですね。
梅は咲いたか桜はまだかいな的な季節になりました。
ただ、僕の花粉センサーもちょっぴり反応しています。
憂鬱な季節の始まりでもあります。